Requirements Engineering Processes

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  1
 Objectives
● To describe the principal requirements
engineering activities
● To introduce techniques for requirements
elicitation and analysis
● To describe requirements validation
● To discuss the role of requirements
management in support of other
requirements engineering processes

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  2
 Topics covered
● Feasibility studies
● Requirements elicitation and analysis
● Requirements validation
● Requirements management

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  3
 Requirements engineering processes
● The processes used for RE vary widely
depending on the application domain, the
people involved and the organisation
developing the requirements
● However, there are a number of generic
activities common to all processes
• Requirements elicitation
• Requirements analysis
• Requirements validation
• Requirements management

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  4
 FaearsstiuipbbodrllttyyR
eF elicqutnairleyom n
tsi asdR
e
spq uc ir
fe m
a in
ot sRe
vqa u
l i
r
dem
n
a
t
ots
S
sm ytodem
The requirements engineering process

lU seqr uainedm
 syntesm
R
edqoucirem
nts
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  5
 Feasibility studies
● A feasibility study decides whether or not the
proposed system is worthwhile
● A short focused study that checks
• If the system contributes to organisational
objectives
• If the system can be engineered using current
technology and within budget
• If the system can be integrated with other
systems that are used

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  6
 Feasibility study implementation
● Based on information assessment (what is required),
information collection and report writing
● Questions for people in the organisation
• What if the system wasn’t implemented?
• What are current process problems?
• How will the proposed system help?
• What will be the integration problems?
• Is new technology needed? What skills?
• What facilities must be supported by the proposed
system?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  7
 Elicitation and analysis
● Sometimes called requirements elicitation or
requirements discovery
● Involves technical staff working with customers to
find out about the application domain, the services
that the system should provide and the system’s
operational constraints
● May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  8
Problems of requirements analysis
● Stakeholders don’t know what they really want
● Stakeholders express requirements in their own
terms
● Different stakeholders may have conflicting
requirements
● Organisational and political factors may influence the
system requirements
● The requirements change during the analysis
process. New stakeholders may emerge and the
business environment change

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  9
 D o m a
i
n R
e
vqu
ai
lr
e
dm
a
ti
o nts R
e
q
u
d
f
n
s
p
ci
r
e
m
t
o
 n
t
s
a
d
i
P
ro u
n
cnteysRd ers t d g Pr
i
o
t
iz
a
i
o
n
The requirements analysis process

ecqoulirecm n
ttosC
lasifcation C
o
n
f
r
e
s
ul
i
c
t
o
n
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  10
 Process activities
● Domain understanding
● Requirements collection
● Classification
● Conflict resolution
● Prioritisation
● Requirements checking

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  11
 System models
● Different models may be produced during the
requirements analysis activity
● Requirements analysis may involve three structuring
activities which result in these different models
• Partitioning. Identifies the structural (part-of) relationships
between entities
• Abstraction. Identifies generalities among entities
• Projection. Identifies different ways of looking at a
problem
● System models covered in Chapter 7

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  12
 Viewpoint-oriented elicitation
● Stakeholders represent different ways of
looking at a problem or problem viewpoints
● This multi-perspective analysis is important
as there is no single correct way to analyse
system requirements

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  13
 Banking ATM system
● The example used here is an auto-teller system
which provides some automated banking services
● I use a very simplified system which offers some
services to customers of the bank who own the
system and a narrower range of services to other
customers
● Services include cash withdrawal, message passing
(send a message to request a service), ordering a
statement and transferring funds

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  14
 Autoteller viewpoints
● Bank customers
● Representatives of other banks
● Hardware and software maintenance engineers
● Marketing department
● Bank managers and counter staff
● Database administrators and security staff
● Communications engineers
● Personnel department

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  15
 Types of viewpoint
● Data sources or sinks
• Viewpoints are responsible for producing or consuming
data. Analysis involves checking that data is produced
and consumed and that assumptions about the source
and sink of data are valid
● Representation frameworks
• Viewpoints represent particular types of system model.
These may be compared to discover requirements that
would be missed using a single representation.
Particularly suitable for real-time systems
● Receivers of services
• Viewpoints are external to the system and receive
services from it. Most suited to interactive systems

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  16
 External viewpoints
