Requirements Engineering Processes

Lecturer: Sebastian Coope

Ashton Building, Room G.18

E-mail: [email protected]

COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201

Lecture 6 – Requirements Engineering Processes

1 COMP201 - Software Engineering

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


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.


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


The Requirements Engineering Process


Requirements Engineering Requirements

specification

Requirements

validation

Requirementselicitation

System requirements

specification andmodeling

System

requirementselicitation

User requirementsspecification

Userrequirements

elicitation

Business requirementsspecification

Prototyping

Feasibility

study

Reviews

Syst em requirements

document


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)


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?


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.


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.


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


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


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


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.


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.


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.


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.


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.


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.


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.


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


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.


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.

Example - Article Printing Use-Case


Actor Use case

ATM machine

Actors

Customers

Bank staff

ATM service engineer

Use cases

Withdraw cash

Check balance

Add cash to machine

Check security video recording


Example - ATM Use Case Diagram


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

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


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.


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


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


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

ATM use cases ID UC2

Name Authenticate customer

Description Bank customer withdraws cash from machine


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


ATM use cases ID UC3

Name Check balance

Description Bank customer retrieves a balance on their account


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


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


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


Security requirements of systems

Broken down into 4 main issues

Confidentiality

Integrity

Authentication and Authorization

Non-repudiation

One auxiliary issue

Availability (Performance security)


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


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


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



Non-repudiation issue

© Orbitage 2011 Applied IP Telecoms Security slide 44

Bob Broker

From: Bob

To: Broker

Please buy

lots of shares

Share Price

Bob subsequently

denies sending the

email

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


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

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


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.


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


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


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.


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


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

In order To prove who I am

As a customer

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

Feature start is not

parsed but describes

feature to developer

Scenario is example

for developer but also

is linked to test code

Coupled to test code public class LoginSteps { @Given("Î have entered a username of account(\\d+)$") public void i_have_entered_a_username_of_account(int arg1) throws Throwable { throw new PendingException(); } @Given("Î have entered a password of pass(\\d+)$") public void i_have_entered_a_password_of_pass(int arg1) throws Throwable { throw new PendingException(); } @When("Î click login$") 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(); } }


You can fetch data from

scenario using this notation

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


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


Documents

Requirements Engineering Processes