Chapter 7

Requirements Engineering
Process

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 1

Objectives
 To describe the principal RE activities.
 To introduce techniques for requirements
elicitation and analysis.
 To describe requirements validation.
 To discuss the role of requirements
management in support of other RE
processes.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 2

RE processes…
 Vary widely depending on:
 Application domain
 People involved
 Organization developing the requirements
 Generic activities common to most:
 Feasibility study
 Requirements elicitation and analysis
 Requirements specification core, iterative
 Requirements validation activities

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 3

RE Process Model

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 4

Spiral RE Process Model

Emphasizes iterative nature Requiremen ts

sp ecificatio n

of core activities Sy stem requiremen ts

sp ecificatio n an d
modelin g

User requirements
sp ecificatio n

Busin ess requirements

sp ecificatio n

Sy stem
requirements Feasibility
User study
elicitatio n requirements
elicitatio n
Pro toty ping

Requiremen ts
elicitatio n Requiremen ts
Rev iews
v alidation

Sy s te m re quire me nts
docum ent

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 5

Feasibility Study
Feasibility study issues

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 6

Feasibility study
 Aims to answer three basic questions:
 Would the system contribute to overall
organizational objectives?
 Could the system be engineered using
current technology and within budget?
 Could the system be integrated with other
systems already in use?

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 7

Feasibility study issues (a high-
level checklist)
 How would the organization cope if the system
wasn’t implemented?
 What are the current process problems and how
would the system help with these?
 What will the integration problems be?
 Is new technology needed? New skills?
 What must be supported by the system, and what
need not be supported?

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 8

Elicitation and Analysis
Problems
Process activities
Viewpoint-oriented elicitation
Method-based RE
Interviewing
Scenarios
Social and organizational factors
Ethnography & focused ethnography

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 9

Elicitation and analysis
 Involves working with customers to learn
about the application domain, the
services needed and the system’s
operational constraints, etc.
 May also involve end-users, managers,
maintenance personnel, domain
experts, trade unions, etc. (That is, other
stakeholders.)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 10

Problems of elicitation and
analysis
 Getting all, and only, the right people involved
 Stakeholders often:
 don’t know what they really want
 express requirements in their own terms.
 have conflicting or competing requirements.
 Requirements naturally change as insight
