1. Can you plan without understanding what is it that you are planning for? e.g. - what is it we are doing? - what do we need to do?

2. Project Content and Deliverables Software Project Managers Ensures that Product Contents & Project Deliverables are: –well understood –clearly defined –agreed to by all parties How do the project managers do this ? Project Managers Provides: –time –skilled resources –conducive environment –process * Project managers are getting results through others

3. Many times projects are “initiated” without completely understanding the requirements How come? Risky & Dangerous ?!

4. Why Requirements may NOT be Understood From Customers/Users side: –not fully knowledgeable of all the requirements –not good communicator –plain forgot –inconsistent among themselves –not motivated and too busy –etc. From Solution Providers side: –misinterpretation and not listening well –not familiar with the domain specific area and terminology –under pressure to “seize” the project or make the sale –“delusion” of ability to making anything happen under software –plain forgot –etc.

5. General Requirements Management Activities (tilted towards “customized” software projects) Agreeing and Initiating Requirements Step Agreeing and “Sign-Off” Requirements Elicitation (SME skills needed) Requirements Analysis and Prototyping Requirements Review Requirements Specifications (as needed) Orange boxes-- needs Additional Management Focus Does this apply to “agile” process?

6. Requirements Prioritization for A Software “Product” (when it is a “customized” software --- the picture changes –how? ) Support Development Sales Consultants Customers Requirements Sources Requirements Repository Product Management Board (e.g. Release Management Council) List of requirements input to the product plan. Requirements Prioritization

7. Project/Product Management “Board” Potential board participants to help choose and prioritize the requirements –application domain subject matter expert (consultant / analyst) –“lead” Architect, Developer, Designer –customer /user support & maintenance personnel –customer /user representative (may be more than one) –sales /marketing representative –manager /executive who has authority over the resources –strategic business planning –Training/education personnel Pick those people whom you believe will “contribute” to the prioritization of requirements through viewing: –technical feasibility and impact –industry leadership, market positioning, product strategy –user satisfaction, user needs, user wishes –business and financial impact

8. Managing Requirements Prioritization List Item #Item DescriptionSourcePriorityStatus Item Number used to identify and trace the item A brief description of the item, pointing to a specification document if necessary Source of the request such as customer or internal support Assigned priority (e.g. 1 to 4 where 4 is the highest priority) Current status (e.g. accepted and included in current product release, accepted for later release, or rejected )

9. Separate Requirements Activities from the rest of the Project High Risk to provide any plan or cost estimate without understanding requirements Pull Requirements Management Activities Out –as a separate project –priced initially, but may be included as project cost if given the rest of the project –deliverable is a requirements specification Requirements activities, themselves, still needs to be planned and managed