Chapter 4 INCEPTION IS NOT THE REQUIREMENTS PHASE

1. Chapter 4INCEPTION IS NOT THE REQUIREMENTS PHASE “The best is the enemy of the good.” - Voltaire Objectives • Define the inception step. • Motivate the following chapters in this section. CS319 Week 1 - Sept.12,2005

2. Inception is NOT the Requirements Phase • Purpose is to decide whether to proceed with development, not to define requirements. • Only key requirements are investigated. • Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation? • Inception is the initial short step to establish a common vision and basic scope for the project. • It will include analysis of perhaps 10% of use cases, analysis of the critical non-functional requirement, creation of a business case, and preparation of the development environment. • Inception in one sentence: Determine the product scope, vision, and business case. CS319 Week 1 - Sept.12,2005

3. Questions during inception • What is the vision for this project? • What is the business case? • Is the project feasible? • Should we buy or build? • Rough estimate of cost? • At end of inception: Go or No Go? An Analogy: New field exploration decision in the oil business. CS319 Week 1 - Sept.12,2005

4. Inception Artifacts • Vision and Business Case • Use-Case Model • Supplementary Specification • Glossary • Prototypes and proof-of-concepts • Risk List & Risk Management Plan • Iteration Plan • Phase Plan and Software Development Plan • Development Case *Not all documents are needed for every project. Project Mgr’s responsibility CS319 Week 1 - Sept.12,2005

5. Vision and Business Case • Describes the high level goals and constraints, the business case, and provides an executive summary. • Usually has an estimate of costs (+/- 100%) and expected benefits stated in financial terms. CS319 Week 1 - Sept.12,2005

6. Use Case Model • Describes the functional requirements and related non-functional requirements. • A set of typical scenarios of using a system. • Preliminary only, usually the names of most of the expected use cases and actors, but usually only about 10% of the use cases are detailed. • Do not detail all of the use cases. Only document the most important ones. About 10% of the use cases should be detailed enough to estimate the scope of the total project. CS319 Week 1 - Sept.12,2005

7. Supplementary Specification • Describes non-functional requirements that do not appear elsewhere. • Functional requirements describe the functionality of the product. All other requirements that must be met are considered non-functional requirements. CS319 Week 1 - Sept.12,2005

8. Glossary • Describes the key terms in the business domain. • Includes a data dictionary • Validation rules, acceptable values, etc. CS319 Week 1 - Sept.12,2005

9. Prototypes / Proof of concepts • These may be developed to clarify the vision, or to validate technical ideas. • Inception phase prototypes are throw away prototypes, not evolutionary prototype that may be evolved into a product. • UI oriented prototypes and programming experiments for “show stopper” technıcal questions. • They are often done with a prototyping tool. CS319 Week 1 - Sept.12,2005

10. Risk Plan • Contains a list of known and expected risks. • Includes business, technical, resource, and schedule risks identified by probability and severity. • All significant risks should have a response or mitigation plan. CS319 Week 1 - Sept.12,2005

11. Iteration Plan • Describes what to do in the first iteration of the product. • Usually implements the core functionality of the product. • Eliminate biggest risk first. • The worst risk is usually that the final product will not meet the most important requirement. CS319 Week 1 - Sept.12,2005

12. Phase / Software Development Plan • A low precision guess for the duration and effort of the elaboration. Includes tools, people, training and other resources required. • May also be called a Resource Plan. CS319 Week 1 - Sept.12,2005

13. Development Case • A description of the Unified Process steps and artifacts for the project. Note that the UP is always customized for each project. CS319 Week 1 - Sept.12,2005

14. Isn’t that a lot of documentation? • In UP, those artifacts are optional • Choose to create only those that really add value for the project • Often, the point of creating artifacts or models is not the document or diagram itself, but the thinking, analysis, and proactive readiness. • “In preparing for battle, I have always found that plans are useless, but planning indispensable.” – General Eisenhower • Artifacts from previous projects can be partially used for later ones. • esp. Risk, project management, testing, and environment artifacts. CS319 Week 1 - Sept.12,2005

