"101 Uses of Requirements"A talk on the reasons for engineering requirements

Ian Alexander

System Architect User Group, 2001

Requirements Aren't Only for Software

Systems can be composed of subsystems of any type

System

Subsystem 1 Subsystem 2 Subsystem 3

Assembly a Assembly b Assembly c

Software Program yHardware Device x

Different Types of Requirement

UserRequirements

SystemRequirements

System Design/Architecture

WorldEngineered

System

… need to be thought about differently

satisfies

satisfies

Desired Resultsto overcome Problems

in the World

Engineered Solutionsusing new and existing

Systems

UR Activities• Identify Business Objectives

– Why develop anything?

• Identify Stakeholders– Who is involved?

• Obtain Viewpoints– What are they concerned about?

– Do they conflict?

• Resolve Conflicts?• Identify Scenarios

– What results do people want?

Objectives Example

• "To become the market leader in small-household burglar alarms"

• "To make steadily growing annual income from alarm sales, maintenance, and monitoring"

Clear, Simple, Truthful – with many implied requirements

Must not conflict!

Must not conflict!

Users

Actors

Stakeholders

Users, Systems, Actors, Stakeholders

Systems

Identify Stakeholders

• Initial contact will usually indicate people to talk to, their roles and interests

• Stakeholders include direct system users and indirect interests, e.g. regulators and standards bodies

• Stakeholders may themselves suggest other people who ought to be consulted …

Example Viewpoints

Burglar Alarm Viewpoints:Householder – want to be safe in my house, not lose

valuablesMaintenance Engineer – want a job; want alarm to be

easy to diagnose and repairPolice – want to reduce crime; no nuisance from

ringing alarmsShareholder – want annual income based on alarm

sales and contracts to monitor & maintain alarmsIEE, BSI – want systems to conform to standards, be

electrically safe

Types of Viewpoint

Viewpoint

Direct

Indirect

System

Operator

Regulatory

Organisation

Engineering

Environment

Maintenance

Standards

After Sommerville & Kotonya

These can be Actors

These influence our system from outside

Direct and Indirect Viewpoints• Direct viewpoints

– Interact directly with the System– Clients who receive services– e.g. Operators & Other Systems

• Indirect viewpoints – Do not interact directly with the System– Have an ‘interest’ in services delivered by System– Create constraints on System– e.g. engineering standards, industry regulator

Conflict Resolution

• Disagreements about requirements are inevitable when a system has many stakeholders. Conflicts are not ‘failures’ but reflect different stakeholder needs and priorities

• Expect to have to discuss requirements conflicts and reach a compromise that all stakeholders can agree to

• Important to leave enough time for negotiation. Finding a compromise is often time-consuming

Capturing Scenarios

• A workshop can represent a sequence of tasks directly by role-play

• Users often understand processes for the first time

token

user states role & activity,identifies next user(s),throws token(s)

next user statesrole, activity…

99 Uses for Scenarios...Problem Domain

Scenarios

TrainingCourses/Manuals

System UsageScenarios

System Test Scripts

Acceptance Test Scripts

System MaintenanceManual

System OperationsManual

• Scenarios show what results systems should deliver

• So they are the natural way of checking that systems do what they should

• And defining how systems should be used & maintained

• And teaching people to use them

includes

Eliciting Functional and Non-Functional Requirements:

Use & Misuse Cases

Use Cases for 'Car Security'

threatens

Short the Ignitionincludes

mitigates

Lock the Transmission

Steal the Car

Car ThiefCar Thief

threatens

includes

mitigates

Lock the Car

Drive the Car

DriverDriverDriver

Capturing Exceptions

Set Alarm

Shut Door

Watch for IntrusionNot set

Alarm failed

Wrong PIN

Exceptions

Alarm failed

Animal in house

Owner/friend in house

Wind triggers alarm

ExceptionsNot shut

Exceptions

Gathering, Capturing, Eliciting

• is about understanding business & system context• creates user requirements and constraints• many possible approaches and methods

Do requirements exist beforeyou go out to capture them?

Sources of Requirements• Interviews with users • The system’s environment• Business objectives• Marketing requirements• Contractual obligations• Working in user environment• Analogous or existing systems• Change suggestions, problem reports

• User modifications

• User group meetings

• Workshops

• Prototypes

• Studies

• Innovation work

• Questionnaires

• Consultants & Trainers

• Observation / Fieldwork

Validating Requirements – Are we about to build the wrong system?

• Certify that described system is the wanted system• Check requirements document for

– Completeness and consistency

– Conformance to standards

– Method of testing agreed

• Ensure freedom from – Requirements conflicts

– Technical errors

– Ambiguities

Best to find out before you spend $1000M

Requirements Review

Plan the Review Cycle

Obtain Review

Comments

Classify & Sort

Comments

Conduct Review Meeting

Update Requirements

