Lecturer: Sebastian Coope
Ashton Building, Room G.18
E-mail: coopes@liverpool.ac.uk
COMP 201 web-page:
http://www.csc.liv.ac.uk/~coopes/comp201
Lecture 6 – Requirements Engineering Processes
COMP201 - 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
COMP201 - 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.
COMP201 - Software Engineering
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?
COMP201 - Software Engineering
4
Example
Patient records system
1.
Talk to patients, doctors, nurses, receptionists, managers
to find out
Current system practise, legal restrictions, problems with current
system, needs for improvement, security issues, costs
2.
Develop draft documentation and review what is most
important, what will it cost, what is the timescale, is new
hardware required
3.
Go back to step 1, discuss requirements again
4.
Have a yearly review of requirements between all
stakeholders. Have a system of reviewing the cost and feasability
of change to system
COMP201 - Software Engineering
5
The Requirements Engineering Process
COMP201 - Software Engineering
6
Requirements Engineering
Req uiremen ts
sp ecification
Sy stem req uiremen ts
sp ecification and
mod eling
User requ irements
sp ecification
Bus iness requ irements
sp ecification
Sy stem
requ irements
elicitation
User
requ irements
elicitation
Feasib ility
stud y
Prototy p ing
Req uiremen ts
elicitation
Rev iews
Req uiremen ts
v alid atio n
System requirements
document
COMP201 - 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)
COMP201 - 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?
COMP201 - 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.
COMP201 - 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
 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.
COMP201 - 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
COMP201 - 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 got from prototyping, so the
initial requirements are often very thin
COMP201 - 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
COMP201 - 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.
COMP201 - Software Engineering
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.
COMP201 - Software Engineering
16
Example – Library System Viewpoint Hierarchy
All VPs
In direct
Library
man ag er
Finance
Stud en ts
In teractor
Article
providers
Staff
Users
Extern al
COMP201 - Software Engineering
Domain
Library
staff
Sy stem
man ag ers
UI
stan dards
Clas sificatio n
sy stem
Catalo gu ers
17
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.
COMP201 - Software Engineering
18
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.
COMP201 - Software Engineering
19
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.
COMP201 - Software Engineering
20
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.
COMP201 - Software Engineering
21
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.
COMP201 - Software Engineering
22
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 usecases by showing the sequence of event processing in the
system (we shall study sequence diagrams later).
COMP201 - Software Engineering
23
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 nonhuman) 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.
COMP201 - Software Engineering
24
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.
COMP201 - Software Engineering
25
Example - Article Printing Use-Case
Actor
Use case
COMP201 - Software Engineering
26
ATM machine
 Actors
 Customers
 Bank staff
 ATM service engineer
 Use cases
 Withdraw cash
 Check balance
 Add cash to machine
 Check security video recording
COMP201 - Software Engineering
27
Example - ATM Use Case Diagram
COMP201 - Software Engineering
28
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
COMP201 - Software Engineering
29
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
COMP201 - Software Engineering
32
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.
COMP201 - Software Engineering
33
Scenarios
 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.
COMP201 - Software Engineering
34
ATM Scenario (1)
Initial assumption: The user has entered their bank card and entered the correct PIN
Normal: The user selects the withdraw cash function. The user is then given options of quick cash amounts
or to be able to pick another amount of money.
The user is then given the option of picking another function.
The user chooses to end the transaction.
The machine first returns the user’s card, then issues the receipt and then dispenses the cash.
The machine then resets itself, going through a test cycle to be ready for the next user.
COMP201 - Software Engineering
35
ATM Scenario (2)
What can go wrong: The bank card might be reported stolen or missing. In this case the card should be
retained and the bank’s central security system should be notified.
The bank card’s chip might be faulty, in this case, the card will be rejected from the machine and the
customer notified to contact their bank for a replacement.
The PIN might be entered incorrectly.
In this case if the PIN retry count is exceeded the card will be retained, otherwise the customer will be
prompted to re-enter their PIN.
The customer may have insufficient
COMP201 - Software Engineering
36
Security requirements of systems
 Broken down into 4 main issues
 Confidentiality
 Integrity
 Authentication and Authorization
 Non-repudiation
 One auxiliary issue
 Availability
