Software

Engineering

Requirements Engineering
Processes

12/15/2022 Software Engineering 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

12/15/2022 Software Engineering 2

 Requirements Engineering Processes

The processes used for requirements engineering 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 which we look at today.
The goal of this stage of the software engineering
process is to help create and maintain a system
requirements document.

12/15/2022 Software Engineering 3

Requirements Engineering Processes

Requirements elicitation;
What services do the end-users require of the system?
Requirements analysis;
How do we classify, prioritise and negotiate
requirements?
Requirements validation;
Does the proposed system do what the users require?
Requirements management.
How do we manage the (sometimes inevitable) changes
to the requirements document?

12/15/2022 Software Engineering 4

Example
Patient records system
(Elicitation) 1.Talk to patients, doctors, nurses, receptionists, managers to
find out
Current system practise, legal restrictions DPA, problems with current system,
needs for improvement, security issues, costs
(Specification) 2.Develop draft documentation and review what is most
important, what will it cost, what is the timescale, is new hardware required
(Validation) 3.Send requirements to end users. Present them with Q&A.
Go back to step 1, discuss requirements again
(Management) 4.Have a yearly review of requirements between all
stakeholders. Have a system of reviewing the cost and feasability of change
to system

12/15/2022 Software Engineering 5

 The Requirements Engineering Process

Requirements
Feasibility
elicitation and
stud y
anal ysis
Requirements
specification

Feasibility Requirements
report validation

System
models

User and system

requirements

Requirements
document

12/15/2022 Software Engineering 6

 Requirements Engineering
Requirements
specification
System requirements
specification and
modeling

User requirements
specification

Business requirements
specification

System
Feasibility
requirements User
elicitation study
requirements
elicitation
Prototyping

Requirements
elicitation
Reviews Requirements
validation

System requirements
document

12/15/2022 Software Engineering 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 used.
Is there a simpler way of doing this (buy in software and
customize)

12/15/2022 Software Engineering 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?

12/15/2022 Software Engineering 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.

12/15/2022 Software Engineering 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
Example, staff  easy of use, management  highest
security
Patients  change appointments easily, management 
plan staff resourcing, reduce costs
Organisational and political factors may influence the
system requirements (Data protection)
The requirements change during the analysis process.
New stakeholders may emerge and the business
environment change.
12/15/2022 Software Engineering 11
Requirements Discovery

Requirements discovery is 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

12/15/2022 Software Engineering 12

 In the real world

Requirements often come from

Copying /modifying the requirements of other systems
Copying and fixing the requirements of a legacy system
Looking at what competitors do and improve on it
Prototyping
A lot of requirements are discovered by prototyping, so
the initial requirements are often very thin

12/15/2022 Software Engineering 13

 Example - ATM Stakeholders
Bank customers
Representatives of other banks
Bank managers
Counter staff
Database administrators
Security managers
Marketing department
Hardware and software maintenance engineers
Banking regulators

12/15/2022 Software Engineering 14

 Viewpoints
Viewpoints are a way of structuring the requirements
to represent the perspectives of different stakeholders.
Stakeholders may be classified under different
viewpoints.
This multi-perspective analysis is important as there is
no single correct way to analyse system requirements.

12/15/2022 Software Engineering 15

