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
(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 feasability of change to system
COMP201 - Software Engineering
5
The Requirements Engineering Process
COMP201 - Software Engineering
6
Requirements Engineering
Requiremen ts
sp ecificatio n
Sy stem requiremen ts
sp ecificatio n an d
modelin g
User requirements
sp ecificatio n
Busin ess requirements
sp ecificatio n
Sy stem
requirements
elicitatio n
User
requirements
elicitatio n
Feasibility
study
Pro toty ping
Requiremen ts
elicitatio n
Rev iews
Requiremen ts
v alidation
Sy s te m re quire me nts
docum ent
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
 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.
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 discovered by 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
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
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.
COMP201 - Software Engineering
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.
COMP201 - Software Engineering
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.
COMP201 - Software Engineering
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.
COMP201 - Software Engineering
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 usecases by showing the sequence of event processing in the
system (we shall study sequence diagrams later).
COMP201 - Software Engineering
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 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
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.
COMP201 - Software Engineering
24
Example - Article Printing Use-Case
Actor
Use case
COMP201 - Software Engineering
25
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
26
Example - ATM Use Case Diagram
COMP201 - Software Engineering
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
COMP201 - Software Engineering
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
COMP201 - Software Engineering
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.
COMP201 - Software Engineering
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
COMP201 - Software Engineering
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
COMP201 - Software Engineering
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
COMP201 - Software Engineering
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
COMP201 - Software Engineering
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
COMP201 - Software Engineering
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
COMP201 - Software Engineering
38
Security
 Most modern systems have some security requirements
 Why?
 Because
 Internet
 Systems often control money
 Systems nearly always contain data (much of it personal)
 You are legally required often to keep your system secure
 You could get sued
COMP201 - Software Engineering
39
Security requirements of systems
 Broken down into 4 main issues
 Confidentiality
 Integrity
 Authentication and Authorization
 Non-repudiation
 One auxiliary issue
 Availability (Performance security)
COMP201 - Software Engineering
40
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
41
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
42
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
43
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
slide4444
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
45
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
46
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
47
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
48
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
49
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
50
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
51
Scenarios
 There are effectively test cases running in a given situation
 So for example:
 Try and withdraw cash with stolen credit card
 Try and withdraw cash but machine has low cash stock
 Withdraw cash with card number 3456123245677
 Etc.
 Scenarios are very important as they
 Show the developer by example what will happen given certain
conditions
 They can be used as a basis to test the software
 Make things very clear and reduce ambiguity
COMP201 - Software Engineering
52
Agile Requirements Tool Example
 Cucumber
 Software tool used to help write requirements which are
linked directly to tests
 Cucumber uses a language called Gherkin which describes
features…
Feature: Login
Feature start is not
In order To prove who I am
parsed but describes
As a customer
feature to developer
I want To be able to login to the system
Scenario: Login With test account1
Given I have entered a username of account1
And I have entered a password of pass1234
When I click login
Then The result should be login successful
COMP201 - Software Engineering
Scenario is example
for developer but also
is linked to test code
53
Coupled to test code
public class LoginSteps {
@Given("^I have entered a username of account(\\d+)$")
public void i_have_entered_a_username_of_account(int arg1) throws Throwable {
throw new PendingException();
}
@Given("^I have entered a password of pass(\\d+)$")
public void i_have_entered_a_password_of_pass(int arg1) throws Throwable
You can{fetch
throw new PendingException();
data from
}
@When("^I click login$")
public void i_click_login() throws Throwable {
throw new PendingException();
}
scenario using
this notation
@Then("^The result should be login succesful$")
public void the_result_should_be_login_succesful() throws Throwable {
throw new PendingException();
}
}
COMP201 - Software Engineering
54
Cucumber in summary
 Gives simple and clear notation to write specification
 Analysts/test team and even customers can learn Gherkin
and develop feature files
 Step files are produced by development team
 Test data can be changed later Without changing test
code
COMP201 - Software Engineering
55
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
56