dr. kivanc dincercs319 week 1 - sept.12,20051 chapter 4 inception is not the requirements phase...

Dr. Kivanc Dincer CS319 Week 1 - Sept.12,2005 1

Chapter 4INCEPTION 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


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.


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.


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


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.


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.


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.


Glossary

• Describes the key terms in the business domain.

• Includes a data dictionary– Validation rules, acceptable values, etc.


• 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


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.


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.


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.


Development Case

• A description of the Unified Process steps and artifacts for the project. Note that the UP is always customized for each project.


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.


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.


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.


Chapter 5EVOLUTIONARY 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


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.


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.


Poor user input13%

Changing requirements12%

Poor technical skills7%

Poor staffing6%

Other50%

Incomplete requirements12%

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!


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.


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

QualityRequirements


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.


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.


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 dincercs319 week 1 - sept.12,20051 chapter 4 inception is not the requirements phase...

Documents

kivanc dincercs319 week

use case model

key requirements

inception phase prototypes

inception artifacts

inception step

requirements phase objectives

requirements phase purpose