Requirements Engineering

Processes

The goal of the requirements engineering process

is to create and maintain a system requirements
document

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

 Objectives

To describe the principal requirements
engineering activities and their relationships

To introduce techniques for requirements
elicitation and analysis

To describe requirements validation and the
role of requirements reviews

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 (2/2)
Requirements engineering activities:

Feasibility studies:
(Is the system useful to the business?)

Requirements elicitation and analysis
(The activity of discovering requirements)

Requirements validation
(Checking that the requirements actually define the
system that the customer wants)

Requirements management
(The activity of managing changing requirements)


Specification and Documentation
(are covered in chapter 6 and concern the
conversion of the requirements into some standard
form)
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 4
 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 5

 The requirements engineering process

Requir ements
Feasibility elicitation and
stud y
analysis
Requir ements
specification
Feasibility Requir ements
repor t validation

System
models

User and system

requirements

Requir ements
document

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

 An alternative to the requirements engineering
process: an iterative process around a spiral
Requirements
specification
System requirements •Three-stage activity;
specification and
modeling
Around the spiral the
User requirements
specification
requirements are developed
to different level of detail.
Business requirements
specification
For example, if the
System
prototyping activity, shown
under the requirements
requirements Feasibility
User
elicitation study
requirements
elicitation
Prototyping validation is extended to
iterative development, this
Requirements
elicitation
model allows the
Requirements
requirements and the
Reviews
validation

implementation to be
Syst em requirements
document
developed together.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 7
 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 already used.

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

 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 9

 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 10

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 11

 The requirements spiral for elicitation
and analysis process

Requirements Requirements
This iterative
process starts from
classification and prioritization and
organisation negotiation

requirements
discovery and ends
Requirements
discovery
Requirements
documentation with requirements
documentation.

See next slide …

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 12
 Process activities

Requirements discovery
• Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.

Requirements classification and organisation
• Groups related requirements and organises them into coherent
clusters.
• For example, it is possible to use model of the system architecture to identify
subsystem and grouping related requirements.

Prioritisation and negotiation
• Prioritising requirements and resolving requirements conflicts.
• For example it is possible to organize stakeholders negotiations so that
compromises can be reached.

Requirements documentation
• Requirements are documented and input into the next round of the
spiral. The documentation can be formal or informal.
• For example, extreme programming uses formal documents and cards and it is
very easy for stakeholders to handle, change and organise requirements.

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

 Requirements discovery

The process of gathering information about
the proposed and existing systems and
distilling the user and system requirements
from this information.

Sources of information include
documentation, system stakeholders and the
specifications of similar systems.

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

 ATM stakeholders, Domain and
interacting System
Stakeholders:

Bank customers

Representatives of other banks

Bank managers

Counter staff

Database administrators

Security managers

Marketing department

Hardware and software maintenance engineers

Banking regulators
Moreover, we have already seen that requirements may
come from the application Domain and from other
System that interact with the application being specified.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 15
 Requirements discovery and
viewpoints

All the previous requirements sources can be
represented as system viewpoints.

Viewpoints are a way of structuring the
requirements to represent the
perspectives of different stakeholders.
Stakeholders and other sources may be
classified under different 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 16

 Types of viewpoint

Interactor viewpoints
• People or other systems that interact directly with the
system. In an ATM, the customer’s and the account
database are interactor VPs.

Indirect viewpoints
• Stakeholders who do not use the system themselves but
who influence the requirements. In an ATM, management
and security staff are indirect viewpoints.

Domain viewpoints
• Domain characteristics and constraints that influence the
requirements. In an ATM, an example would be
standards for inter-bank communications.

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

 Viewpoint identification

Since it may be difficult the identification of the
viewpoint ….. It could be helpfully identify viewpoints
using:
• Providers and receivers of system services;
• Systems that interact directly with the system being
specified;
• Regulations and standards;
• Sources of business and non-functional requirements.
• Engineers who have to develop and maintain the system;
• Marketing and other business viewpoints.

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

 LIBSYS viewpoint hierarchy

All VPs

Indirect Interactor Domain

Library Article Library UI Classification

Finance Users
manager providers staff standards system

System
Students Staff External Cataloguers
managers

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

 Requirements discovery and
interviewing

