Transcript Requirements Engineering Processes

Chapter 6
Requirements Engineering Process
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 1
Requirements Engineering Processes

Processes used to discover,
analyze and validate system
requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 2
Objectives


To describe the principal requirements
engineering activities
To introduce techniques for requirements
elicitation and analysis

To describe requirements validation

To discuss requirements management
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 3
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 4
Topics covered

Feasibility studies

Requirements elicitation and analysis

Requirements validation
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 5
Feasibility studies

A feasibility study decides whether or not the
proposed system is worthwhile. The study 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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 6
Feasibility study implementation


Based on information collection, information
assessment 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 skills?
What facilities must be supported by the proposed
system?
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 7
Topics covered

Feasibility studies

Requirements elicitation and analysis

Requirements validation
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 8
Requirement 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
Involves many stakeholders, such as end-users,
managers, engineers, domain experts, trade
unions, etc.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 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,
because new stakeholders may emerge and the
business environment may change
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 10
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 11
Techniques for requirements
elicitation and analysis

Viewpoint-oriented elicitation

Scenarios

Ethnography

State models

Prototyping
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 12
Banking ATM system – An example

Services include cash and check deposit, 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 13
ATM viewpoint resources








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 14
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 analyze system
requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 15
Types of viewpoint

Receivers of services
•

Data sources or sinks
•

Viewpoints are external to the system and receive services
from the system. Most suited to interactive systems
Viewpoints are responsible for producing or consuming
data.
Representation frameworks
•
Viewpoints represent particular types of system model.
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 16
The VORD method

View Point-Oriented Requirement Definition
Viewpoint
identification
©Ian Sommerville 2000
Viewpoint
structuring
Viewpoint
documenta tion
Software Engineering, 6th edition. Chapter 6
Viewpoint
system ma pping
Slide 17
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 18
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
Software
size
Printe
r
Hardware
maintenance
Funds
transfer
Software Engineering, 6th edition. Chapter 6
Transaction
log
Remote
software
upgrade
Order
cheques
Bank
teller
Invalid
user
Security
Message
passing
Card
retention
Card
validation
Slide 19
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 20
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 21
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 22
Scenarios



Scenarios are descriptions of how a system is
used in practice (the interaction)
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 23
Scenario descriptions
Including

System state description 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 24
Structured approach for scenarios

Event Scenarios

Use-cases
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 25
Event scenarios


An event is an occurrence of something important
Event scenarios are used to describe how a
system responds to the occurrence of some
particular event such as ‘start transaction’
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 26
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 27
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 28
Lending use-case
Lending services
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 29
Library use-cases
Lending services
Library
User
User administration
Supplier
©Ian Sommerville 2000
Library
Staff
Catalog services
Software Engineering, 6th edition. Chapter 6
Slide 30
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 31
Ethnography




A social scientists spends a considerable time
observing and analysing how people actually
work
People do not have to explain or articulate their
work
Social and organizational factors of importance
may be observed
Ethnographic studies have shown that work is
usually richer and more complex than suggested
by simple system models
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 32
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
Requirements that are derived from cooperation
and awareness of other people’s activities
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 33
Topics covered

Feasibility studies

Requirements elicitation and analysis

Requirements validation
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 34
Requirements validation


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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 35
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 36
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 37
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 38
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 39
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, prioritisation and
validation
Systems have multiple stakeholders with different
requirements
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 40
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
©Ian Sommerville 2000
Software Engineering, 6th edition. Chapter 6
Slide 41