● Natural to think of end-users as receivers of
system services
● Viewpoints are a natural way to structure
requirements elicitation
● It is relatively easy to decide if a viewpoint is
valid
● Viewpoints and services may be sued to
structure non-functional requirements

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  17
 Method-based analysis
● Widely used approach to requirements
analysis. Depends on the application of a
structured method to understand the system
● Methods have different emphases. Some are
designed for requirements elicitation, others
are close to design methods
● A viewpoint-oriented method (VORD) is used
as an example here. It also illustrates the
use of viewpoints

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  18
V
idnetw
p o
ifcantsV
itruecw
p o
itrngt doV
icum
ew
poaintosyV
itm
ew
p o
i anptg
The VORD method

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  19
 VORD process model
● Viewpoint identification
• Discover viewpoints which receive system services and
identify the services provided to each viewpoint
● Viewpoint structuring
• Group related viewpoints into a hierarchy. Common
services are provided at higher-levels in the hierarchy
● Viewpoint documentation
• Refine the description of the identified viewpoints and
services
● Viewpoint-system mapping
• Transform the analysis to an object-oriented design

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  20
 VORD standard forms
Viewpoint template Service template
Reference: The viewpoint name. Reference: The service name.
Attributes: Attributes  providing Rationale: Reason  why the service is
viewpoint information. provided.
Events: A reference to a set of  event Specification: Reference to a list of service
scenarios describing  how specifications. These  may
the  system reacts to be  expressed in different
viewpoint events. notations.
Services A reference  to a set of Viewpoints: List  of viewpoint names
service descriptions. receiving the service.
Sub­VPs: The names of  sub­ Non­functional Reference to  a set of non ­
viewpoints. requirements: functional  requirements
which constrain the service.
Provider: Reference to a list of system
objects  which provide the
service.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  21
Q
rbMue y
asulpnhcliesinA tG
r
a
n
se
ct
c
i
ooun
Ms
tan g
e
rC
u
s
t
o
d
a
b
M
e
sm
a
a
ge
srC
a
r
e
t
u
nr
d
i
g
S
o
fw
i
t
w C
t
h
a
ra
d
es
rh
w
a
l
R
e
m
s
o
f
u
p
go
t
e
w
a
r
dT
r
a
n
s
lc
o
gt
i
co
O
hn
rd
q e
us
siAU e f r
m
rnhtclofdauecnrtcto a i
on l
o si
z B
ta
n
k
e
l
r Inuv
sa
eli
rd
Viewpoint identification

S
l
a
ry
e
dnst
em  c
o
s
t
s
t
ac
O
r
d
e
mF
u
ns
t
tr
e
oi
g
n
m
rH
a
m
i
nP
d
w
t
ern
at
e
nce
MS
e
c
e
s
a
g
p
i
nu
r
i
t
y
er
eC
t a
nr d
i
on
R e m
tdiagnseicR o Updat
e F ud s
eliablityacountranfer vlC
©Ian Sommerville 2004
aird
tion
Software Engineering, 7th edition. Chapter 7                        Slide  22
 A
S
e
rW
iQ
iO
tS
h
u
e
rT
y
 O dH
lranndesrm C
va
w
b cLO
eU
D
 
l
a
n N
E
i
s
h
c
eR
tTF
C
U
S
e
W
i
t
h
d
Q
u
e
r
yO
R
E
S
T
r
v
i
c
e
a
w
 
b
lI
G
N
M
E
 
l
i
s
t
a
h
n
c
eRB
A
T
E
L
S
e
r
v
i
R
u
n
 
d
a
g
A
c
s
hN
K
E
R
c
e
 
l
i
s
n
ot
c
cf h
etisouq
u
senam
g
 ldisnt p
S
e
n
d
 
