Www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 1 Requirements Engineering From System Goals to UML Models

www.wileyeurope .com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 1

Requirements EngineeringFrom System Goals

to UML Models to Software Specifications

Axel Van Lamsweerde

www.wileyeurope .com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 2

Fundamentals of REFundamentals of RE

Chapter 1

Setting the Scene

3www.wileyeurope .com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons

Setting the scene: outline

What is Requirements Engineering (RE) ?

– The problem world & the machine solution

– The scope of RE: the WHY, WHAT and WHO dimensions

– Types of statements involved: descriptive vs. prescriptive

– Categories of requirements: functional vs. non-functional

– The requirements lifecycle: actors, processes, products

– Target qualities and defects to avoid

– Types of software projects

– Requirements in the software lifecycle

– Relationship to other disciplines


Setting the scene: outline (2)

Why engineer requirements?

– The requirements problem: facts, data, citations

– Role and stakes of Requirements Engineering

Obstacles to good RE practice

Agile development and RE

To fully apprehend the material in this chapter and the next ones, you should carefuly read the 3 case study descriptions in Section 1.1.2 of the book


The problem world and the machine solution

To make sure a software solution “correctly” solves some real-world problem, we must first fully understandunderstand and definedefine ...

– what problemwhat problem needs to be solved in the real world

– the contextcontext in which the problem arises

Example: car control

– ProblemProblem: manual handbrake release can be inconvenient in certain situations

– ContextContext: car driving, braking, driver ’s intent, safety

rules, ...


WorldWorld: problematic part of the real-world, made of– human components: organization units, staff, operators, ...

– physical components: devices, legacy software, mother Nature, ...

MachineMachine: what needs to be installed to solve the problem– software to be developed and/or purchased– hardware/software implementation platform, associated

input/output devices (e.g. sensors & actuators)

Requirements engineering (RE) is concerned with ...

– the desired machine’s effect on the problem worldeffect on the problem world– the assumptionsassumptions and relevant propertiesrelevant properties about this world

The problem world and the machine solution (2)


The problem world and the machine solution (3)

The world and the machine have their own phenomena while sharing others

RE is solely concerned with worldworld phenomena, including shared ones [Jackson95]

– unlike software design, concerned with machine phenomena

World Machine

MotorRaising

HandbrakeReleased

DriverWantsToStart motor.Regime = ‘up’

handBrakeCtrl = ‘off’

errorCode = 013

MachineMachinephenomenaphenomena

WorldWorldphenomenaphenomena

SharedSharedphenomenaphenomena

stateDatabaseupdated


The problem world involves two system versions

SystemSystem: set of interacting components structuring the problem world

System-as-isas-is: system as it exists before the machine is built into it

System-to-beto-be: system as it should be when the machine will operate into it

System-as-isas-is

Concepts, phenomena, rules about car handbraking

System-to-beto-be Machine

Concepts, phenomena, rules about automated handbraking

Car

Driver Brake


RE: a preliminary definition

CoordinatedCoordinated set of activitiesactivities ...

– for exploringexploring, evaluatingevaluating, documentingdocumenting, consolidatingconsolidating,

revisingrevising and adaptingadapting the objectivesobjectives, capabilitiescapabilities,

qualitiesqualities, constraintsconstraints & assumptionsassumptions on a software-

intensive systemsystem

– based on problemsproblems raised by the system-as-isas-is and

opportunitiesopportunities provided by new technologies


What others said ...

Requirements definition must say ...– whywhy a new system is needed, based on current or

foreseen conditions,

– whatwhat system features will satisfy this context,

– howhow the system is to be constructed

RE is concerned with the real-world goalsgoals for, functionsfunctions of, constraintsconstraints on software systems; and with their

– linklink to precise specifications of software behaviorspecifications of software behavior,

– evolutionevolution over time and families

Ross'77

Zave'97


System System requirements vs. softwaresoftware requirements

Software-to-beSoftware-to-be: software to be developed - part of the machine, component of the system-to-be

Environment:Environment: all other components of the system-to-be, including people, devices, pre-existing software, etc.

