Chapter 7

Requirements Engineering Processes

Haya Sammaneh

1
 Objectives

 To describe the principal of requirements

engineering activities and their relationship

 To introduce techniques for requirements

elicitation and analysis

 To understand the importance of requirements

validation

2
 Topics covered
 Feasibility studies
 Requirements elicitation and analysis
 Requirements validation
 Requirements management

3
 Requirements Engineering processes
 The processes used for RE vary widely depending on the
application domain, the people involved and the
organization developing the requirements

 However, there are a number of generic activities common

to all processes
 Feasibility study

 Requirements elicitation and analysis

 requirements specification and system modeling.

 Requirements validation

 Requirements management

4
The requirements engineering process

Feasibility Requirements
study elicitation and
analysis
Requir ements
specification
Feasibility Requirements
report validation
System
models
User and system
requirements

Requirements
document

5
The Spiral model of requirements
engineering Process
Requirements
specification
System requirements
specification and
modeling

User requirements
specification

Business requirements
specification

System
requirements Feasibility
User study
elicitation requirements
elicitation
Prototyping

Requirements
elicitation Requirements
Reviews
validation

Syst em requirements 6
document
 Feasibility studies 7.1
 A feasibility study decides whether or not the proposed
system is worthwhile

 A short focused study that checks

 If the system contributes to organizational 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
7
 Feasibility study implementation

 Based on information assessment , information

collection and report writing

 Questions for people in the organization

 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 facilities must be supported by the proposed

system?
8
 Requirements Elicitation (discovery) 7.2
and analysis

 Involves technical staff working with customers,

the services that the system should provide and
the system’s operational constraints

 May involve end-users, managers, engineers

These are called stakeholders

9
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

 Organizational and political factors may influence the system

requirements

 The requirements change during the analysis process. New

stakeholders may emerge and the business environment
change
10
The requirements analysis
process
Requir ements
definition and
Requirements specification
validation

Domain
Prioritization
understanding
Process
entry

Requirements Conflict
collection resolution

Classification

11
The requirements Analysis Spiral

Requireme nts Require ments

classification and prioritization and
organisa tion negotia tion

Requireme nts Require ments

discovery documentation

12
 requirements analysis Process
(activities)
 Requirements collection, interact with stakeholders, domain requirements
(understanding).

 Classification and organization, organize requirement in a structure one

(coherent cluster).

 Conflict resolution, resolving the conflict.

 Prioritization, prioritize requirements.

 Requirements checking and documentation, checking for completion,

consistency, and in accordance with what stakeholder really wants, then
documented for the next phase.

13
Requirements discovery 7.2.1
(Viewpoints, interview , scenario, use case)

 The process of gathering information

about the proposed and existing systems
and eliciting the user and system
requirements from this information.

 Sources of information include

documentation, system stakeholders and
the specifications of similar systems.

14
 a. Viewpoint-oriented approach
 Stakeholders represent different ways of looking
at a problem

 Viewpoints are a way of structuring the

requirements to represent the perspectives of
different stakeholders..

 This multi-perspective analysis is important as

there is no single correct way to analyze system
requirements.
15
 Example - Banking (auto-teller system )ATM
system
 The example used here is an auto-teller system which
provides some automated banking services

 we use a very simplified system which offers some

services to customers of the bank who own the system
and a narrower range of services to other customers

 Services include cash withdrawal, message passing

(send a message to request a service), ordering a
statement and transferring funds

16
 Auto-teller viewpoints

 Bank customers
 Representatives of other banks: allow other
ATM to be used
 Hardware and software maintenance engineers

 Marketing department

 Bank managers and staff

 Database administrators and security staff

 Communications engineers

 Personnel department

Stakeholder + domain + system can be represented as system

viewpoints
17
 Types (Models) of viewpoint
 Interactor viewpoints
 People or other systems that interact directly with the
system.
 In an ATM, the customer’s and the account database are
interactor VPs.
 Indirect viewpoints
 Stakeholders who do not use the system themselves but
who influence the requirements.
 In an ATM, management and security staff are indirect
viewpoints.
 Domain viewpoints
 Domain characteristics and constraints that influence the
requirements.
 In an ATM, the standards for inter-bank communications.

18
LIBSYS viewpoint hierarchy
All VPs

