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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 2

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 3

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 Project Mgr’s responsibility *Not all documents are needed for every project. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 4

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 5

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 6

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 7

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

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 9

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 10

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 11

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 12

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

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 14

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 15

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 16

Chapter 5 EVOLUTIONARY 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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 18

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 19

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! Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 20

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 21

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) Quality Requirements • + ancillary and sub-factors – – – Implementation (includes limitations) Interface Operations Packaging Legal Requirements Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 22

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 23

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 24

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. Dr. Kivanc Dincer CS 319 Week 1 - Sept. 12, 2005 25