Requirement 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

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.

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

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
(Elicitation) 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 feasibility of
change to system

5
The Requirements Engineering Process
Require ments
Feasibility
elicitation and
study analy sis
Require ments
specification

Feasibility Require ments

report validation

System
models

User and system

requirements

Require ments
document

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

Syst
em requirements
document

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)

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?

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.

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.
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
 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

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

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.

15
 Viewpoint Identification
We may 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.

16
 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.
Ideally, interviewers should be open-minded, willing to
listen to stakeholders and should not have pre-conceived
ideas.

17
 Ethnography
In ethnography, a social scientist spends a considerable
amount of 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.

18
 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.
The problem with ethnography is that it studies existing
practices which may have some historical basis which is
no longer relevant.

19
 Scope of Ethnography
Requirements that are derived from the way that people
actually work rather than the way in which process
definitions suggest that they ought to work.
People may have “short cuts” or use their previous
knowledge and experience to better perform their role
which may not be evident.
As an example, an air traffic controller may switch off a
conflict alert alarm detecting flight intersections. Their
strategy is to ensure these planes are moved apart before
problems arise and the alarms can distract them.

20
 Scope of Ethnography
Requirements that are derived from cooperation and
awareness of other people’s activities.
People do not work in isolation and may share information
and use dialogue with colleagues to inform decisions.
Using the previous scenario, air traffic controllers may
use awareness of colleagues work to predict the number
of aircraft entering their sector and thus require some
visibility of adjacent sector.

21
 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).

22
 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.

23
 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.

24
Example - Article Printing Use-Case
Actor Use case

Article printing

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

26
Example - ATM Use Case Diagram

27
 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

28
 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.
 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.
 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

31
 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.

32
 Full use case template
 ID
 Short ID (useful for diagrams and reference)
 Name
 Full name
 Description
 Full description
 Pre-condition
 What must be true before the use case can proceed
 Event flow
 Flow of behaviour that makes up this use case
 Post-condition
 What should be true if the use case successfully completes
 Includes
 What other use cases are used
 Extensions
 Optional behaviour
 Triggers
 What makes this use case happen

33
 Notes about use cases
They do NOT describe internal behaviour
Must describe behaviour with external Actors
But external Actor can be
External system (e.g. Paypal)
External hardware (e.g. smoke detector fire alarm)
External agency (e.g. Police, fire brigade)
So Use cases are always systems EXTERNAL behaviour

34
 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

35
 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

36
 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

37
 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

38