Prof.

Nasir Shahzad

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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?

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 5

The Requirements Engineering Process

Prof. Nasir Shahzad 6

Requirements Engineering
Requirements
sp ecification
Sys tem requirements
sp ecification and
modeling

User requirements
sp ecification

Business requirements
sp ecification

Sys tem
Feas ibility
requirements User
elicitation study
requirements
elicitation
Prototyp ing

Requirements
elicitation Requirements
Reviews
validation

System requirements
document

Prof. Nasir Shahzad 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)

Prof. Nasir Shahzad 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?

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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.
Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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).

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 24

Example - Article Printing Use-Case
Actor Use case

Prof. Nasir Shahzad 25

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

Prof. Nasir Shahzad 26

Example - ATM Use Case Diagram

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 29

 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.

Prof. Nasir Shahzad 30

 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

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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
Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 39

 Security requirements of systems
 Broken down into 4 main issues
 Confidentiality
 Integrity
 Authentication and Authorization
 Non-repudiation
 One auxiliary issue
 Availability (Performance security)

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 43

 Non-repudiation issue

From: Bob
To: Broker
Bob subsequently
Please buy denies sending the
lots of shares email

Share Price

Bob Broker

Prof. Nasir Shahzad 44

 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

Prof. Nasir Shahzad 45

 Availability requirements
 High availability of system
 Specifying in 9s terminology
Uptime Uptime Maximum Downtime
per Year
Six nines 99.9999% 31.5 seconds
Five nines 99.999% 5 minutes 35 seconds
Four nines 99.99% 52 minutes 33
seconds
Three nines 99.9% 8 hours 46 minutes
Two nines 99.0% 87 hours 36 minutes
One nine 90.0% 36 days 12 hours

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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.

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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
I want To be able to login to the system
feature to developer

Scenario: Login With test account1 Scenario is example

Given I have entered a username of account1 for developer but also
And I have entered a password of pass1234
When I click login
is linked to test code
Then The result should be login successful
Prof. Nasir Shahzad 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
scenario using
@When("^I click login$") this notation
public void i_click_login() throws Throwable {
throw new PendingException();
}

@Then("^The result should be login succesful$")

public void the_result_should_be_login_succesful() throws Throwable {
throw new PendingException();
}
} Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 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

Prof. Nasir Shahzad 56