Indirect Interactor Domain

Library Article Library UI Classification

Finance Users standards system
manager providers staff

System
Students Staff External Cataloguers
managers

19
 Viewpoint process model
 Viewpoint identification: discover viewpoints which
receive system services and identify the services
provided to each viewpoint using:

 Providers and receivers of system services;

 Systems that interact directly with the system being
specified;
 Regulations and standards;
 Engineers who have to develop and maintain the system;
 Marketing and other business viewpoints.

20
 Viewpoint process model, cont
 Viewpoint structuring, group related viewpoints
into a hierarchy. Common services are provided
at higher-levels in the hierarchy

 Viewpoint documentation, refine the description

of the identified viewpoints and services

 Viewpoint-system mapping, transform the

analysis to an object-oriented design

21
Viewpoint identification
Query Get Customer Cash Transaction
balance transactions database withdrawal log

Manager Card Remote

Machine Order
returning software
supplies cheques
upgrade
Account Message Software
information log size Bank Invalid
User teller user
interface System cost Foreign
customer Printe
r Security
Account Stolen Order Hardware
card statement Card
holder maintenance retention
Message
passing
Remote Update Funds Card
Reliability account transfer
diagnostics validation

22
b. Interviewing
 In formal or informal interviewing, the RE
team puts questions to stakeholders about
the system.

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

23
Interviews in practice

 Normally a mix of closed and open-ended

interviewing.

 Interviews are good for getting an overall

understanding of what stakeholders do and how
they interact with the system.

24
Effective interviewers
 Interviewers should be open-minded, willing to
listen to stakeholders and should not have pre-
ideas about the requirements.

 They should prompt the interviewee with a

question or a proposal and should not simply
expect them to respond to a question such as
‘what do you want’.

25
 c. Scenarios

 Scenarios are descriptions of how a system is

used in practice, a real-life examples of how a
system can be used.

 Scenarios are particularly useful for adding detail

to an outline requirements description

26
 :Scenario include
 description of the system state at the
beginning of the scenario
 Normal flow of events in the scenario
 What can go wrong and how this is handled
 Other concurrent activities
 description of the System state on completion
of the scenario

27
 Event scenarios
 Event scenarios may be used to describe how a
system responds to the occurrence of some particular
event such as ‘start transaction’

28
…Event scenarios, cont
 The diagrammatic notations used in event
scenarios are:
 Data provided and delivered from/to a
viewpoint is shown in ellipses.
 Control information, enter and leave at the
top of each box.
 Exception processing, shown at the
bottom of the box.
 Name of the next expected event is shown
in a shaded box
29
Event scenario - start transaction

Card present

Valid card
Card User OK
Request PIN
PIN
Account Validate user Account
number number Select
PIN service
Timeout

Return card Incorrect PIN

Re-enter PIN
Invalid card

Return card
Incorrect PIN

Stolen card Return card

Retain card
30
 Exception description

 In the previous example, exceptions are:

 Timeout, customer fails to enter a PIN within the
allowed time limit
 Invalid card, the card is not recognized and is
returned
 Stolen card, the card has been registered as
stolen and is retained by the machine

31
 c. Use cases
 Use-cases are a scenario based technique for
requirement elicitation in the UML notations that used
in object-oriented system model (Unified Modelling
Language) 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 in the system

32
..Use cases, cont
 The sequence diagram (ch 6) is used to add
information to use-case.

The sequence diagram shows the:

1- actors used in the interaction
2- objects that the actors interact with.
3- operation associated with these objects.

33
.Library system , example
 Interaction for downloading and printing
article.
 Objects used in this interaction are:
1. Article
2. Form
3. workspace
4. printer

34
Lending use-case

Lending services

35
use-cases for Library system

Lending services
Library
User

User administration
Library
Staff

Supplier Catalog services

36
.Example of sequence diagram of Printing article

item: copyrightF orm: myWorkspace: myPrinter:

Article Form Workspace Printe r

User

request
request

complete
return

copyright OK

deliver

article OK

print send

inform confirm

delete
37
 Requirements validation 7.3
 Concerned with demonstrating that the requirements
define the system that the customer really wants

 Requirements error costs are high so validation is very

important
 Fixing a requirements error after delivery may cost up to
100 times the cost of fixing an implementation error

 Change requirement error means change system design