System requirementsSystem requirements: what the system-to-be should meet; formulated in terms of phenomena in the environment

“The handbrake shall be released when the driver wants to start.”

Software requirementsSoftware requirements: what the software-to-be should meet on its own; formulated in terms of phenomena sharedshared by the software and the environment

“The software output variable handBrakeCtrl shall have the value off when the software input variable motorRegime gets the value up.”


The scope of RE: the WHY, WHAT, WHO dimensions

ObjectivesWHYWHY

a new system?

WHATWHAT services?

WHOWHO will be

responsiblefor what ?

satisfy

assignment

requirements, constraints,assumptions

problems, problems, opportunities,opportunities,

system knowledgesystem knowledge

System-to-beSystem-as-is


The WHY dimension

Identify, analyze, refine the system-to-be’s objectivesobjectives– to address analyzed deficiencies of the system-as-is– in alignment with business objectives– taking advantage of technology opportunities

Example: airport train control“Serve more passengers”

“Reduce transfer time among terminals”

Difficulties– Acquire domain knowledge– Evaluate alternative options (e.g. alternative ways of satisfying

the same objective)– Match problems-opportunities, and evaluate these:

implications, associated risks– Handle conflicting objectives

??


The WHAT dimension

Identify & define the system-to-be’s functional services functional services (software services, associated manual procedures)

– to satisfy the identified objectives– according to quality constraints: security, performance, ...– based on realistic assumptions about the environment

Example: airport train control

“Computation of safe train accelerations”

“Display of useful information for passengers inside trains”

Difficulties– Identify the right set of features

– Specify these precisely for understanding by all parties– Ensure backward traceability to system objectives

??


The WHO dimension

Assign responsibilities for the objectives, services, constraints among system-to-be components

– based on their capabilities and on the system’s objectives

– yielding the software-environment boundary

Example: airport train control

– “Safe train acceleration” ... under direct responsibility of software-to-be (driverless option) oror of driver following software indications ?

– “Accurate estimation of train speed/position” ... under responsibility of tracking system oror of preceding train ?

Difficulties– Evaluate alternative options to decide on the right degree of

automation

??



What is Requirements Engineering?



– Types of statements involved: descriptive Types of statements involved: descriptive vs.vs.

prescriptiveprescriptive

– Categories of requirements: functional Categories of requirements: functional vsvs.. non-functional non-functional







Statements may differ in mood

DescriptiveDescriptive statements state system properties holding regardless of how the system should behave (indicative mood)

– natural law, physical constraint, etc

– e.g. “If train doors are closed, they are not open” “If the train’s acceleration is positive, its speed is non-null”

PrescriptivePrescriptive statements state desirable properties holding or not depending on how the system behaves (optative mood)

e.g. “Doors shall always remain closed when the train is moving”

Important distinction for RE:– prescriptive statements can be negotiated, weakened,

replaced by alternatives– descriptive statements cannot


Statements may differ in scope

A RE statement may refer to phenomena ...

– owned by the environment

– or shared between the environment & the software-to-be: one controls controls phenomena monitored monitored by the other, and resp.

Environment Software

TrainMoving

TrainAtPlatform

DoorsClosed measuredSpeed 0

doorsState = 'closed'

errorCode = 05

trainPosition-DBupdated

TrainMovingTrainMoving DoorsClosedDoorsClosedmeasuredSpeed measuredSpeed 0 0 doorsState = 'closed'doorsState = 'closed'


Types of statements:

systemsystem requirements, softwaresoftware requirements

System requirementSystem requirement: prescriptive statement refering to environment phenomena (not necessarily shared)

– to be enforced by the software-to-be possibly together with other system components

– formulated in a vocabulary understandable by all parties

TrainMoving DoorsClosed

Software requirementSoftware requirement: prescriptive statement refering to shared phenomena

– to be enforced by the software-to-be solely– formulated in the vocabulary of software developers

measuredSpeed 0 doorsState = 'closed’

(A software req is a system req; the converse is not true)


Types of statements: domain properties, assumptions, definitions

Domain propertyDomain property: descriptive statement about problem world phenomena (holds regardless of any software-to-be)

trainAcceleration > 0 trainSpeed 0