In formal or informal interviewing, the RE
team puts questions to stakeholders about
the system that they use and the system to
be developed.

There are two types of interview
• Closed interviews where a pre-defined set of
questions are answered.
• Open interviews where there is no pre-defined
agenda and a range of issues are explored with
stakeholders.

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

 Interviews in practice

Normally a mix of closed and open-ended
interviewing.

Interviews are good for getting an overall
understanding of what stakeholders do and how
they might interact with the system.

Interviews are not good for understanding domain
requirements for two reasons:
• Requirements engineers cannot understand specific
domain terminology;
• Some domain knowledge is so familiar that people find it
hard to articulate or think that it isn’t worth articulating.

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

 Effective interviewers

Interviewers should be open-minded, willing
to listen to stakeholders and should not have
pre-conceived ideas about the requirements.

They should prompt the interviewee with a
question or a proposal and should not simply
expect them to respond to a question such
as ‘what do you want’. Most people find it
much easier to talk in a defined context rather
than in general terms.

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

 Requirements discovery and
scenarios (1/2)

People usually find it easier to relate to real-life examples
than to abstract description.


They can understand and critique a scenario of how they
can interact with the system.

That is, scenario can be particularly useful for adding detail
to an outline requirements description:
• they are description of example interaction sessions;
• each scenario covers one or more possible interaction;

Several forms of scenarios have been developed, each of

which provides different types of information at different
level of detail about the system.

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

 Requirements discovery and
scenarios (2/2)

Scenarios are real-life examples of how a
system can be used.

They should include
• A description of the starting situation;
• A description of the normal flow of events;
• A description of what can go wrong;
• Information about other concurrent activities;
• A description of the state when the scenario
finishes.

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

 LIBSYS scenario (1/2)
Scenario may be informal and may be written
as text.
Initial assumption: The user has logged on to the LIBSYS system and has located the journal containing
the copy of the article.
Normal: The user selects the article to be copied. He or she is then prompted by the system to ei ther
provide subscriber information for the journal or to indicate how they will pay for the article. Alternative
payment methods are by credit card or by quoting an organisational account number.
The user is then asked to fill in a copyright form that maintains details of the transaction and they then
submit this to the LIBSYS system.
The copyright form is c hecked and, if OK, the PDF version of the article is downloaded to the LIBSYS
working area on the userÕscomputer and the user is informed that it is available. The user is asked to select
a printer and a copy of the article is printed. If the article has been flagged as Ōprint-onlyÕit is deleted from
the userÕs system once the user has confirmed that printing is complete.

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

 LIBSYS scenario (2/2)
What can go wrong: The user may fail to fill in the copyright form correctly. In this case, the form should
be re-presented to the user for correction. If the resubmitted form is s till incorrect then the userÕsrequest
for the article is rejected.
The payment may be rejected by the system. The userÕs er quest for the article is rejected.
The article download may fail. Retry until successful or the user terminates the session.
It may not be possible to print the article. If the article is not flagged as Ōprint-onlyÕthen it is held in the
LIBSYS workspace. Otherwise, the article is deleted and the userÕs account credited with the cost of the
article.
Other activities: Simultaneous downloads of other articles.
System state on completion: User is logged on. The downloaded article has been deleted from LIBSYS
workspace if it has been flagged as print-only.

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

 Scenarios

Scenarios described as text might be
supplemented by some kind of diagrams,
screen-shot and so on.

Alternatively, a more structured approach
such as event scenarios and/or use-case
may be adopted.

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

 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.


Actors are represented as stick figures.


Each class of interaction is represented as a
named ellipse.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 28
 Use cases

A set of use-cases may be used to represent
all of the possible interactions in the system.

Avoiding confusion between use-cases
and scenarios:
• Use-cases identify the interactions with the
system and they can be documented with text
or linked to UML models.
• 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 29

 Scenarios

Scenarios show:
• The actors involved in the interaction;
• The objects they interact with;
• The operations associated with these objects.

It is worthwhile noticing that the terms
object it is used to indicate an instance
of a class or an instance of a general
system component.

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

 Article printing use-case

Article printing

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

 LIBSYS use cases

Article search

Library Article printing

User

User administration Library

Staff

Supplier Catalogue services

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

 Print article sequence