and implementation

38
 Requirements checking (types of checks
should be carried out on requirements)
 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? In order to
reduce potential dispute ‫ع‬B‫زا‬BB‫ ن‬between customers.
Should be write a set of test that can be demonstrate that
the delivered system meet each specified requirements.
39
 Requirements validation techniques
 Requirements reviews, systematic manual analysis of the
requirements

 Prototyping, using an executable model of the system to check

requirements.

 Test-case generation, developing tests for requirements to check

testability of requirement.

 Automated consistency analysis , checking the consistency of

a structured requirements description, if the requirements are
expressed in structured or formal notation, then CASE tool may
be used to check the consistency.
40
 Requirements reviews 6.3.1
 Regular reviews should be held while the requirements
definition is being formulated

 Both client and contractor staff should be involved in

reviews

 Reviews may be formal (with completed documents) or

informal.

 Good communications between developers, customers

can resolve problems at an early stage
41
 :Review checks
 Verifiability. Is the requirement realistically testable?

 Comprehensibility. Is the requirement properly

understood?

 Trace-ability. Is the source of the requirement clearly

stated?

 Adaptability. Can the requirement be changed without

a large impact on other requirements?
42
 Requirements management 7.4
 Requirements management is the process of managing
changing requirements during the requirements
engineering process and system development

 Requirements are inevitably incomplete and

inconsistent because:
 New requirements emerge during the process
because business needs change and a better
understanding of the system is developed

 Different viewpoints have different requirements and

these are often contradictory
43
 :Requirements change because of

 The priority of requirements from different viewpoints

changes during the development process

 System customers may specify requirements from a

business perspective that conflict with end-user
requirements.
 (customers-people who pay for the system- and end-user -
people who use the system- usually different)

 The business and technical environment of the system

changes during its development
44
 Enduring and volatile requirements 7.4.1
 Enduring requirements. Stable requirements derived from
the core activity of the customer organization. E.g. a
hospital will always have doctors, nurses, etc.

 Volatile requirements. Requirements which change during

development or when the system is in use. In a hospital,
requirements derived from health-care policy

45
 Classification of Volatile requirements

 Mutable‫ متقلب‬requirements, requirements that

change due to the changing of system’s
environment
 Emergent requirements, requirements that
emerge as understanding of the system
develops during the system development.
Classification of Volatile requirements
 Consequential requirements,
requirements that result from the
introduction of the computer system that
result to new process which may generate
new requirements.
 Compatibility requirements, requirements
that depend on other systems

47
Requirements management planning 7.4.2

 During the requirements engineering process, you

have to plan on:

 Requirements identification, how

requirements are individually identified

 A change management process, the process

followed when analyzing a requirements
change (the impact and cost of change)
48
Requirements management planning,
..cont
 Traceability policies, the amount of
information about requirements relationships
are recorded and how it should be maintained

 CASE tool support which required to help

manage requirements change, using
spreadsheets and databases.

49
 Traceability
 Traceability is concerned with the relationships between
requirements, their sources and relationships between
requirements and the system design

 There are three types of traceability:

 Source traceability, links from requirements to
stakeholders who proposed these requirements

 Requirements traceability, links between dependent

requirements

 Design traceability, links from the requirements to the

design,
A traceability matrix
R- weak relationship
U- row use facility of column, shows dependency between reqs

Req. in the row depends on the Req. in the column

51
 Requirements change management 7.4.3
process

 Should be applied to all proposed changes to the

requirements. The advantage of using a formal process for
change management is that all change proposals are
treated consistently.

 Principal stages to a change management process:

 Problem analysis. Discuss requirements problem and
propose change
 Change analysis and costing. Assess effects of change
on other requirements
 Change implementation. Modify requirements document
and other documents to reflect change 52
 Key points
 The requirements engineering process includes a
feasibility study, requirements elicitation and analysis,
requirements specification and requirements management

 Requirements analysis is iterative involving domain

understanding, requirements collection, classification,
structuring, prioritization and validation

 Systems have multiple stakeholders with different

requirements

53
Key points
 Social and organisation factors influence system
requirements

 Requirements validation is concerned with checks for

validity, consistency, completeness, realism and
verifiability

 Business changes inevitably lead to changing

requirements

 Requirements management includes planning and

change management 54