IT Requirements Capture Process

Motivation for this seminar

• Discovering system requirements is hard.• Formally testing use case conformance is hard.• We wanted to show that use cases and shall-

statement requirements can be applied synergistically.

Traditional requirement specs

• Requirements are documented as distinct, textual statements of imperative– Usually using “shall-statement” notation

• Typically organized by functional area• Requirements are structured into parent-child

relationships to facilitate requirement decomposition and derivation

Traditional specs, strengths

• Allows for very precise wording• Straightforward “sign off” of capabilities during

testing– Important for defense contracts

• Requirements easily captured in a tool (e.g., database)

• Widely known and accepted, especially in the defense industry

Traditional specs, weaknesses

• Often become very long and tedious– Increases chance of ambiguity– Hard to comprehend the entire set– Difficult to review with customers

• Little context to each requirement– Typically nothing that “ties” requirements together

into a comprehensive story

Use cases

• Originated in the software industry• Focus: “What does my system have to do for

each user type”• Describes system functionality through structured

narrative stories• Provides light graphical modeling via UML use

case diagrams

Use cases

•A use case is an abstraction of a required behavior of a system. •A use case produces an observable result of value to the user. •A typical system will have many use cases each of which satisfies a goal of a particular user.

•Each use case describes a sequence of interactions between one or more actors and the system.

•A use case narrative is written in a natural language. It is written as a sequence of numbered steps with a main success scenario and alternate flows.

•This sequence of interactions is contained in a use case report and the relationships between the system and its actors are portrayed in use case diagrams.

Use cases, strengths

• Simple concept• Easy to comprehend and follow

– Contingent on writing skill, of course!• User focused – ensures that you consider how the

system supports its environment• Easy to review with non-technical stakeholders

Use cases, weaknesses

• Lack precision– Use cases feel vague

• Relatively hard to document and organize lots of necessary details

• Use cases are not fully accepted• Hard to definitively “sign off” a use case for

acceptance testing

Two requirements specification methods

• Shall-Statement Requirements– Precise and widely accepted but specs are typically

long and hard to comprehend as a set• Use Cases

– Simple and ensure the system satisfies user needs but are less precise and hard to formally test

The starting point

• Capture non-functional requirements in shall-statement form directly in use case report

• Use a “supplementary specification” to capture global non-functional requirements

An Adaptive Process

Develop business model

Define actors &

architecture

Write use case

reports

Revise

Extract functional

requirements

Capture nonfunctional requirements

Develop supplementary requirements

Σ Requirements Specification

Vision, Ops &

Capabilities

The new part.

An Adaptive process that combines traditional requirements and use cases

• Develop a business model• Discover the actors and their goals • Sketch out the use case reports• Iterate on the architecturally significant use cases

Extract the functional requirements from each use case's Brief Description, Added Value and Flow of Events and document them in the Specific Requirements Sections

• Document the nonfunctional requirements in the Specific Requirements Sections

• Iterate on the use case set to ensure consistency and completeness• Develop a Supplementary Requirements Specification to capture

system-wide requirements that do not fit into individual use case reports.

Uses of process output

• With the shall-statement requirements a traditional requirements spec can be easily created– Requirements are based on use cases – good traceability to user goals– Can be stored in a database

• Can build formal tests for each use case– Sign off shall-statements

• Specific requirements section used to document details– Data requirements– User Interface preferences– Constraints

• These details clutter scenario narrative

Requirements and use cases

•Specific Requirements– Functional requirements state, in formal shall statement notation, the

functions that the system must execute.– Nonfunctional requirements are often performance requirements that

specify how well the system must execute certain functions.

•Supplementary Requirements Specification contains the requirements that are associated with more than one use case. Often they are system wide. Examples include cost, schedule, reliability, availability, technology, design life, etc.

Goals versus requirements

•The Mission Statement, Concept of Operations and Business Model contain goals, objectives, capabilities, features, constraints and top-level functions.

•Formal requirements are contained in– Specific Requirements Sections of the Use Cases – Supplementary Requirements Specification– Traditional Requirements Specification

Rating the requirements methods*

Criterion Shall

Statement Method

Use Cases

Hybrid Process

Necessary 1 3 3 Verifiable 3 1 3 Unambiguous 3 2 3 Complete 2 3 3 Consistent 1 2 3 Traceable 2 2 3 Concise 3 1 3 Standard constructs

3 1 3

1= poor, 3= good

Critique of the process

• A problem with the these Processed is that it produces specific, low-level, design requirements.

• We do not know if these can be abstracted to high-level customer requirements.

• The Brief Description and Added Value slots of the use case might provide high-level requirements.

• We need examples of using the process with business use cases.

Summary

• The process derive statement requirements from the use case sequence of events.

• These functional requirements are put in the Specific Requirements section of the use case report.

• These functional requirements can then be put into a requirements database to support traditional specs and tracing.