1. Inception: Starting a New Project Needs Features Vision

2. Purpose of the Requirements Process A Requirements Baseline means we have established, in the users language, a statement of the system functionality and operating constraints SRS Business Vision / Roadmap Informal Requirements Feasibility/Cost Analysis Project Plans Requirements Analysis Contract(s) Customers Business Stakeholders QA Requirements Analysts ArchitectUsers Everybody depends on it!

3. Inception: Know What to Build Prepare vision document & initial business case  Identify key features  Understand your project’s history Develop high-level project requirements  See Objective 1 from last week’s notes!  Remember the “mile-wide inch-deep” mantra  Initial scenarios & domain models (10-20% complete) Manage project scope  Reduce risk by identifying all key requirements

4. What How What How What How Stakeholder Needs Product or System Features Software Requirements Design Spec Test Procedures Documentation Plans Requirements Exist at Many Levels

5. Needs, Features, and Requirements The system to be built Needs Software Requirements Design Test Procedures User Doc Features Solution Space Problem Space Traceability Problem

6. Needs “a reflection of the business, personal, or operational problem (or opportunity) that must be addressed in order to justify consideration, purchase, or use of a new system” -- p. 96 L&W Needs can come from any stakeholder  We typically focus on user needs Needs can be vague and contradictory  Don’t press; some of these will “come out in the wash”  Needs can help you understand the true nature of the problem(s), but you don’t directly implement them

7. Features “a service the system provides to fulfill one or more stakeholder needs” -- p. 97 L& W High-level statements of desired behavior  What we want the system to do, not how to do it!  Often the user has translated this some toward a mechanism to realize the feature. Can be good and bad - work carefully if you want to change the stakeholder’s mind! (change the how, not the what) Sometimes needs and features are hard to separate Features are identifiable but not implementable  You can track these  You can scope your project with these  You can define metadata for these (see fig 9-2)  Try to keep small and manageable  You may start to anticipate gaps & inconsistencies (as risks)

8. 5 Steps in Problem Analysis (Ch. 5) 1.Gain agreement on the Problem Definition  “write the problem down and see if everyone agrees”  See Table 5-1 for a suggested format 2.Understand the Root Causes  Use root-cause analysis and other techniques to ascertain the true problem you are trying to solve  For your projects, chances are these are reasonably well- understood. You can benefit from knowing though, as it can help guide later prioritization of your use cases and feature lists. 3.Identify Stakeholders and End Users  Page 51 provides some reasonable starting questions

9. 5 Steps (continued) 4.Define the Solution System Boundary  What is in the system and who interacts with it Intuitively, you may not be able to pin down exactly what is in the system yet, but you can get agreement on what is not going to be in it! Some useful starting questions on page 54 5.Identify Constraints  A constraint is “…a restriction on the degree of freedom we have in providing a solution” (p. 55)  Tables 5-4 & 5-5 give some examples Your project environments will differ some…but you do need to think about external forces not under your control Understand current constraints, the source of the constraint (person, regulation, etc.), and anticipate future constraints!

10. Drill-down: Step 2 Understand the Root Cause Have you asked your customer WHY they want the project you are implementing? Lean Development and the 5 Whys: Ask your customer why they are having the problem they are asking you to solve. When they tell you, ask them “why is that?” When they tell you, ask them “well, why is that?.” When they respond ask them “why is that?” and when they explain ask them again “why?” The rule is that it can take from 2 to 9 “Whys” to get to the root cause.

11. Drill-down Step 2: Tools Ishakawa (fishbone): Problem goes in box on right Possible causes connected off a main axis (“spine”) Ask Why again – start a mini- skeleton off that cause Heuristic: the 4Ms: consider Man, Machine, Management, & Method Pareto Chart: The 80-20 rule: “80% of the problem is in 20% of the causes” Lay out causes and give estimate of its contribution to the problem Display as histogram

12. Example: Course Registration System Stakeholder Needs  Need less administrative overhead for registration.  Professors need immediate access to student grades. Constraint Operate on the College’s UNIX cluster. Software Requirement Functional  The use case starts when the student selects the “register for course” command. The system displays the list of available courses…  Tree browser is a suggested UI metaphor for showing semester & class info Non-Functional 99% of 24/7 availability (3.65 days downtime per year) Feature Provides a way to view student information, by semester and by class.

13. RUP’s view of Vision In RUP-speak, the Vision document oversees the entire requirements process and deliverables…

14. The Vision Document Capture the essence of the project  “essence” == needs and features  “essence” --> scope Is the Vision document the Product Roadmap?  Some might say yes  I say no You need a vision for this project instance, as you need to scope! The product may need a broader roadmap that indicates its trajectory in the marketplace –A document you should be aware of, but Marketing owns –The Vision doc you own, but Marketing (and other “external” stakeholders should be very interested in) Some templates will be provided on the class website