Inception is Not the Requirements Phase

Inceptions

The initial short step to establish a common vision and basic scope for the project

Inception includes

analysis of perhaps 10% of the use cases, analysis of the critical non-functional requirements (quality attributes), creation of a business case, preparation of the development environment

Questions to explore

What is the vision and business case for this project?, Is it feasible?, Buy and/or build?, Rough estimate of cost?, Should we proceed or stop?

Do just enough investigation to

form a rational, justifiable opinion of the overall purpose and feasibility of the potential new system

Decide

if it’s worthwhile to invest in deeper exploration

Most requirements analysis occurs during

elaboration

Inception

Envision the product scope, vision, and business case.

Main problem solved

Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?

Optional artifacts in Inception

Vision and business case, Use case model, Supplementary specification, Glossary, Risk list & risk management plan, Prototypes and proof of-concepts, Iteration plan, Phase plan & software development plan, Development case

Inception is

more than “a few” weeks long for most projects

There is an attempt to

define most of the requirements

Estimates or plans are expected to be

reliable

You define the architecture

this should be done iteratively in elaboration

You believe the proper sequence of work should be

define the requirements, design the architecture, implement

There is no

business case or vision artifact

All the use cases are

written in detail

None of the use cases are written in detail

10-20% should be written in detail to obtain some realistic insight into the scope of the problem

UML in Inception

not much diagramming is warranted, Simple UML use case diagrams may be useful, Most UML diagramming occurs in elaboration…

Managing the requirements is not

fully defining and stabilizing them before beginning design and coding

Manage requirements

are Given the reality of unclear, changing requirements (volatility)…

Managing requirements is

a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system.

The single largest contributing factor to failure

cited in 82% of projects as the number one problem (Thomas 2001), requirements definition is a cause of failure in nearly 80% of failed projects (Taylor 2000)

Any assumption that there will be little significant change to

requirements once they have been documented is fundamentally flawed.

45% of waterfall-style requirements were

never used (Johnson 2002), 19% were “rarely” used

FURPS+

requirement categories in the UP

FURPS+

functional, usability, reliability, performance, supportability + implementation, interface, operations, packaging, legal

functional

features, capabilities, security

Usability

human factors, help, documentation

Reliability

frequency of failure, recoverability, predictability

Performance

response times, throughput, accuracy, availability, resource usage

supportability

adaptability, maintainability, internationalization, configurability

implementation

resource limitations, languages and tools, hardware

interface

constraints imposed by interfacing with external systems

operations

system management in its operational setting

packaging

physical box

legal

licensing and so forth

quaility attributes

The “-ilities” of a system drive the architectural decisions…

In common use, requirements are categorized into

functional requirements (behavioral), non-functional requirements (everything else)

UP Requirements Artifacts

Use case model, supplementary specification, glossary, vision, business rules

Use case model

typical scenarios of using a system, primarily for functional requirements

supplementary specification

non-functional requirements, features not expressible as use cases

glossary

noteworthy terms, data dictionary

Vision

executive overview of the project’s big ideas

business rules

domain rules, transcend a single project