item: copyrightF orm: myWorkspace: myPrinter:
Article Form Workspace Printe r

User

request
request

complete
return

copyright OK

deliver

article OK

print send

inform confirm

delete

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

 Use-cases and scenarios (1/2)

Scenarios and use-cases are effective
technique for eliciting requirements for
interactor viewpoints. In fact each
interaction can be represented as a use-
case supplemented by scenarios.

They may also be used for indirect
viewpoint when these viewpoint receive
some result. For example consider the
Library Manager of our example.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 34
 Use-cases and scenarios (2/2)

Due to their “low-level nature” in this
context (requirements engineering process),
scenarios and use-cases are not so
effective
• for discovering constraints and/or high-
level non-functional requirements;
• for discovering domain requirements.

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

 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 should immerse him or herself
in the working environment where the system will
be used and must be sensitive to these factors

Currently no systematic way to tackle their
analysis.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 36
 Ethnography

An expert in social branch spends a considerable time
observing and analysing how people actually work.

In this way it is possible to discover implicit system
requirements.

People do not have to explain or articulate detail about their
work. In fact people often find it difficult to detail their
works because it is second nature to them.

An unbiased observer may be suitable to find out social and
important organisational factors (that are not obvious to
individuals).

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 37

 Ethnography and prototyping

Ethno g raphic Debriefing Focused

analysis meetings ethno g raph y
Prototype
evaluation
Generic system System
de velopment proto yping

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

 Scope of ethnography
To summarize the discussion, we can say that
ethnography is particularly effective at
discovering two type of requirement:
1. 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.
2. Requirements that are derived from
cooperation and awareness of other people’s
activities.

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

 Requirements validation

Concerned with demonstrating that the requirements
define the system that the customer really wants.

Requirements validation covers a part of analysis in
that it is concerned with finding problems with
requirements.

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.
• In fact, a change to the requirements usually means that the
system design and the implementation must also be changed
and the testing has to be performed again.

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

 Checks required during the
requirements validation process

Validity checks. Does the system provide the
functions which best support the customer’s needs?
( Other functions maybe identified by a further analysis )

Consistency checks. Are there any requirements
conflicts?

Completeness checks. Are all the requirements
needed to define all functions required by the
customer sufficiently specified?

Realism checks. Can the requirements be
implemented given available budget, technology
and schedule?

Verifiability. Can the requirements be checked?
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 43
 Requirements validation techniques
The following techniques can be used individually or in
conjunction.

Requirements reviews
• Systematic manual analysis of the requirements
performed by a team of reviewers (see next slides).

Prototyping
• Using an executable model of the system to check
requirements.

Test-case generation
• Developing tests for requirements to check testability.
• If the test is difficult to design, usually the related
requirements are difficult to implement.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 44
 Requirements reviews

A requirements review is a manual process that
involves both client and contractor staff should be
involved in reviews.

In other words these people should discuss.

Regular reviews should be held while the
requirements definition is being formulated.

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 45
 Formal and informal reviews

Informal reviews(without agenda) simply
involve contractors discussing requirements
with as many system stakeholders as possible;

Formal reviews(with agenda) the
development team should “take” the client
through
• the system requirements and
• explaining the implications of each requirements.

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

 Checks that should be performed by
reviews

Verifiability. Is the requirement realistically testable?

Comprehensibility. Is the requirement properly
understood?

Traceability. Is the origin of the requirement clearly
stated? It might be necessary to go back to the
source of a requirement to assess the impact of the
change.

Adaptability. Can the requirement be changed
without a large impact on other requirements?

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

 Requirements validation outputs

The requirements validation process should
be output a report which point out
potentially conflicts, contradictions, errors
and omissions.

Then it is up to the user, the contractor stuff,
the developers to negotiate a solution to
the reported problems.

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

 Requirements management

The requirements for large systems are frequently
changing.

In fact, during the software process, the stakeholders’
understanding of the problem is constantly changing.

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 management

It is hard for the users and customers to
anticipate what effects the new system will have
on the organization.


Often, only when the system has been
deployed, new requirements inevitably emerge.


This is mainly due to the fact that, when the end-
users have experience of the new system, they
discover new needs and priority.

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

 Requirements change
