Requirements Engineering Processes

Processes used to discover,
analyze and validate system
requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 1
Requirements engineering processes


The processes used for RE vary widely
There are a number of generic activities
common to all processes
•
•
•
•
Requirements elicitation
Requirements analysis
Requirements validation
Requirements management
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 2
Elicitation and analysis

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
Hospital Example
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 3
Problems of requirements analysis

Stakeholders
•
•
•



Don’t know what they really want
Express requirements in their own terms
Different stakeholders may have conflicting requirements
Organizational and political factors influence
requirements
Requirements change during the analysis process.
New stakeholders may emerge
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 4
Viewpoint-oriented elicitation


Stakeholders represent different ways of looking
at a problem or problem viewpoints
This multi-perspective analysis is important as
there is no single correct way to analyse system
requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 5
Banking ATM system (simplified)


Offers services to customers of the bank, owns
the system, and other customers
Services include
•
•
•
•
cash withdrawal,
message passing (send a message to request a
service),
ordering a statement and
transferring funds
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 6
ATM viewpoints








Bank customers
Representatives of other banks
Hardware and software maintenance engineers
Marketing department
Bank managers and counter staff
Database administrators and security staff
Communications engineers
Personnel department
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 7
Types of viewpoint

Data sources or sinks
•

Representation frameworks
•

Viewpoints are responsible for producing or consuming data.
Viewpoints represent particular types of system model such as
real-time systems.
Receivers of services
•
Viewpoints are external to the system and receive services from
it.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 8
Method-based analysis




Widely used approach to requirements analysis.
Depends on the application of a structured
method to understand the system
A viewpoint-oriented method (VORD) is used as
an example here.
It also illustrates the use of viewpoints
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 9
The VORD method
Viewpoint
identification
©Ian Sommerville 2000
Viewpoint
structuring
Viewpoint
documenta tion
Software Engineering, 6th edition. Chapter 6
Viewpoint
system ma pping
Slide 10
VORD process model

Viewpoint identification
•

Viewpoint structuring
•

Group related viewpoints into a hierarchy. Common services are
provided at higher-levels in the hierarchy
Viewpoint documentation
•

Discover viewpoints which receive system services and identify
the services provided to each viewpoint
Refine the description of the identified viewpoints and services
Viewpoint-system mapping
•
Transform the analysis to an object-oriented design
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 11
VORD standard forms
Vie wpoint te mplate
Ref er ence :
The viewpoint na m e.
Att ribut es:
Attr ibute s
providing
viewpoint inf or m ation.
Eve nt s:
A re fe re nc e to a se t ofe ve nt
sc ena rios de scr ibing how
the sy stem r ea c ts to
viewpoint events.
Ser vic es
A re fe re nc e to a se t of
se rvic e de sc riptions.
Sub-VPs:
The nam e s of
subviewpoints.
©Ian Sommerville 2000
Ser vic e te mplate
Ref er ence :
The se rvic e na m e.
Rat ionale:
Rea son why the se rvic e is
provided.
Spe cif ic at ion:
Ref er ence to alist of se rvice
spec if ica tions. These
m ay
be e xpre sse d in diffe re nt
nota tions.
Vie wpoint s:
List of vie wpoint na m es
re ce iving the se rvic e.
Non-f unct ional
Ref er ence to a se t of non r equir eme nt s:
func tional
re quir em e nts
which constr ain the se rvic e.
Provide r:
Ref er ence to alist of sy ste m
obje c ts which pr ovide the
se rvic e.
Software Engineering, 6th edition. Chapter 6
Slide 12
Viewpoint identification
Query
balance
Get
transactions
Customer
database
Card
returning
Manager
Machine
supplies
Message
log
Account
information
User
interface
Account
holder
Remote
diagnostics
©Ian Sommerville 2000
System cost
Stolen
card
Reliability
Cash
withdrawal
Foreign
customer
Order
statement
Update
account
Transaction
log
Remote
software
upgrade
Software
size
Printe
r
Hardware
maintenance
Funds
transfer
Software Engineering, 6th edition. Chapter 6
Order
cheques
Bank
teller
Invalid
user
Security
Message
passing
Card
retention
Card
validation
Slide 13
Viewpoint service information
ACCOUNT
HOLDER
Service list
Withdraw cash
Query balance
Or der cheques
Send message
Transaction list
Or der statement
Transfer funds
©Ian Sommerville 2000
FOREIGN
CUSTOMER
Service list
Withdraw cash
Query balance
Software Engineering, 6th edition. Chapter 6
BANK
TELLER
Service list
Run diagnostics
Add cash
Add paper
Send message
Slide 14
Viewpoint data/control
ACCOUNT
HOLDER
Control input
Start transaction
Cancel transaction
End transaction
Select service
©Ian Sommerville 2000
Da ta input
Card details
PIN
Am ount required
Message
Software Engineering, 6th edition. Chapter 6
Slide 15
Viewpoint hierarchy
All VPs
Services
Query balance
Withdraw cash
Services
Customer
Account
holder
Foreign
customer
Bank staff
Teller
Manager
Engineer
Order cheques
Send message
Transaction list
Order statement
Transfer funds
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 16
Customer/cash withdrawal templates
Reference: Customer
Reference:
Cash withdrawal
Attributes: Account number
PIN
Start transaction
Events:
Select service
Cancel
transaction
End transaction
Rationale:
To improve customer service
and reduce paperwork
Services:
Cash withdrawal
Balance enquiry
Specification: Users choose this service by
pressing the cash withdrawal
button. They then enter the
amount required. This is
confirmed and, if funds allow,
the balance is delivered.
VPs:
Sub-VPs:
Account holder
Foreign
customer
Deliver cash within 1 minute
Non-funct.
requirements: of amount being confirmed
Provider:
©Ian Sommerville 2000
Customer
Filled in later
Software Engineering, 6th edition. Chapter 6
Slide 17
Scenarios



