Dr. Kivanc DincerCS319 Week 1 - Sept.12,20051 Chapter 4 INCEPTION IS NOT THE REQUIREMENTS PHASE Objectives Define the inception step. Motivate the following.

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 Objectives Define the inception step. Motivate the following.

Documents

kivanc dincercs319 week

use case model

key requirements

inception phase prototypes

inception artifacts

inception step

requirements phase objectives

requirements phase purpose