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

2. Dr. Kivanc DincerCS319 Week 1 - Sept.12,20052 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.

3. Dr. Kivanc DincerCS319 Week 1 - Sept.12,20053 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.

4. Dr. Kivanc DincerCS319 Week 1 - Sept.12,20054 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

5. Dr. Kivanc DincerCS319 Week 1 - Sept.12,20055 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.

6. Dr. Kivanc DincerCS319 Week 1 - Sept.12,20056 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.

7. Dr. Kivanc DincerCS319 Week 1 - Sept.12,20057 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.

8. Dr. Kivanc DincerCS319 Week 1 - Sept.12,20058 Glossary Describes the key terms in the business domain. Includes a data dictionary –Validation rules, acceptable values, etc.

9. Dr. Kivanc DincerCS319 Week 1 - Sept.12,20059 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. Prototypes / Proof of concepts

10. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200510 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.

11. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200511 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.

12. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200512 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.

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

14. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200514 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.

15. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200515 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.

16. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200516 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.

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

18. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200518 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.

19. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200519 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.

20. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200520 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!

21. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200521 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.

22. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200522 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

23. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200523 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.

24. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200524 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.

25. Dr. Kivanc DincerCS319 Week 1 - Sept.12,200525 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.