Document

Execute Agreed Actions

Pre-review Baseline

All reviewers work from

same version

Post-review Baseline

Approved version

Review Checks

• Understandable– Can readers of the document understand what the

requirements mean?

• Stated Once– Is information unnecessarily repeated?

• Complete– Any missing requirements? Any information missing from

individual requirement descriptions?

• Unambiguous– Are all terms clearly defined? – Could readers from different backgrounds interpret the

requirements differently?

Review Checks• Consistent

– Different requirements free from contradictions?

• Organised– Document structured sensibly? – Related requirements grouped together?

• Conforms to standards– Do individual requirements and whole requirements

document conform to standards? Are departures from the standards fully justified?

• Fully Traced– Requirements unambiguously identified?– Links to all related requirements? – Links to justifications?

Requirements Checklist• Is each requirement uniquely identified?• Are all specialised terms defined in the glossary?• Does each requirement stand on its own?• Are terms used consistently?• Are there any contradictions?• Are all mentioned facilities described?• Are all related requirements grouped or cross-referenced?• Can we build it?

SR Activities

• Trace Between Items

• Model Desired Behaviour

• Define Constraints

• Specify Requirement Attributes

Traceability• Traceability is primarily to help assess the impact of

requirements change (tracing forwards to design)• And to demonstrate complete satisfaction of

requirements (tracing backwards from design)• Traces link requirements to other system items• Traces have many other uses and purposes:

– to support verification (linking test steps to requirements and other items)

– to link to reference documents– to link terms to their definitions– … and so on.

Backwards/forwards Traceability

User Requirements

System Design

System Specifications

go forwards to assess impact of a change

go backwards to trace origins of a component

Logical links can be followed in either direction

Traceability Example

Impact of requirements on design (in another document)

is found from traceability links

Example Types of Traceability• satisfies

– Links an item back to its sources (such as a requirement). Each system specification and design element must trace back to at least one source

• defines– Links a definition to a term being used with a particular

meaning within the project. Should be a 1:1 mapping.

• verifies– Links a verification (usually a test) item back to a

requirement that it helps to verify. (Note that several tests may be needed for one requirement, and that one test may help to verify many requirements.)

• ...and many others (constrains, depends on, …)

Information Model(of requirement traceability)

• Explicitly named relationships

• Relationship has a type and a direction

• Simple mapping between user concepts and data structures

Document / Data Structure

Typed, Directional Traceability Relationship

Traceability Matrix

Traceability Graph (Back-to-Back Trees)

Traceability - Making Sure You Build What The Users Want

• Engineers and Reviewers have to be able to refer to each requirement uniquely, but change is inevitable and continuous – making tracing difficult

• Requirements are more stable than implementations, but compatibility and portability requirements are therefore often volatile

• Tool support becomes essential when projects are any of the following: large, distributed, long-lived, safety- or mission-critical, in product families or multiple versions, or subject to change

Model System Behaviour - Objectives

• To explore the solution, avoiding commitment to any specific design

• To Show what the system must do, but not how• To Model the desired behaviour of the system• To Map between the World and the Machine

– between the user requirements and the system design

• Method: constrain the solution space with precise specifications. Often called ‘system requirements’ as distinct from ‘user requirements’

• Focus on functions/constraints that must be flowed down to the physical design to meet the user requirements

• Leave freedom for designers to decide how to partition into sub-systems

System Behaviour ModellingDefines Exactly What Is Needed

• System behaviour descriptions

• End-to-end scenarios/threads

• Timing/sequencing of functionality

• Requirements for parallelism/concurrency

• Data and/or material flows

• Flow of control

• Conformance to mathematical models/algorithms

• Performance requirements

• System constraints and ‘ilities’• Interactions with external systems• Other modes of operation:

– Fall-back/reversionary– Abnormal, degraded & emergency– Recovery– Start, stop, reset, warm-up,…– Test modes– Instrumentation or recording– Training

• Safety interlocks, inhibits, overrides,…

What to Model, and WhenTo Describe: Model with:

Big Picture, Actors’ Story Agent Interactions or Use Case Summary

Sequences of Events Scenarios, Use Casesfirst for business transactions,then for system threads

What can happen, when State Transitionsfor complex subsystems

Detailed structure of data Entity-Relationships or for complex structures Objects & Attributes

Partitioning into subsystems Objects & Messageswith interfaces

Traditional versus UML [Context]

Context Diagram Agent Interactions, orUse Case Summary Diagrams

[Scenarios] Jackson Trees, Flowcharts Use Case text (not diagrams), (Dataflows are unsuitable) Activity Diagrams +/- Swimlanes

[States] State Transition Diagrams State Diagrams

[Data] Entity-Relationship Diagrams Objects & Attributes

[Architecture] Procedure Calling Trees, Objects & Messages, Informal Box-and-Line Object Sequence DiagramsArchitecture Diagrams, Dataflows