AssumptionAssumption: statement to be satisfied by the environment of the software-to-be– formulated in terms of environment phenomena– generally prescriptive (e.g. on sensors or actuators)

measuredSpeed 0 iffifftrainSpeed 0

DefinitionDefinition: statement providing a precise meaning to system concepts or auxiliary terms– no truth value

“measuredSpeed is the speed estimated by the train’s speedometer”


measuredSpeed

I: input data

DoorsClosed

C: controlled variables

trainSpeed

doorsState

Environment

M: monitored variables

O: output results

SoftwareToBe

Output Devices (e.g. actuators)

Input Devices (e.g. sensors)

SysReq M C relation on environment monitored/controlled variables SofReq I O relation on software input/output variables

SofReq = Map (SysReq, Dom, Asm) translates SysReq using domain properties and assumptions

Relating software software reqs to system system reqs: the 4-variable model [Parnas95]


Mapping system reqs to software reqs involvessatisfaction arguments

SOFREQ, ASM, DOM |= SysReq “IfIf the software requirements in SOFREQ, the assumptions in ASM and

the domain properties in DOM are all satisfied and consistent, thenthen the system requirements SysReq are satisfied”

SofReq: measuredSpeed 0 doorsState = 'closed’

ASM: measuredSpeed 0 iff iff trainSpeed 0

doorsState = 'closed’ iffiff DoorsClosed

Dom: TrainMoving iffiff trainSpeed 0

---------------------------------------------------------------------------

SysReq: TrainMoving DoorsClosed

Further to requirements, we need to elicit, evaluate, document, consolidate relevant assumptions & domain properties


Categories of requirements

Functional requirements: Functional requirements: prescribe what services the software-to-be should provide

– capture intended software effects on environment, applicability conditions

– units of functionality resulting from software operations

“The software shall control the acceleration of all trains”

Non-functional requirements: Non-functional requirements: constrain how such services should be provided

– QualityQuality requirements: safety, security, accuracy, time/space performance, usability, ...

– Others: compliance, architectural, development reqs

– To be made precise in system-specific terms

“Acceleration commands shall be issued every 3 seconds to every train”


A taxonomy of non-functional requirements

Non-Functional Requirement

Quality of Service Compliance Architectural Constraint Development Constraint

ConfidentialityIntegrity Availability

DistributionInstallationSafety Security

Usability

PerformanceReliability MaintainabilityCost

Time Space

DeadlineVariability

Softwareinteroperability

Convenience

Interface

Userinteraction

Deviceinteraction

Subclass link

Accuracy

Cost

See definitions and examples in the book No clear-cut boundaries, possible overlaps

– Functional/non-functional: e.g. functional reqs for firewall management are security-related

– Non-functional overlaps: e.g. “high frequency of train commands” is related to performance and safety


Requirements taxonomies are helpful ...

More specific definition of what requirements are in specific classes

More semantic characterization of requirements ...

– prescribing desired behaviorsdesired behaviors e.g. many functional reqs

– ruling out inadmissible behaviorsinadmissible behaviors e.g. many safety, security, accuracy reqs

– indicating preferred behaviorspreferred behaviors e.g. soft, “ility” reqs

Elicitation/analysis can be guided by taxonomy browsing– Is there any confidentiality req on information X ?

– Is there any accuracy req on information Y ?

– Is there any conflict between confidentiality and accountability reqs in my system?








– The requirements lifecycle: actors, processes, productsThe requirements lifecycle: actors, processes, products






The RE process (1)

start

domain understandingdomain understanding

& elicitation& elicitation

alternative proposalsalternative proposals


Domain understanding

Studying the system-as-is– Business organization: structure, dependencies, strategic

objectives, policies, workflows, operational procedures, ...– Application domain: concepts, objectives, tasks,

constraints, regulations, ...

– Strengths & weaknesses of the system-as-is

Identifying the system stakeholdersstakeholders:– Groups or individuals affected by the system-to-be, who

may influence its elaboration and its acceptance– Decision makers, managers, domain experts, users,

clients, subcontractors, analysts, developers, ...

