Chapter 6

Requirements Engineering
Process

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 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 2000 Software Engineering, 6th edition. Chapter 6 Slide 2

Requirements engineering
processes
 The processes used for RE vary widely
depending on the application domain, the
people involved and the organization
developing the requirements.
 However, there are a number of generic
activities common to most processes:
 Feasibility study
 Requirements elicitation and analysis
 Requirements specification
 Requirements validation

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 3

Feasibility study
 Determines whether or not the proposed
undertaking is worthwhile.
 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, 6th edition. Chapter 6 Slide 4

Feasibility study issues
 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?

(What are the relative benefits & costs, and what is absolutely required?)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 5

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

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 6

Problems of elicitation and
analysis
 Getting all, and only, the right people
involved.
 Stakeholders often don’t know what they
really want (“I’ll know when I see it”).
 Stakeholders express requirements in
their own terms.
 Stakeholders may have conflicting
requirements.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 7

Problems of elicitation and
analysis
 Requirements change during the
analysis process. New stakeholders may
emerge and the business environment
may evolve.
 Organizational and political factors
may influence the system requirements.
(Examples?)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 8

The elicitation and analysis
process

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 9

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 to organize
requirements).

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 10

Types of viewpoints
 Data sources or sinks – viewpoints are responsible
for producing or consuming data. Analysis involves
checking that assumptions about sources and sinks are valid.
 Representation frameworks – viewpoints
represented by different system models (i.e., dataflow, ER,
finite state machine, etc.). Each model yields different
insights into the system.
 Receivers of services – viewpoints are external to
the system and receive services from it. Natural to think of
end-users as external service receivers.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 11

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) (www.kare.org), Esprit project
 Sommerville’s Viewpoint-Oriented Requirements
Definition (VORD), and
 Thebaut’s Scenario-Based Requirements Engineering
(SBRE)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 12

Volere Requirements Process

Start here

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 13

Volere requirement shell

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 14

KARE workbench architecture

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 15

Sommerville’s VORD method

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 16

VORD standard forms
two points of reference

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 17

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 dealing with

fragmentary, incomplete, or conflicting
requirements.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 18

Scenario descriptions
 System state at the beginning of the
scenario.
 Sequence of events for a specific case of
some generic task the system is required
to accomplish.
 Any relevant concurrent activities.
 System state at the completion of the
scenario.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 19

A simple scenario
t0: The user enters values for input array A.
The values are [1, 23, -4, 7, 19]. The value
of output variable BIG remains ‘undefined’.
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].

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 20

Scenario-Based Requirements
Engineering (SBRE)
 Marcel support environment allows rapid
construction of an operational specification
of the desired system and its environment.
 Based on a forward chaining rule-based
language.
 An interpreter executes the specification to
produce natural language based scenarios
of system behavior.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 21

SBRE rule template

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 22

SBRE scenario generation

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 23

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, 6th edition. Chapter 6 Slide 24

 Scenario for a “start
transaction” event

different
scenarios
different
scenarios

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 25

UML use-cases and sequence
diagrams
 Use-cases are a graphical notation for
representing abstract scenarios in the
UML. (UML is the de facto standard for OO Analysis & Design)
 They identify the actors in an interaction
and describe the interaction itself.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 26

UML use-cases and sequence
diagrams
 A set of use-cases should describe all
types of interactions with the system.
 Sequence diagrams may be used to add
detail to use-cases by showing the
sequence of event processing.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 27

Library use-cases

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 28

 Catalogue management
sequence diagram

time

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 29

Social and organizational
factors
 All software systems are used in a social
and organizational context. This can
influence or even dominate the 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, 6th edition. Chapter 6 Slide 30

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. This may limit the type of
system interface used.
 Managerial responsibilities. Managers may have no
uninterrupted time when they can learn to use the system
 Organizational resistance. Middle managers who will be
made redundant may deliberately provide misleading or
incomplete information so that the system will fail.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 31

Ethnography
 A social scientists spends considerable time
observing and analyzing how people actually
work.
 People do not have to explain or 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.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 32

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, 6th edition. Chapter 6 Slide 33

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
validation is very important. (Fixing a
requirements error after delivery may
cost up to 100 times that of fixing an error
during implementation.)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 34

Requirements checking
 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, 6th edition. Chapter 6 Slide 35

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 8.
 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, 6th edition. Chapter 6 Slide 36

Requirements reviews /
inspections
 Regular reviews should be held while the
requirements definition is being formulated.
 Both client and contractor staff should be involved
in reviews. (Stakeholders)
 Reviews may be formal (with completed
documents) or informal. Good communication
between developers, customers and users can
resolve problems at an early stage. - goes beyond
reviews…

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 37

Review check-list
 Verifiability. Is the requirement realistically
testable?
 Comprehensibility. Is the requirement properly
understood?
 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, 6th edition. Chapter 6 Slide 38

Requirements management
 Requirements management is the process
of managing changing requirements
during the requirements engineering
process and system development.
 New requirements emerge during the
process as business needs change and a
better understanding of the system is
developed.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 39

Requirements management
 The priority of requirements from different
viewpoints changes during the development
process.
 The business and technical environment of
the system changes during its development.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 40

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, 6th edition. Chapter 6 Slide 41

Classification of requirements
 Mutable requirements – those that change
due to changes in the system’s (i.e., users’
organization) environment.
 Emergent requirements – those that emerge
as understanding of the system develops.
 Consequential requirements – those that
result from the introduction of the system.
 Compatibility requirements – those that
depend on other systems or (internal)
organizational processes.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 42

Requirements management
planning
 During requirements management
planning, you must decide on:
 Requirements identification – how requirements will be
individually identified.
 A change management process – a process to be
followed when analysing 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, 6th edition. Chapter 6 Slide 43

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. (or other sources)
 Requirements traceability – links between
dependent requirements.
 Design traceability – links from the requirements to the
design.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 44

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 the stages partially
automated.
 Traceability management – automated discovery
and documentation of relationships between requirements.
(keyword search, common scenarios, etc.)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 45

Requirements change
management
 Should apply to all proposed changes to
the requirements.
 Principal stages:
 Problem analysis – discuss identified requirements
problem and propose specific change(s).
 Change analysis and costing – assess effects of
change on other requirements.
 Change implementation – modify requirements
document and others to reflect change.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 46

Requirements change
management

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 47

Key points
 The requirements engineering process
includes a feasibility study, elicitation and
analysis, specification, and validation.
 Requirements analysis is an iterative
process involving domain understanding,
requirements collection, classification,
structuring, prioritization and validation.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 48

Key points
 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.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 49

Key points
 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, 6th edition. Chapter 6 Slide 50