15. You know you don’t understand Inception when… • Schedule • Inception should last a few weeks at most. • Requirements and most of the use cases &actors identified. • Only key requirements should be described during inception. Save the rest for later phases and later iterations. • Accuracy of estimates • There is a funnel of cost estimates. The earlier the estimate, the less accurate it is. • Architecture designed • Architecture should be done iteratively during elaboration. • Defer decisions as late as possible. The more you know, the less chance that you will make a bad decision. CS319 Week 1 - Sept.12,2005

16. How much UML during inception? • Perhaps, beyond simple UML use case diagrams, not much diagramming is warranteed. • Requirements expressed mostly in text forms. • UML diagramming will occur in the elaboration phase. CS319 Week 1 - Sept.12,2005

17. Chapter 5EVOLUTIONARY REQUIREMENTS “Ours is a world where people don’t know what they want and are willing to go through hell to get it.” - Don Marquis Objectives • Motivate doing evolutionary requirements. • Defines the FURPS+ model. • Define the UP requirements artifacts. CS319 Week 1 - Sept.12,2005

18. Path to disaster* • The Waterfall method is too risky: - Define the requirements - Design the architecture • Implement the product • There is an attempt in the waterfall method to describe the requirements fully and accurately and “freeze” them. • The wrong paradigm is viewing the software project as similar to predictable mass manufacturing, with low change rates. • Avoid “Paralysis by Analysis” – it kills the budget without significantly benefiting the corporation. • Classic Mistake: Too much time and money wasted in the “fuzzy front end.” • Use iterations instead. CS319 Week 1 - Sept.12,2005

19. Requirements • These are the capabilities and conditions that the system, the project, and the product must provide and meet. • Requirement issues (...) are the leading cause of project failure. • Even if you do a perfect job of building the wrong thing, its no good! • Managing requirements is a best practice for project managers. CS319 Week 1 - Sept.12,2005

20. Figure 5.1 Actual use of waterfall-specified features (Johnson 2002): 45% such features were never used, and an additional 19% were rarely used. WRONG GRAPH! CS319 Week 1 - Sept.12,2005

21. Managing Requirements • Stakeholder requirements are frequently unclear and change over time. Frequently new requirements are discovered as part of the development process. • There must be a “systematic approach to finding*, documenting, organizing, and tracking the changing requirements of a system.” (RUP) * Skillful elicitation via useful techniques • Such as writing use cases with customers, requirements workshops, focus groups with proxy customers, and a demonstratıon of the results of each iteration to the customer. CS319 Week 1 - Sept.12,2005

22. Types and Categories of Requirements : FURPS+ Model (Grady 1992) • Functional (features, capabilities, security) • Usability (human factors, help, documents) • Reliability (failures, recovery, predictable) • Performance (response, throughput, etc) • Supportability (maintainability, configuration) • + ancillary and sub-factors • Implementation (includes limitations) • Interface • Operations • Packaging • Legal Requirements Quality Requirements CS319 Week 1 - Sept.12,2005

23. Functional Requirements • “Behavioral” requirements • Detailed in the Use Case Model and in the System Features list of the Vision artifact. • They are specified in detail in Operation Contracts where necessary. CS319 Week 1 - Sept.12,2005

24. Non-functional requirements • Often called the “-ilities” of a system; quality, reliability, usability, performance, etc. • The glossary, data dictionary and supplemental specifications describe many non-functional requirements. • In addition, architectural documents may have non-functional requirements. CS319 Week 1 - Sept.12,2005

25. UP Requirements Artifacts • Use-Case Model • Supplementary Specification • Glossary • Vision • Business (Domain) Rules • Decribes requirements or policies that transcend one software project. • Ex. Government tax rules. CS319 Week 1 - Sept.12,2005