ProductsProducts: Initial sections for preliminary draft proposal Glossary of terms


Requirements elicitation

Exploring the problem world ...

Further analysis of problems with system-as-is: symptoms, causes, consequences

Analysis of technology opportunities, new market conditions

Identification of ...– improvement objectives

– organizational/technical constraints on system-to-be

– alternative options for satisfying objectives, for assigning responsibilities

– scenarios of hypothetical software-environment interaction

– requirements on software, assumptions on environment

ProductProduct: Additional sections for preliminary draft proposal


The RE process (2)

start

domain understanding& elicitation

evaluationevaluation

& agreement& agreement

alternative proposals

agreedagreedrequirementsrequirements


Evaluation & agreement

Negotiation-based decision making ...

– Identification & resolution of conflictingconflicting concerns

– Identification & resolution of risksrisks with proposed system

– Comparison of alternative optionsalternative options against objectives & risks, and selection of preferred ones

– Requirements prioritizationprioritization: to resolve conflicts, address cost/schedule constraints, support incremental development

ProductProduct: Final sections of draft proposal documenting the selected/agreed objectives, requirements, asssumptions (incl. rationale for selected options)


The RE process (3)

start


evaluation& agreement


agreedrequirements

documented requirementsdocumented requirements

specificationspecification& documentation& documentation


Specification & documentation

Precise definition of all features of the agreed system

– Objectives, concepts, relevant domain properties, system/software requirements, assumptions, responsibilities

– Satisfaction arguments, rationale for options taken

– Likely system variants & evolutions

– Estimated costs

Organization of these in a coherent structure

Documentation in a form understandable by all parties

Resulting product: Requirements DocumentRequirements Document (RD)


The RE process (4)

start




agreedrequirements

documented requirements

consolidatedconsolidatedrequirementsrequirements

specification& documentation

validationvalidation

& verification& verification


Requirements consolidation

Quality assurance activity on RD ...

– Validation: adequacy of RD items wrt real needs ?

– Verification: omissions, inconsistencies ?

– Checks for other target qualities (discussed next)

– Fixing of errors & flaws

ProductsProducts: Consolidated RD Acceptance test data, prototype

Development plan

Project contract


RE: an iterative process

start




agreedrequirements

documented requirements

consolidatedrequirements

specification& documentation

validation& verification

RE phases are ordered by data dependencies

No strict sequencing: intertwining, overlap, backtracking

Iterated cycles due to error corrections & evolving needsevolving needs– during RE, during software development, after

deployment









– Target qualities and defects to avoidTarget qualities and defects to avoid





Target qualities for RE process

Correct Each requirement reflects a need.

Complete All necessary requirements included.

Unambiguous All parties agree on meaning.

Consistent All parts match

Ranked for importance and stability Priority and expected changes per requirement.

Modifiable Easy to change, maintaining consistency.

Verifiable Possible to see whether requirement is met.

Traceable To goals/purposes, to design/code.

Additional:

Understandable by customer and developer.


Types of RE errors & flaws: a wide palette

Omission (critical error!)

Contradiction (critical error!)

Ambiguity (critical error!)

Unmeasurability

Noise, overspecification

Unfeasibility (wishful thinking)

Unintelligibility

Poor structuring

Poor modifiability:

Opacity


Errors in a requirements document (RD)

OmissionOmission: problem world feature not stated by any RD item e.g. no req about state of train doors in case of emergency stop

ContradictionContradiction: RD items stating a problem world feature in an incompatible way

“Doors must always be kept closed between platforms” and “Doors must be opened in case of emergency stop”

AmbiguityAmbiguity: RD item allowing a problem world feature to be interpreted in different ways

“Doors shall be open as soon as the train is stopped at platform”

UnmeasurabilityUnmeasurability: RD item stating a problem world feature in a way precluding option comparison or solution testing

“Panels inside trains shall be user-friendly”


Flaws in a requirements document (RD)

NoiseNoise: RD item yielding no information on any problem world feature (Variant: uncontrolled redundancy)

“Non-smoking signs shall be posted on train windows”

OverspecificationOverspecification: RD item stating a feature not in the problem world, but in the machine solution