improves. (Should this really be thought of as a problem?)
(cont'd)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 11

Problems of elicitation and
analysis (cont’d)
 New stakeholders may emerge.
 Political or organizational factors may affect
requirements. (Examples?)
 The environment may evolve during the RE
process.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 12

Elicitation and analysis
process activities
 Requirements discovery
 Interacting with stakeholders to discover product and
domain requirements
 Requirements classification and organization
 Grouping and organizing requirements to facilitate
analysis
 Prioritization and negotiation
 Prioritizing requirements and resolving requirements
conflicts.
 Requirements documentation
 Requirements are documented and input into the
next round of the spiral.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 13

Elicitation and Analysis spiral

Requiremen ts Requiremen ts
classificatio n an d p rioritization and
o rgan isation n ego tiation

Requiremen ts Requiremen ts
discov ery documen tation

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 14

Viewpoint-oriented elicitation
 Stakeholders represent different ways of
looking at a problem (“viewpoints”).
 A multi-perspective analysis is important
as there is no single correct way to analyze
system requirements.
 Provides a natural way to structure the
elicitation process and organize
requirements.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 15

Types of viewpoints
 Interactor viewpoints
 People or other systems that interact directly
with the system.
 Indirect viewpoints
 Stakeholders who do not use the system
themselves but who influence the requirements.
 Domain viewpoints
 Domain characteristics and constraints that
affect the requirements.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 16

Method-based RE
 “Structured methods” to elicit, analyze,
and document requirements. Suzanne & James
part of “SA/SD” Robertson, Atlantic
 Examples include: Systems Guild
 Ross’ Structured Analysis (SA),
 Volere Requirements Process (www.volere.co.uk)
 Knowledge Aquisition and Sharing for Requirement
Engineering (KARE) Esprit project
(http://cordis.europa.eu/esprit/home.html),
 Sommerville’s Viewpoint-Oriented Requirements
Definition (VORD), and
 Thebaut’s Scenario-Based Requirements Engineering
(SBRE)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 17

Volere Requirements Process

Start here

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 18

Volere requirement shell

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 19

KARE workbench architecture

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 20

Sommerville’s VORD method

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 21

VORD standard forms
two points of reference

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 22

Interviewing
 RE’s meet with stakeholders to discuss
the system currently in place and the
system to be developed.
 May be:
 formal or informal
 closed (with a pre-defined agenda), open
(no pre-defined agenda), or a mix
 Useful for learning how stakeholders
might affect or be affected by the system.
(cont'd)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 23

Interviewing (cont’d)
 Less useful for learning about domain
requirements since:
 RE’s may not understand domain-specific
terminology;
 stakeholders may not communicate such
requirements because they are so obvious
(to the stakeholders)
 Gause & Weinberg (“Exploring Requirements:
Quality Before Design,” Dorset House, 1989) describe
many useful interviewing techniques.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 24

Scenarios
 Depict examples or scripts of possible
system behavior
 People often relate to these more readily
than to abstract statements of requirements
“Give me an example to help tie the parts together” (into a coherent
whole.)

 Particularly useful in elucidating fragmentary,

incomplete, or conflicting requirements

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 25

Scenario elements
1. System state at the beginning of the
scenario (if relevant)
2. Sequence of events for a specific case
of some generic task the system is
required to accomplish.
3. Any relevant concurrent activities.
4. System state at the completion of the
scenario.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 26

A simple scenario
t0: The user enters values for input array A.
The values are [1, 23, -4, 7, 19].
t1: The user executes program MAX.
t2: The value of variable BIG is 23 and the
values of A are [1, 23, -4, 7, 19].

(Compare this to the interface and operational specification

examples from the Chap. 6 lecture notes.)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 27

Scenario-Based Requirements
Engineering (Thebaut)
 A CASE tool supports the rapid construction
of an operational specification of the desired
system and its environment.
 Utilizes a forward chaining, parallel, rule-
based language.
 An interpreter executes the specification to
produce natural language based scenarios
of system behavior.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 28

Scenario representation in
VORD (Sommerville)
 VORD supports the graphical description
of multi-threaded “event scenarios” to
document system behavior:
 Data provided and delivered
 Control information
 Exception processing
 The next expected event
 Multi-threading supports description of
exceptions. (blurs the distinction between scenarios
and operational specifications)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 29

Scenario for a “start
transaction” event

different
scenarios
different
scenarios

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 30

UML use-cases and sequence
diagrams
 Graphical notations for representing
abstract scenarios in the UML. (UML is the de
facto standard for OO Analysis & Design)

 Identify actors in an interaction and

describe the interaction itself.
 A set of use-cases should describe all
types of interactions with the system.
 Sequence diagrams show the sequence
of event processing.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 31

Library use-cases

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 32

 Catalogue management
sequence diagram

time

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 33

Social and organizational
factors
 All software systems are used in a social
and organizational context. This can
influence or even dominate system
requirements.
 Good analysts must be sensitive to these
factors, but there is currently no
systematic way to tackle their analysis.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 34

Example
• Consider a system which allows senior manage-
ment to access information without going through
middle managers.
 Managerial status – Senior managers may feel that
they are too important to use a keyboard.
 Managerial responsibilities – Managers may not have
time to learn how to use the system
 Organizational resistance – Middle managers who will
be made redundant may deliberately provide
misleading or incomplete information so the system
will fail.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 35

Ethnography
 A social scientist observes and analyzes how
people actually work.
 Subjects do not have to explain or otherwise
articulate what they do.
 Social and organizational factors of importance
may be observed.
 Ethnographic studies have shown that work is
usually richer and more complex than
suggested by simple system models.
(Good for studying existing practices, but how will things
change when the new system is introduced?)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 36

Focused ethnography
 Developed during a project studying the air traffic
control process.
 Combines ethnography with prototyping.
 Prototype development raises issues which focus
the ethnographic analysis.
 Problem with ethnography alone: it studies
existing practices which may not be relevant
when a new system is put into place.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 37

Requirements Validation
attributes
techniques

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 38

Requirements validation
 Concerned with whether or not the
requirements define a system that the
customer really wants. (as opposed to needs?)
 Requirements error costs are high, so
early validation is very important.
(Fixing a requirements error after delivery
may cost 100 times that of fixing an error
during implementation.)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 39

Requirements attributes
 Validity: Does the system provide the functions
which best support the customer’s needs? (as opposed
to wants?)
 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 tested?
(More precisely, can the system be tested to determine
whether or not the requirements are met?)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 40

Requirements validation
techniques
 Requirements reviews / inspections –
systematic manual analysis of the requirements.
 Prototyping – using an executable model of the
system to check requirements. Covered in Chapter 17.
 Test-case generation – developing tests for
requirements to check testability.
 Automated consistency analysis – checking
the consistency of a structured requirements description.
(CASE – e.g., “Wisdom” tool in KARE workbench)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 41

Requirements reviews /
inspections
 Regular reviews should be held while require-
ments are being formulated.
 Both client and contractor staff should be
involved in reviews. (+ other stakeholders…who?)
 Reviews may be formal or informal…
 Good communication between developers,
customers and users can resolve problems at
an early stage.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 42

Review check-list
 Verifiability: Is the requirement testable?
 Comprehensibility: Is the requirement
understandable?
 Traceability: Is the origin of the requirement
clearly stated? and rationale!

 Adaptability: Can the requirement be

changed with minimum impact on other
requirements? (Especially when change is anticipated!)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 43

Requirements Management
Enduring vs. volatile requirements
Planning considerations
Traceability
CASE support
Change management process

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 44

Requirements management…
 …is the process of understanding and
controlling requirements change.
 Requirements evolve, priorities change,
and new requirements emerge as
 a better understanding of the system is
developed, and
 the business and technical environment of
the system changes.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 45

Enduring and volatile
requirements
 Enduring requirements: Stable
requirements derived from the core activity of the
customer organization. (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. (E.g., requirements derived from the
latest health-care policy.)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 46

Types of volatile requirements
 Mutable – those that change due to changes
in the organization’s operating environment.
 Emergent – those that emerge as a better
understanding of the system develops.
 Consequential – those that result from the
introduction of the system.
 Compatibility – those that change due to
changing systems or processes within the
organization.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 47

Requirements management
planning requires decisions on:
 Requirements identification – how
requirements will be individually identified
 A change management process – to be
followed when analyzing the impact and costs of
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 2000 Software Engineering. Chapter 7 Slide 48

Traceability…
 …is concerned with the relationships
between requirements, their sources, and
the system design.
 Types of traceability:
 Source traceability – links from requirements to
stakeholders who proposed the requirements. (or other sources)
 Requirements traceability – links between dependent
requirements.
 Design traceability – links from the requirements to the
design.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 49

CASE tool support
 Requirements storage – in a secure, managed
data store
 Change management – a workflow process
whose stages can be defined and information flow between
the stages partially automated
 Traceability management – automated
discovery and documentation of relationships between
requirements (keyword search, common scenarios, etc.)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 50

Change management process
 Applied to all proposed requirements
changes
 Principal stages:
 Problem analysis – analyze identified
requirements problem and propose specific
change(s)
 Change analysis and costing – assess effects
of change on other requirements
 Change implementation – modify requirements
document (+ system design and implementation,
as necessary) to reflect the change

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 51

Change management process
(cont’d)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 52

Key points
 The RE process includes a feasibility study,
elicitation and analysis, specification, and
validation.
 Elicitation and analysis involves
requirements discovery, classification and
organization, prioritization and negotiation, and
documentation.

(cont'd)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 53

Key points (cont’d)
 Systems have multiple stakeholders with
different viewpoints and requirements.
 Social and organization factors influence
system requirements.
 Requirements validation is concerned with
checks for validity, consistency, complete-
ness, realism, and verifiability.

(cont'd)

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 54

Key points (cont’d)
 Business, organizational, and technical
changes inevitably lead to changing
requirements.
 Requirements management involves
careful planning and a change manage-
ment process.

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 55

 Chapter 7

Requirements Engineering
Process

©Ian Sommerville 2000 Software Engineering. Chapter 7 Slide 56