COMP201 - Software Engineering
37
Confidentiality requirements
 Usually two main options
 Encryption
(hard security)
 Permissions (soft security)
 Data must be kept secure
 In storage (final or intermediary)
 On the wire or wireless link
 For as long as reasonably possible
COMP201 - Software Engineering
38
Integrity Requirements
 Messages or data must not be modifiable without
 Knowledge of the change
 Integrity approaches
 CRC Checking (no good, easy to forge check value)
 Hash value over data, similar problem to CRC
 Hash value over data + secret value

Key distribution problem
 Hash value encrypted using asymmetric cipher

Best approach to date
COMP201 - Software Engineering
39
Authentication/Authorization
 Authentication
 Who are you?
 Authorization
 What are you allowed to do?
 Techniques
 Usernames, Passwords, hardware (cards, dongles),
Biometrics
 Often first point of attack
COMP201 - Software Engineering
40
Non-repudiation issue
From: Bob
To: Broker
Please buy
lots of shares
Applied IP Telecoms Security
Bob subsequently
denies sending the
email
Share Price
Bob
Broker
COMP201 - Software Engineering
© Orbitage 2011
slide4141
Non Repudiation in practice
 May require
 Trusted broker, third party
 Funding in Escrow
 Non repudiation is built on
 Authentication
 Integrity
 Recording and time stamping
 Broker style services
COMP201 - Software Engineering
42
Availability requirements
 High availability of system
 Specifying in 9s terminology
Uptime
Uptime
Six nines
Five nines
Four nines
99.9999%
99.999%
99.99%
Three nines
Two nines
One nine
99.9%
99.0%
90.0%
COMP201 - Software Engineering
Maximum Downtime
per Year
31.5 seconds
5 minutes 35 seconds
52 minutes 33
seconds
8 hours 46 minutes
87 hours 36 minutes
36 days 12 hours
43
Availability in practise
 9s terminology not always useful
 Imagine a computer system
 Three 9s available but unavailability spread as 78 seconds
per day
 Or Five 9s available, failing once every 10 years for 50
minutes
 So ideally to need specify
 Worst case scenarios
 Worst case delay as well as down time
 How the system can degrade gracefully
COMP201 - Software Engineering
44
Security, logs and alerts
 Security is very dependent on knowledge of activity (audits





and logs)
Standard log (records all logins/logouts, database access
requests)
Failed login log (records all failed logins)
Unusual activity log (high volume transactions on account)
Alert log (failed logins for top level clearance users)
Alerts
 Unusual activity can be used to alert operators, suspend
accounts etc.
COMP201 - Software Engineering
45
Bell–LaPadula model
 All items given security clearance level
 Top-Secret (4), Secret(3), Sensitive(2), Unclassified
 no read-up

A subject cannot read a document above their clearance level

If I am cleared to level 2, I cannot read a level 3 or 4 document
 no write-down



A document cannot be copied/included with another document with a
lower security clearance
So if I want to add a top secret to a sensitive document the result will be a
top secret document
If my classification is 2, I cannot produce an unclassified document
 Trusted subjects
 Can write documents down
 Must be shown trustworthy with regard to the security policy
COMP201 - Software Engineering
46
Specifying Security
 Ideally kept as open as possible to allow for
 Upgrading of encryption algorithms and protocols
 Security policy
 Shredding documents
 Secure disposal
 Password reset protocols
 Security training
 Security audits
 Standards compliance
 Payment Card Industry Data Security Standard
COMP201 - Software Engineering
47
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.
COMP201 - Software Engineering
48
Lecture Key Points
 The requirements engineering process includes a
feasibility study, requirements elicitation and analysis,
requirements specification and requirements
management.
 The requirements elicitation and analysis stage is iterative
and involves domain understanding, requirements
collection, classification, structuring, prioritisation and
validation.
 Systems have multiple stakeholders with different
requirements
 Security for most systems is a core service
COMP201 - Software Engineering
49