1. The priority of requirements from different
viewpoints changes during the development
process. Conflicts have to inevitably converge in
a compromise.
2. System customers may specify requirements from
a business perspective that conflict with end-
user requirements.
3. The business and technical environment of the
system changes during its development.
4. New hardware, new interface, business priority,
new regulations, etc.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 51
 Requirement changes and the
requirements management

The requirements management is the process of

identifying, understanding and controlling changes
to system requirements.

It might be useful to keep track of individual
requirements and maintain links between
dependent requirements so that you can asset the
impact of requirements changes.

The process of requirements management should
start as soon as a draft a version of the
requirement document is available.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 52
 Requirements evolution

Initial Changed
understanding understanding
of pr ob lem of prob lem

Initial Changed
requir ements requir ements

Time

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

 Enduring and volatile requirements

From an evolution perspective, requirements fall into two
classes:

Enduring requirements. Stable requirements derived from
the core activity of the customer organisation and relate
directly to the domain of the system.
• E.g., In a hospital, requirements will always relate to doctors,
nurses, etc.
• These requirements may be derived from a domain conceptual
models that show entities and relations between them.

Volatile requirements. Requirements which change during
development or when the system is in use.
• E.g., In a hospital, requirements derived from healthcare policy;

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

 A possible classification of volatile
requirements

Requirement Description
Type
Mutable Requirements that change because of changes to the environment in which the
requirements organisation is operating. For example, in hospital systems, the funding of patient
care may change and thus require different treatment information to be collected.
Emergent Requirements that emerge as the customer's understanding of the system develops
requirements during the system development. The design process may reveal new emergent
requirements.
Consequential Requirements that result from the introduction of the computer system. Introducing
requirements the computer system may change the organisations processes and open up new ways
of working which generate new system requirements
Compatibility Requirements that depend on the particular systems or business processes within an
requirements organisation. As these change, the compatibility requirements on the commissioned
or delivered system may also have to evolve.

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

 Requirements management planning

Since the RE process is very expensive, it might be useful to
establish a planning.

In fact, during the requirements engineering process, you
have to plan:
• Requirements identification
• How requirements are individually identified; they should be uniquely
identified in order to keep a better traceability.
• A change management process
• The process followed when requirements change: the set of activities
that estimate the impact and cost of changes.
• Traceability policies
• The policy for managing the amount of information about relationships
between requirements and between system design and
requirements that should be maintained (e.g., in a Data Base)
• CASE tool support
• The tool support required to help manage requirements change; tolls
can range from specialist requirements management
systems to simple data base systems.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 7 Slide 56
 Traceability

Traceability is concerned with the relationships between requirements,
their sources and the system design.


There are three type of traceability information that should be
maintained:
1. Source traceability
• Links from requirements to stakeholders who proposed these requirements;
• Links from requirements to rationale of the requirements themselves;
2. Requirements traceability
• Links between dependent requirements; a change to a requirement may
propagate to its dependent requirements.
3. Design traceability
• Links from the requirements to the design; these links are used to assess
the impact of a requirements change to system design and
implementation.

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

 A traceability matrix

A traceability matrix may be maintained to keep traceability
information which relate requirements to sources, each other
and design module

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

 CASE tool support

Traceability matrix may be used for a small number of
requirements but it might become too expensive to maintain,
so often automated support is needed (e.g., DOORS,
RequisitePro).

These tool are needed for:


Requirements storage
• Requirements should be managed in a secure 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 (see next slides).

Traceability management
• Automated retrieval of the links between requirements.

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

 Requirements change management

Formal process for change management should apply to all
proposed changes to the requirements in order to treat
consistently them.

Principal stages
• Problem analysis and change specification. Identify and
discuss requirements problem , propose change and provide
feedback to the change requestor;
• Change analysis and costing. Assess effects of change on
other requirements by traceability and estimate the cost in term of
modifications to the requirements document and to the system
design and implementation;
• Change implementation. Modify requirements document and, if
necessary, system design and implementation. For that reason
the requirement document should be modular and should minimize
external references.

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

 Change management

Identified Revised
problem Problem analysis and Change analysis Change requirements
change specification and costing implementation

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

 Key points

The requirements engineering process
includes a feasibility study, requirements
elicitation and analysis, requirements
specification and requirements management.

Requirements elicitation and 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 62

 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 63