me
r
a
ge
Viewpoint service information

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  23
A
C
O
U
N
T
H
L
D
E
RSC
tC
a
rE
 S
n co
en
atro
sl i
cnpou
t C
leld strvnicaetinPD
a
r
d
IA
N
m
o
u
tM t
e
n i
n
ap
l
sut
 esagerquired
Viewpoint data/control

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  24
Q
 W u S
lith
rSy
de r
bva
wic e
n s
 ervicecsashA C
u
s
t
om
e
r Al
 
V
Ps B
a
n
k
 
s
t
a
f
Viewpoint hierarchy

O
rS
 T
eO d
n m h
e s q u
a
g
ardns fecrtiounm e
 ldisntc
h
lo
u
n
t
d
e
rF
o
c
ur
e
i
g
n
s
t
m
r T
el
r M
a
n
g
e
r E
n
g
i
e
r
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  25
 R
eA
fE r
tven
ibe unc
tts:sA e
:C
cP
tS
 Cu
ItE
t
e N
al
ns
r tc ou
tm
n
l ae
e r
s
rvucmt
i
e b
oe
nr R
S
pe
af
t
i
e
c r
o
i e
n
c
a
f e
l
a
t:
io
n:C
T
a
U
pa
o
n
d
s
e s
im
 h
r 
e
iw
p
d
c
n i
r
u
h
gt
oo
 h
v
t d
e er
 
p
sa
ccu
aw
s
 
t
a t
e
hl
o
r
ism
w 
w e
er
r
t 
k
v
hs
e
i
dcr
v
e
 
a
wi
bce
yl
S
eS
ru v
ib
c­V eP
ss::C r
a d s
  tra i o
s nc ti o
n b
a
cu
m
n tfo
i .
m T
r
e d q ay
uni r ,e
dn
.
f Tu ni
s
d  t
h
a
l ow
,
Customer/cash withdrawal templates

aB
sA
iF h
lucsretoinguw
cm h d ra
enet rhnoqlu w l
ideryV P
sN
:rP
on
­eq
fovird
u
n c
tem t
C
.:s:Dh
e
u
eo
lF  
sbt
ifi laema
ol
m
vdo n
e rc s
  iucnaltasbhe rw e lv er
ingthcon 1fm .
irnudte
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  26
 Scenarios
● Scenarios are descriptions of how a system
is used in practice
● They are helpful in requirements elicitation
as people can relate to these more readily
than abstract statement of what they require
from a system
● Scenarios are particularly useful for adding
detail to an outline requirements description

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  27
 Scenario descriptions
● System state at the beginning of the
scenario
● Normal flow of events in the scenario
● What can go wrong and how this is handled
● Other concurrent activities
● System state on completion of the scenario

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  28
 Event scenarios
● Event scenarios may be used to describe how a
system responds to the occurrence of some
particular event such as ‘start transaction’
● VORD includes a diagrammatic convention for event
scenarios.
• Data provided and delivered
• Control information
• Exception processing
• The next expected event

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  29
 C
aP
rIN
dR C a rd  p r
e e
q s
n
t
u
e
s
t
 
P
IN V a l i d 
c
a
r
d Us
e
r
 
O
K
A
c
o
n
u
mu
n
t
b
e
r V a lid a t e  us
e
r A
c
o
u
n
t
n
u
m
b
e
rS
e
lc
t
Event scenario - start transaction

iR
eR T
tInevtum e
ruarln o u t P
IN
 indc caardrd IIn
cnR
o
rco­rneecctt r P
IP
N s
r
v
ie
S
tR oalein card R tunard I
N
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  30
Notation for data and control analysis
● Ellipses. data provided from or delivered to a
viewpoint
● Control information enters and leaves at the
top of each box
● Data leaves from the right of each box
● Exceptions are shown at the bottom of each
box
● Name of next event is in box with thick edges

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  31
 Exception description
● Most methods do not include facilities for
describing exceptions
● In this example, exceptions are
• Timeout. Customer fails to enter a PIN within
the allowed time limit
• Invalid card. The card is not recognised and is
returned
• Stolen card. The card has been registered as
stolen and is retained by the machine

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  32
 Use cases