“The setAlarm method shall be invoked on receipt of an Alarm message”

UnfeasibilityUnfeasibility: RD item not implementable within budget/schedule

“In-train panels shall display all delayed flights at next stop”

UnintelligibilityUnintelligibility: RD item incomprehensible to those needing to use it

A requirement statement containing 5 acronyms

Poor structuringPoor structuring: RD item not organized according to any sensible & visible structuring rule

Intertwining of acceleration control and train tracking issues


Flaws in a requirements document (2)

Poor modifiabilityPoor modifiability: RD items whose changes must be propagated throughout the RD

Use of fixed numerical values for quantities subject to change

OpacityOpacity: RD item whose rationale, authoring or dependencies are invisible

“The commanded train speed must always be at least 7 mph above physical speed” without any explanation of rationale for this


The RE process may vary according to project type

GreenfieldGreenfield vs. brownfieldbrownfield projects

Customer-drivenCustomer-driven vs. market-drivenmarket-driven projects

In-houseIn-house vs. outsourcedoutsourced projects

Single-productSingle-product vs. product-lineproduct-line projects

Variation factors ...– Respective weights of elicitation, evaluation, documentation,

consolidation, evolution– Intertwining RE/design– Respective weights of functional vs. non-functional reqs– Types of stakeholder & developer involved– Specific uses of the RD– Use of specific techniques


Requirements in the software lifecycle

RequirementsDocument

Project estimations(size, cost, schedules)

Project workplan

Software prototype,mockup

Follow-up directives

Software architecture

Call for tenders,proposal evaluation

Quality Assurancechecklists

Project contract

Software evolutiondirectives

Software documentation

Acceptance test data

Implementationdirectives

User manual

RE, system design & software architecture design are inevitably intertwined

The RD impacts on many software artefacts


RE has multiple connections with other disciplines

Primarily with Software Engineering (SE) Other connections:

– Domain understanding & requirements elicitationDomain understanding & requirements elicitation: system engineering, control theory, management science, organization theory, behavioral psychology, anthropology, AI knowledge acquisition

– Requirements evaluation & agreementRequirements evaluation & agreement: multicriteria analysis, risk management, conflict management, negotiation theory

– Requirements specification, documentation & consolidationRequirements specification, documentation & consolidation: software specification, formal methods in SE

– Requirements evolutionRequirements evolution: change management, configuration management in SE

– System modelingSystem modeling: conceptual models in DB & MIS; task models in HCI; knowledge representation in AI


Setting the scene: outline (2)

Why engineer requirements?Why engineer requirements?

– The requirements problem: facts, data, citationsThe requirements problem: facts, data, citations

– Role and stakes of Requirements EngineeringRole and stakes of Requirements Engineering




The requirements problem: facts, data, citations

Poor requirements are ubiquitous ...

“Requirements need to be engineered and have continuing review and revision”

Prohibitive cost of late correction ... “Up to 200 x cost of early correction”

RE is hard & critical ... “Hardest, most important function of SE is the iterative extraction & refinement of requirements”

Bell&Thayer ’76

Boehm ’81

Brooks ’87


The requirements problem: Standish report, 1995

Survey of 350 US companies, 8000 projects8000 projects

(partial success = partial functionalities, excessive costs, big delays)

Major source of failure: poor requirements engineering 50% responses


Major source of failure: poor requirements engineering 50% responses:

The requirements problem: Standish report, 1995 (2)

www.standishgroup.com/chaos.html


The requirements problem: European survey, 1996

Coverage: 3800 EUR organizations, 17 countries

Main software problems perceived to be in...

– requirements specification

> 50% responses

– requirements evolution management

50% responses

[European Software Institute, 1996]


The requirements problem is perceived to persist in spite of progress in software

technology

[J. Maresco, IBM developersWork, 2007]

Failure %

1994 2000 2003

100

50

other causes

requirements-related

0


Requirements-related errors are ...

the most numerousnumerous

– 40% of software errors

the most persistentpersistent

– found very late, often after software delivery

the most expensiveexpensive

– cost ... 5x more if fixed during design

10x more if fixed during implementation

20x more if fixed during integration testing