Define Constraints

• Capture requirements that are not functions but which constrain the desired system in any way

• Link to specific functions where possible

• Some constraints are global, e.g. end-to-end performance targets

• No perfect universal way to classify constraints – but may be helpful to think through a checklist

Types of Constraint(including ‘ilities’)

Constraints

Process Product External

Delivery

Implementation

Standards

Usability

Reliability

Safety

Efficiency

Performance

Capacity

Legal

Economic

Interoperability

After Sommerville & Kotonya

Many other types

Priority & Other Attributes

• Database tracks each item, allowing audit and tracing

• User-defined attributes typically include Status and Priority among others

Control Changes

• Change comes from many sources – detected errors, user wishes, new technology opportunities, competition, …

• Uncontrolled change derails projects

• Ideal is to permit change in manageable increments at predictable cost

• So, you need a change management policy

Concepts of Requirements Engineering• Requirements Engineering consists of two related streams of activity:

– Requirements Development (Elicitation, Analysis, & Modelling)

– Requirements Management (Identification, Configuration, Prioritisation, Traceability)

Requirements Elicitation, Analysis, & Modelling

Requirements Management

newly elicited requirements

agreed versions, traces, progress

• Requirements Development creates and interprets requirements

• Requirements Management organises and keeps track of them

Manage the Requirements

Requirements Database

Requirementsdocument

Traceabilitysupport system

Report generator

Requirementsreport

Req. browserReq. query

system

Change controlsyste m

import/export

Traceability

Matrix

Metrics,Graphs, etc

Managing the Requirements

• Guaranteeing a solid basis for projects• Receives the products of Elicitation & Modelling

• Consists of 3 quite different kinds of activity– Fine-Grained Configuration Management (CM)

– Coarse-Grained CM

– Fine-Grained Engineering Decision Support

Fine-Grained Configuration Management (CM)• Uniquely identifies every requirement

– solid basis for review e.g. “reqt #123 is ambiguous, please change it”

– foundation of traceability e.g. “reqt #123 is satisfied by design items #345, #346”

– only possible basis for managing versions and releases e.g. “reqt #123 is

– optional in version 1.0

– mandatory in version 2.0”

• Must be available within RM toolkit (however it is done)

• Must be rock-solid

What is a Requirements Release?• A Release is a group of Requirements to be developed together

• The resulting (increment of) functionality is typically released to users as a new Product Version

• Can you just put whatever the users want most in Release 1.0 ?

No!

• Some Requirements depend on others– no point being able to send colour images to cellphones until colour screens exist

• So a Release is a Consistent Interdependent Set of Requirements

• Later Releases can build on earlier ones

• Should (in theory) be easy if Life-Cycle is Incremental

• But since development is often Evolutionary, Release Planning can be hard

Coarse-Grained Configuration Management (CM) • Baselines whole sets of requirements/project documents

– solid basis for reviews, contracts, product releases e.g. “Baseline for System Requirements Review (SR/R) contains

– BR v2.1

– SR v1.0

– AT v1.3

– ST v1.0”

e.g. “We promise to deliver the system specified in SR v1.0 at end of Stage 2”

– builds on the fine-grained definition of what exactly is in each version of each document

• CM should therefore be closely integrated with RM toolkit

• Must keep the document versions securely

Fine-Grained Engineering Decision Support

• Prioritising each requirement– rational basis for trade-offs and hard decisions

e.g. “reqt #124 is nice but not vital”

• Tracing each requirement– rational basis for cost estimation

e.g. “reqt #124 leads to design items costing £xyz”

– rational basis for trade-offs e.g. “reqt #124 is not vital; deleting it will save £xyz”

• Specifying which requirement belongs to which Version / Release– firm basis for agreement between customer & developer

e.g. “reqt #124 waits till v3”

OperationalAcceptance

OperationalTrials

SystemTesting

SystemIntegration

Sub-systemTesting

Sub-systemIntegration

Building BlockTesting

Building BlockCommissioning

SystemRequirementsDefinition

System DesignDefinition

Sub-systemRequirementsDefinition

Sub-systemDefinition

Building BlockRequirementsDefinition

Building BlockDesign

Building BlockManufacture

UserRequirementsDefinition

And Requirements are the foundation of V&V!Validation (that we have the

right requirements for the next version)

Verification (of each sub-system)

Verification (that the system does meet its

requirements)

Verification(of each building block)

Validation(that we have the right

requirements now)

SystemsEngineering

Soft SystemsEngineering

EnterpriseManagement

Project Management

Hardware Engineering

Software Engineering

Human Factors

Engineering

Verification EngineeringRequirements Engineering

101 Uses for Requirements?• No, there are many more than that!• The essential foundation of every project• The little rudder that guides the ship• Why? Who? When? What? How Much?• Impossible without.