● Use-cases are a scenario based technique
in the UML which identify the actors in an
interaction and which describe the
interaction itself
● A set of use cases should describe all
possible interactions with the system
● Sequence diagrams may be used to add
detail to use-cases by showing the sequence
of event processing in the system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  33
 L
endig services
Lending use-case

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  34
 L
iU
bsraeyULe
n d i g 
s e rv i c e
Library use-cases

s
sC
eatr laodgm
i senrvsitrcaesionL
i
b
r
a
y
S
t
f
Suplier
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  35
 B
o
S k
s ho
p:
uplierA I
t
e
m
:
L
i
b
r
ay
 
I
t
em B
o
k
s
:
C
a
t
l
o
g C
a
L
it
l
o
g
b
r
y
 u
e
r
:
S
t
a
f
cquireC N
e
w
Catalogue management

a
tU
lncatloogg I Itteem
mDi
s
p
o
se
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  36
 Social and organisational factors
● Software systems are used in a social and
organisational context. This can influence or
even dominate the system requirements
● Social and organisational factors are not a
single viewpoint but are influences on all
viewpoints
● Good analysts must be sensitive to these
factors but currently no systematic way to
tackle their analysis

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  37
 Example
● Consider a system which allows senior management
to access information without going through middle
managers
• Managerial status. Senior managers may feel that they
are too important to use a keyboard. This may limit the
type of system interface used
• Managerial responsibilities. Managers may have no
uninterrupted time where they can learn to use the
system
• Organisational resistance. Middle managers who will be
made redundant may deliberately provide misleading or
incomplete information so that the system will fail

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  38
 Ethnography
● A social scientists spends a considerable time
observing and analysing how people actually work
● People do not have to explain or articulate their work
● Social and organisational factors of importance may
be observed
● Ethnographic studies have shown that work is
usually richer and more complex than suggested by
simple system models

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  39
 Focused ethnography
● Developed in a project studying the air traffic
control process
● Combines ethnography with prototyping
● Prototype development results in
unanswered questions which focus the
ethnographic analysis
● Problem with ethnography is that it studies
existing practices which may have some
historical basis which is no longer relevant

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  40
E
thanog
rlyasphG
idcenvrlioc psm D
e
b
r
i
e
f
n
g
m
t
s F
e
t
ho
n
ytnemprS
ycu
s
gre
ad
p
sotepmhyP
r
o
t
e
v
a
l
uy
p
e
i
o
n
Ethnography and prototyping

ing
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  41
 Scope of ethnography
● Requirements that are derived from the way
that people actually work rather than the way
I which process definitions suggest that they
ought to work
● Requirements that are derived from
cooperation and awareness of other people’s
activities

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  42
 Requirements validation
● Concerned with demonstrating that the
requirements define the system that the
customer really wants
● Requirements error costs are high so
validation is very important
• Fixing a requirements error after delivery may
cost up to 100 times the cost of fixing an
implementation error

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  43
 Requirements checking
● Validity. Does the system provide the functions
which best support the customer’s needs?
● Consistency. Are there any requirements conflicts?
● Completeness. Are all functions required by the
customer included?
● Realism. Can the requirements be implemented
given available budget and technology
● Verifiability. Can the requirements be checked?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  44
Requirements validation techniques
● Requirements reviews
• Systematic manual analysis of the requirements
● Prototyping
• Using an executable model of the system to check
requirements. Covered in Chapter 8
● Test-case generation
• Developing tests for requirements to check testability
● Automated consistency analysis
• Checking the consistency of a structured requirements
description

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  45
 Requirements reviews
● Regular reviews should be held while the
requirements definition is being formulated
● Both client and contractor staff should be
involved in reviews
● Reviews may be formal (with completed
documents) or informal. Good
communications between developers,
customers and users can resolve problems
at an early stage

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  46
 Review checks
