1 / 25

Chapter 4 INCEPTION IS NOT THE REQUIREMENTS PHASE

Chapter 4 INCEPTION 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. Inception is NOT the Requirements Phase.

joshuawatts
Télécharger la présentation

Chapter 4 INCEPTION IS NOT THE REQUIREMENTS PHASE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related