Use Cases
Use-Cases are a scenario based technique in the
Unified Modeling Language (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 (we shall study sequence diagrams later).

12/15/2022 Software Engineering 16

Use Cases
In a use-case diagram, an actor is a user of the system
(i.e. Something external to the system; can be human or
non-human) acting in a particular role.
A use-case is a task which the actor needs to perform
with the help of the system, e.g., find details of a book or
print a copy of a receipt in a bookshop.

12/15/2022 Software Engineering 17

Use Cases
The details of each use case should also be
documented by a use case description: E.g.,
Print receipt – A customer has paid for an item via a
valid payment method. The till should print a receipt
indicating the current date and time, the price, the
payment type and the member of staff who dealt with
the sale.
 [Alternate Case] – No print paper available – Print
out “Please enter new till paper” to the cashier’s
terminal. Try to print again after 10 seconds.
An alternate case here is something that could potentially go
wrong and denotes a different course of action.

12/15/2022 Software Engineering 18

Example -
Actor
Article Printing Use-Case
Use case

Article printing

12/15/2022 Software Engineering 19

ATM machine
Actors
Customers
Bank staff
ATM service engineer
Use cases
Withdraw cash
Check balance
Add cash to machine
Check security video recording

12/15/2022 Software Engineering 20

Example - ATM Use Case Diagram

12/15/2022 Software Engineering 21

Advanced Use Case Diagrams
We can draw a box (with a label) around a set of use
cases to denote the system boundary, as on the
previous slide (“library system”).
Inheritance can be used between actors to show that
all use cases of one actor are available to the other:

Bank Staff Customer

12/15/2022 Software Engineering 22

Include Relations
If several use cases include, as part of their
functionality, another use case, we have a special way
to show this in a use-case diagram with an
<<include>> relation.

12/15/2022 Software Engineering 23

Extend Relations
If a use-case has two or more significantly different
outcomes, we can show this by extending the use case
to a main use case and one or more subsidiary cases.

12/15/2022 Software Engineering 24

In summary
Include
When the other use case is always part of the main use
case
Extend
When the other use case, sometime is needed

12/15/2022 Software Engineering 25

A Word on Extend/Include
Note the directions of the arrows in the previous two
slides, they are different for each (according to
whether a use case “includes” another, or “extends” it).
One of the benefits of UML diagrams is their
simplicity and that they can be shown to and worked
through with, customers.
This is to some extent lost by using more advanced
features like “include” and “extend” relations; they
should thus be used with care.

12/15/2022 Software Engineering 26

ATM use case descriptions
ID UC1

Name Withdraw cash

Description Bank customer withdraws cash from machine

Pre-condition ATM in service

Pre-condition ATM has sufficient cash stock

Event flow 1. Include Use case 2 “Authenticate customer”

2. Choose quick cash or enter exact amount
3. Choose receipt option
4. Take cash

Extension points Use case 4 “Balance too low”

Triggers  

12/15/2022 Software Engineering 27

ATM use cases
ID UC2

Name Authenticate customer

Description Bank customer withdraws cash from machine

Pre-condition ATM in service

Event flow 1. If user already authenticated exit from user case.

2. User enters card and PIN number
3. User re-enters PIN if PIN incorrect

Extension points Use case 5 “Card stolen”

Use case 6 “PIN entry failure”

Triggers Authenticated service requested and user not

authenticated

Post-condition User is authenticated

12/15/2022 Software Engineering 28

ATM use cases
ID UC3

Name Check balance

Description Bank customer retrieves a balance on their account

Pre-condition ATM in service

Event flow 1. Include Use case 2 “Authenticate customer”

2. Choose onscreen or paper balance

Extension points Use case 5 “Card stolen”

Use case 6 “PIN entry failure”

Triggers Authenticated service requested and user not

authenticated

Post-condition  

12/15/2022 Software Engineering 29

ATM use cases
ID UC4

Name Balance too low

Description Bank customer cannot make cash withdrawal due to low

balance

Pre-condition  

Event flow 1. Customer chooses smaller amount or cancels

transaction

Extension points  

Triggers Cash chosen greater than available balance

Post-condition  

12/15/2022 Software Engineering 30

 Validating Requirements
 Is each requirement consistent with the overall objective for the system/product?
 Have all requirements been specified at the proper level of abstraction? That is, do some
requirements provide a level of technical detail that is inappropriate at this stage?
 Is the requirement really necessary or does it represent an add-on feature that may not
be essential to the objective of the system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a source (generally, a specific
individual) noted for each requirement?
 Do any requirements conflict with other requirements?

 Is each requirement achievable in the technical

environment that will house the system or product?
 Is each requirement testable, once implemented?
 Does the requirements model properly reflect the
information, function and behavior of the system to be
built.
31
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.
 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?
 This reduces the potential for disputes between customers
and contractors and a set of tests should be possible.

12/15/2022 Software Engineering 33

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 17.
Test-case generation
Developing tests for requirements to check testability.
 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.
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;
 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.
Requirements evolution
Initial Changed
understanding understanding
of problem of prob lem

Initial Changed
requirements requirements

Time
Requirements classification
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.