● Verifiability. Is the requirement realistically
testable?
● Comprehensibility. Is the requirement
properly understood?
● Traceability. Is the origin of the requirement
clearly stated?
● Adaptability. Can the requirement be
changed without a large impact on other
requirements?

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  47
 R
in aRe qu
foepqm ir e mn
auoicrle sm t
g
ns
u
a
e
torsR
Automated consistency checking

pR
e
q
u
i
r
e
r
o
b
l
R
e
q
u
i
r
e
a
n
l
ym
n
t
 
p
o
m
n
t
s
rs
r
s
eqduaitrebm n
tass
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  48
 Requirements management
● Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development
● Requirements are inevitably incomplete and
inconsistent
• New requirements emerge during the process as
business needs change and a better understanding of the
system is developed
• Different viewpoints have different requirements and
these are often contradictory

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  49
 Requirements change
● The priority of requirements from different
viewpoints changes during the development
process
● System customers may specify requirements
from a business perspective that conflict with
end-user requirements
● The business and technical environment of
the system changes during its development

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  50
 Iuodf eIpn
irnsiottbaanlld
i
e
m g C
h
a
u
n
d
e
r
s
o
f
 
pn
t
og
b
Ce
ld
hi
n
m
ag
n
g
e
d
requrem nts requirm
ntT
sim
Requirements evolution

©Ian Sommerville 2004
e
Software Engineering, 7th edition. Chapter 7                        Slide  51
Enduring and volatile requirements
● Enduring requirements. Stable requirements
derived from the core activity of the customer
organisation. E.g. a hospital will always have
doctors, nurses, etc. May be derived from
domain models
● Volatile requirements. Requirements which
change during development or when the
system is in use. In a hospital, requirements
derived from health-care policy

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  52
 Classification of requirements
● Mutable requirements
• Requirements that change due to the system’s
environment
● Emergent requirements
• Requirements that emerge as understanding of the
system develops
● Consequential requirements
• Requirements that result from the introduction of the
computer system
● Compatibility requirements
• Requirements that depend on other systems or
organisational processes

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  53
 Requirements management planning
● During the requirements engineering process, you
have to plan:
• Requirements identification
• How requirements are individually identified
• A change management process
• The process followed when analysing a requirements
change
• Traceability policies
• The amount of information about requirements relationships
that is maintained
• CASE tool support
• The tool support required to help manage requirements
change

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  54
 Traceability
● Traceability is concerned with the relationships
between requirements, their sources and the system
design
● Source traceability
• Links from requirements to stakeholders who proposed
these requirements
● Requirements traceability
• Links between dependent requirements
● Design traceability
• Links from the requirements to the design

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  55
 A traceability matrix

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  56
 CASE tool support
● Requirements storage
• Requirements should be managed in a secure, managed
data store
● Change management
• The process of change management is a workflow
process whose stages can be defined and information
flow between these stages partially automated
● Traceability management
• Automated retrieval of the links between requirements

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  57
 Requirements change management
● Should apply to all proposed changes to the
requirements
● Principal stages
• Problem analysis. Discuss requirements
problem and propose change
• Change analysis and costing. Assess effects of
change on other requirements
• Change implementation. Modify requirements
document and other documents to reflect
change

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  58
Id
epronbtilfem
dP
rcho
b
langem
 span
lecy
sfi taondC
handgec oasntilygsi imC h
a
n
g
pleme r
q
taionR
e
v
i
s
e
d
u
r
m
nt
s
Requirements change management

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  59
 Key points
● The requirements engineering process
includes a feasibility study, requirements
elicitation and analysis, requirements
specification and requirements management
● Requirements analysis is iterative involving
domain understanding, requirements
collection, classification, structuring,
prioritisation and validation
● Systems have multiple stakeholders with
different requirements

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  60
 Key points
● Social and organisation factors influence
system requirements
● Requirements validation is concerned with
checks for validity, consistency,
completeness, realism and verifiability
● Business changes inevitably lead to
changing requirements
● Requirements management includes
planning and change management

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7                        Slide  61