200x more if fixed after delivery

– account for 66% of software error costs

[Boehm, Jones, Lutz, Hooks & Farry, ...]


Requirements-related errors can be dangerous

US Aegis/Vincennes (1988): shooting of IranAir airbus

– Missing timing between 2 threat events in requirements on alarm software

Patriot anti-missile system (1st Gulf war)

– Hidden assumption on maximum usage time

London Ambulance System (1993): fatal delays– Wrong assumptions on crew behavior, ambulance

localization system, radio communication, ...

Boeing 757 crash, Cali (1995)

– Autopilot ’s wrong timing/localization assumption on flap extension point

Cf. ACM RISKS Digest Forum website


Example: inadequate domain property in A320 braking logic

SofReq: reverse = ‘on’ iffiff WheelPulses = ‘on’

ASM: reverse = ‘on’ iffiff ReverseThrustEnabled

WheelPulses = ‘on’ iff iff WheelsTurning

Dom: MovingOnRunway iffiff WheelsTurning

---------------------------------------------------------------------------

SysReq: ReverseThrustEnabled iffiffMovingOnRunway

Warsaw crash: plane moving on waterlogged runway with no wheels turning (aquaplaning)


Role and stakes of RE

TechnicalTechnical impact– on many software-related artefacts (as seen before)

ManagerialManagerial impact– basis for communication among parties and for project

management

LegalLegal impact – contractual commitment client-provider-subcontractors

Impact on certificationcertification

– Mastered RE process required by many quality standards & certification authorities


Role and stakes of RE (2)

Impact on economyeconomy, security, and safety

– CostCost and consequencesconsequences of errors in requirements on the software-to-be, assumptions about its environment

SocialSocial impact– from user satisfaction

to degradation of working conditions

to system rejection



RE efforts often spent without guarantee of project contract being concluded

Pressure on tight schedules, short-term costs, catching up on technology

Too little work available on RE economics– Lack of quantitative data on RE benefits & cost savings– Progress in RE process is harder to measure than in

design, implementation

RDs are sometimes felt ...– big, complex, to be quickly outdated– too far away from the executable product customers

are paying for



More agile development may overcome some obstacles

– early & continuous provision of functionality of value to customer

– by reducing the req-to-code distance

Short RE cycles in spiral RE process, each directly followed by short implementation cycle

– Useful functional increment is elicited directly from the user

– Evaluation/spec/consolidation phases often shortcut (e.g. spec = test case on the implementation)

– Increment is implemented/tested by small team at same location, close to the user for instant feedback, using strict rules


Strong assumptions for agility to be successful

All stakeholder roles are reducible to one single role Project sufficiently small to be assignable to single, small, single-location

team (programmers/testers/maintainers) “User” can interact promptly & effectively Functionality can be provided quickly, consistently, incrementally from

essential to less important (no prioritization required) Non-functional aspects, environment assumptions, objectives, alternative

options, risks may receive little attention Little documentation required for work coordination & product

maintenance; requirements precision not required; verification before coding is less important than early release

Requirements changes are not likely to require major code refactoring

More/lessMore/less agility is achievable by less/moreless/more weight in elicitation, evaluation, documentation, consolidation phases of RE cycles


Setting the scene: summary

What is Requirements Engineering?– RE is concerned with the problem world only

– Scope: WHY, WHAT, WHO issues– Statement types: descriptive vs. prescriptive; requirements,

assumptions, domain properties, defs; satisfaction arguments

– Categories of requirements: functional, non-functional– RE is a spiral process; elicit-evaluate-specify-consolidate cycles driven

by corrections & evolving needs

– Multiple target qualities, defects to avoid --some are critical !

– Weight on each RE phase may depend on project type– Requirements impact on many software artefacts

Why engineer requirements?– Requirements-related errors are the most numerous, persistent,

expensive, dangerous– Technical, managerial, legal, economical, social impact of RE

Obstacles to good RE practice; agility in spiral RE

Documents

Www.wileyeurope.com/college/van lamsweerde Chap.1: Setting the Scene © 2009 John Wiley and Sons 1 Requirements Engineering From System Goals to UML Models