Scenarios are descriptions of how a system is
used in practice
They are helpful in requirements elicitation as
people can relate to these more readily than
abstract statement of what they require from a
system
Scenarios are particularly useful for adding detail
to an outline requirements description
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 18
Scenario descriptions





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
System state on completion of the scenario
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 19
Event scenarios


Event scenarios may be used to describe how a
system responds to the occurrence of some
particular event such as ‘start transaction’
VORD includes a diagrammatic convention for
event scenarios.
•
•
•
•
Data provided and delivered
Control information
Exception processing
The next expected event
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 20
Event scenario - start transaction
Card present
Valid card
User OK
Card
Request PIN
PIN
Timeout
Return card
Account
number
PIN
Validate user
Account
number
Select
service
Incorrect PIN
Re-enter PIN
Invalid card
Return card
Incorrect PIN
Stolen card
Return card
Retain card
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 21
Notation for data and control analysis





Ellipses. data provided from or delivered to a
viewpoint
Control information enters and leaves at the top
of each box
Data leaves from the right of each box
Exceptions are shown at the bottom of each box
Name of next event is in box with thick edges
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 22
Exception description


Most methods do not include facilities for
describing exceptions
In this example, exceptions are
•
•
•
Timeout. Customer fails to enter a PIN within the allowed time
limit
Invalid card. The card is not recognised and is returned
Stolen card. The card has been registered as stolen and is
retained by the machine
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 23
Use cases



Use-cases are a scenario based technique in the
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 24
Lending use-case
Lending services
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 25
Library use-cases
Lending services
Library
User
User administration
Supplier
©Ian Sommerville 2000
Library
Staff
Catalog services
Software Engineering, 6th edition. Chapter 6
Slide 26
Catalogue management
Item:
Library Item
Books:
Catalog
Cataloguer:
Library Staff
Bookshop:
Supplier
Acquire
New
Catalog Item
Dispose
Uncatalog Item
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 27
Social and organizational factors




Software systems are used in a social and
organizational context.
This can influence or even dominate system
requirements
Social and organizational factors are not a single
viewpoint but influence all viewpoints
Good analysts must be sensitive to these factors
but currently no systematic way to tackle their
analysis
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 28
Example

Consider a system which allows senior
management to access information without going
through middle managers
•
•
•
Managerial status. Senior managers may feel that they are too
important to use a keyboard. This may limit the type of system
interface used
Managerial responsibilities. Managers may have no
uninterrupted time where they can learn to use the system
Organisational resistance. Middle managers who will be made
redundant may deliberately provide misleading or incomplete
information so that the system will fail
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 29
Requirements validation



Demonstrating that the requirements define the system
that the customer really wants
High requirements error costs make validation important
Cost of fixing a requirement error:
•
•
•
•
•
•
Phase
requirements
design
coding
testing
operation
©Ian Sommerville 2000
Cost
2
5
15
50
150
Software Engineering, 6th edition. Chapter 6
Slide 30
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?
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 31
Requirements validation techniques

Requirements reviews
•

Prototyping
•

Using an executable model of the system to check requirements.
Covered in Chapter 8
Test-case generation
•

Systematic manual analysis of the requirements
Developing tests for requirements to check testability
Automated consistency analysis
•
Checking the consistency of a structured requirements
description
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 32
Requirements reviews



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 and users can
resolve problems at an early stage
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 33
Review checks




Verifiability. Is the requirement realistically
testable?
Comprehensibility. Is the requirement properly
understood?
Traceability. Is the origin of the requirement
clearly stated?
Adaptability. Can the requirement be changed
without a large impact on other requirements?
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 34
Requirements management


Requirements management is the process of
managing changing requirements during the
requirements engineering process and system
development
Requirements are inevitably incomplete and
inconsistent
•
•
New requirements emerge during the process as business needs
change and a better understanding of the system is developed
Different viewpoints have different requirements and these are
often contradictory
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 35
Requirements change



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
The business and technical environment of the
system changes during its development
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 36
Requirements evolution
Initial
understanding
of problem
Changed
understanding
of problem
Initial
requirements
Changed
requir ements
Time
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 37
Enduring and volatile requirements


Enduring requirements. Stable requirements
derived from the core activity of the customer
organisation. E.g. a hospital will always have
doctors, nurses, etc. May be derived from domain
models
Volatile requirements. Requirements which
change during development or when the system is
in use. In a hospital, requirements derived from
health-care policy
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 38
Traceability


Traceability is concerned with the relationships
between requirements, their sources and the
system design
Source traceability
•

Requirements traceability
•

Links from requirements to stakeholders who proposed these
requirements
Links between dependent requirements
Design traceability
•
Links from the requirements to the design
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 39
A traceability matrix
Req.
id
1.1
1.2
1.3
2.1
2.2
2.3
3.1
3.2
1.1
1.2
1.3
U
R
U
R
©Ian Sommerville 2000
2.1
2.2
2.3
3.1
R
3.2
U
R
R
R
U
U
U
U
R
R
Software Engineering, 6th edition. Chapter 6
Slide 40
SE tool support

Requirements storage
•

Change management
•

Requirements should be managed in a secure, managed data
store
The process of change management is a workflow process
whose stages can be defined and information flow between
these stages partially automated
Traceability management
•
Automated retrieval of the links between requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 41
Requirements change management


Should apply to all proposed changes to the
requirements
Principal stages
•
•
•
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 42