Processes used to discover, analyse and validate system requirements Requirements Engineering Processes

Requirements Engineering Processes

Processes used to discover,
analyse and validate system
requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 1
Requirements engineering processes

Generic activities common to all processes
•
•
•
•
Requirements elicitation
Requirements analysis
Requirements validation
Requirements management
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 4
The requirements engineering process
Feasibility
study
Requirements
elicitation and
analysis
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
User and system
requirements
Requirements
document
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 5
Feasibility studies

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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 6
Feasibility study implementation

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?
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 7
Elicitation and analysis


Technical staff work 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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 8
Problems of requirements analysis






Stakeholders don’t know what they really want
Stakeholders may want more than is feasible
Stakeholders express requirements in their own terms
Different stakeholders may have conflicting
requirements
Organisational and political factors may influence the
system requirements
The requirements change during the analysis process.
New stakeholders may emerge and the business
environment change
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 9
The requirements analysis process
Requir ements
definition and
specification
Requirements
validation
Process
entry
Domain
understanding
Prioritization
Requirements
collection
Conflict
resolution
Classification
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 10
Viewpoint-oriented elicitation



Stakeholders are members of different groups
with different problem viewpoints
Valuable approach because it recognizes the
potential for requirements conflicts, and explicitly
focuses on different perspectives
Different methods have different kinds of
“viewpoints”, with different strengths and
weaknesses
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 13
ATM system 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 15
External viewpoints – based on services




Natural to think of end-users as receivers of
system services
Viewpoints are a natural way to structure
requirements elicitation
It is relatively easy to decide if a viewpoint is
valid
Viewpoints and services may be used to structure
non-functional requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 17
The VORD method
Viewpoint
identification
©Ian Sommerville 2000
Viewpoint
structuring
Viewpoint
documenta tion
Software Engineering, 6th edition. Chapter 6
Viewpoint
system ma pping
Slide 19
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 21
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 22
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 23
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 24
Viewpoint documentation VORD standard forms
Vie wpoint te mplate
Re feren ce :
The viewpoint name.
Attribu tes:
Attributes
providing
viewp oint information.
Eve nts:
A reference to a set of event
scenarios describing
how
the system reacts to
viewp oint events.
S e rvices
A reference to a set of
service descriptions.
S ub-VPs:
The names of
subviewp oints.
©Ian Sommerville 2000
S e rvice template
Re feren ce :
The service name.
Rationale:
Reason why the service is
provided.
S pecification:
Reference to a list of service
specifications. These
may
be expressed in different
notations.
Vie wpoints:
List of viewpoint names
receiving the service.
Non -function al
Reference to a set of non requiremen ts:
functional
requirements
which constrain the service.
Provider:
Reference to a list of system
objects which provide the
service.
Software Engineering, 6th edition. Chapter 6
Slide 25
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 26
Scenarios



Scenarios are descriptions of how a system is
used in practice
People can relate to these more readily
Particularly useful for adding detail
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 27
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 28
Event scenarios


Event scenarios describe how a system responds
to the occurrence of some particular event
VORD includes a diagrammatic convention for
event scenarios.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 29
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 30
Exception description


Unlike most methods, event scenarios
include facilities for describing exceptions
In this example, exceptions are
•
•
•
Timeout.
Invalid card.
Stolen card.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 32
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 33
Library use-cases
Lending services
Library
User
User administration
Supplier
©Ian Sommerville 2000
Library
Staff
Catalog services
Software Engineering, 6th edition. Chapter 6
Slide 35
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 36
Social and organisational factors



Software systems are used in a social and
organisational context. This can influence or even
dominate the system requirements
Social and organisational factors are not a single
viewpoint but are influences on 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 37
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 38
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
Problem with ethnography is that it studies
existing practices which may have some
historical basis which is no longer relevant
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 40
Requirements validation


Demonstrating that the requirements define the
system that the customer really wants
Requirements error costs are high so validation is
very important
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 43
Requirements checking





Validity.
Consistency.
Completeness.
Realism.
Verifiability.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 44
Requirements validation techniques




Requirements reviews
Prototyping
Test-case generation
Automated consistency analysis
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 45
Requirements reviews




Regular reviews during requirements definition
Both client and contractor staff should be involved
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 46
Review checks




Verifiability.
Comprehensibility.
Traceability.
Adaptability.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 47
Automated consistency checking
Requirements
in a formal language
Requirements
problem report
Requirements
processor
Requirements
analyser
Requir ements
database
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 48
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 49
Requirements change



Change in priority of requirements from different
viewpoints
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 50
Enduring and volatile requirements


Enduring requirements.
Volatile requirements.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 52
Classification of volatile requirements

Mutable requirements
•

Emergent requirements
•

Requirements that emerge as understanding of the system
develops
Consequential requirements
•

Requirements that change due to the system’s environment
Requirements that result from the introduction of the
computer system
Compatibility requirements
•
Requirements that depend on other systems or
organisational processes
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 53
Requirements management planning

During the requirements engineering process, you have to
plan:
•
Requirements identification
» How requirements are individually identified
• A change management process
» The process followed when analysing a
requirements change
•
Traceability policies
» The amount of information about requirements relationships that is maintained
• CASE tool support
» The tool support required to help manage requirements
change
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 54
Traceability




Traceability is concerned with the relationships
between requirements, their sources and the
system design
Source traceability
Requirements traceability
Design traceability
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 55
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 56
CASE tool support



Requirements storage
Change management
Traceability management
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 57
Requirements change management

Should apply to all proposed changes to the
requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 58
Requirements change management
Identified
problem
Problem analysis and
change specification
©Ian Sommerville 2000
Change analysis
and costing
Software Engineering, 6th edition. Chapter 6
Change
implementation
Revised
requirements
Slide 59