Transcript Requirements Engineering - ISTI-CNR

Lezione 5. RE e Viewpoints
•

Analisi dei requisiti
•
•
•


[S2000, Cap. 6]
Viewpoint oriented analysis
Metodo VORD ed esempio ATM (Bancomat)
Event scenarios - VORD and UML Use Cases
Validazione dei requisiti
Evoluzione dei requisiti
Slide 1
Requirements elicitation and analysis in context
Feasibility
study
Requirements
elicitation and
analysis
Consistenti
Completi
Realistici
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
(specification)
* User and system
requirements
Requirements
document
requirements = ‘requirements definition’ in Sommerville 5th edition
* User
System requirements = ‘requirements specification’ in Sommerville 5th edition
Slide 2
Requirements analysis process
Requir ements
definition and
specification
Requirements
validation
Process
entry
Domain
understanding
Prioritization
Requirements
collection
Conflict
resolution
‘shall…’
‘should…’
Classification
Slide 3
Problems of requirements analysis

Stakeholders (sources of requirements) don’t know what they really
want
•

Stakeholders express requirements in their own terms
•


assuming knowledge of domain-specific terms and concepts
Different stakeholders may have conflicting requirements
Organisational and political factors may influence the system
requirements
•

and may express unrealistic requests
including a manager’s personal interest...
The requirements change during the analysis process, and new
stakeholders may emerge
•
e.g. because of restructuring in the Client’s organisation, changes in
management or economic scenario
Slide 4
Viewpoint-oriented analysis

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
Slide 5
Multiple problem viewpoints
Problem
to be
analysed
Slide 6
Types of viewpoint

Data sources or sinks
•

Representation frameworks
•

Viewpoints are responsible for producing or consuming data.
Analysis involves checking that the data produced is actually
consumed and viceversa (Methods: SADT ‘77, CORE, ‘79)
Viewpoints represent particular types of system model. These
may be compared to discover requirements that would be
missed using a single representation. (VOSE ‘90)
Receivers of services
•
Viewpoints are external to the system and receive services from
it. Most suited to interactive systems (VORD ‘92)
Slide 7
External viewpoints (receivers of services)

Natural way to structure requirements elicitation
•

It is relatively easy to decide if a viewpoint is
valid:
•

they directly correspond to stakeholders and end-users
it must interact with the system
Viewpoints and services provide a framework for
structuring non-functional requirements
•
•
non functional requirements may be associated to a service of a
viewpoint, and
different viewpoints may have same service but different
associated non functional requirements
Slide 8
The VORD method
Viewpoint Oriented Requirements Definition
[Kotonya, Sommerville ‘92]
Viewpoint
identification
Viewpoint
structuring
Viewpoint
documenta tion
Viewpoint
system ma pping
Slide 9
VORD process model

Viewpoint identification
•

Viewpoint structuring
•

Group related viewpoints into a hierarchy. Common services are
provided at higher-levels in the hierarchy, and inherited by
lower levels
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
Slide 10
VORD standard forms
Vie wpoint te mplate
Re fer ence :
The viewpoint na me .
Attr ibutes:
Attribute s
providing
viewpoint informa tion.
Events:
A re fere nc e to a se t of
e ve nt
sc enarios de scribing how
(Event scenarios)
the system rea cts to
viewpoint events.
Ser vic es
A re fere nc e to a se t of
se rvic e desc riptions.
Sub-VPs:
The nam es of
subviewpoints.
Ser vic e te mplate
Re fer ence :
The se rvic e nam e.
Rationale :
Re ason why the se rvic e is
provide d.
Spe cific ation:
Re fere nc e to alist of service
spec ifica tions. The se m ay
be e xpresse d in diffe rent
nota tions.
Vie wpoints:
List of vie wpoint nam es
re ce iving the se rvic e .
Non-func tional
Re fere nc e to a set of non r equir ements:
func tional
re quirem ents
which constra in the service .
Pr ovide r:
Re fere nc e to alist of syste m
obje cts which provide the
se rvic e.
Slide 11
EXAMPLE: Autoteller system (bancomat)

A simplified, embedded system which offers
some services to customers of the bank, and a
narrower range of services to customers from
other banks

Services include cash withdrawal, message
passing (send a message to request a service),
ordering a statement and transferring funds
Slide 12
Viewpoint and service identification
Get
transactions
Query
balance
Customer
database
Card
returning
Manager
Machine
supplies
Message
log
Account
information
User
interface
System cost
Stolen
card
Account
holder
Remote
diagnostics
*
Reliability
Cash
withdrawal
Foreign
customer
Order
statement
Update
account
Transaction
log
Remote
software
upgrade
Software
size
Printe
r
Hardware
maintenance
Funds
transfer
Order
cheques
*
Bank
teller
Invalid
user
Security
Message
passing
Card
retention
Card
validation
Slide 13
Autoteller stakeholders - viewpoints









Bank customers
Representatives of other banks
Hardware and software maintenance engineers
Marketing department
Bank managers and counter staff
Database administrators
Security staff
Communications engineers
Personnel department
Slide 14
Viewpoint-service mapping
ACCOUNT
HOLDER
Service list
Withdraw cash
Query balance
Or der cheques
Send message
Transaction list
Or der statement
Transfer funds
FOREIGN
CUSTOMER
Service list
Withdraw cash
Query balance
BANK
TELLER
Service list
Run diagnostics
Add cash
Add paper
Send message
Unallocated services may suggest new viewpoints (* e.g. Software Maintenance)
Slide 15
Viewpoint hierarchy
All VPs
Services
Query balance
Withdraw cash
Services
Order cheques
Send message
Transaction list
Order statement
Transfer funds
Customer
Account
holder
Foreign
customer
Bank staff
Teller
Manager
Engineer
Basis for assignment of reqs. priorities and structuring
of subsequent development
Slide 16
Viewpoint data/control
ACCOUNT
HOLDER
Control input
Start transaction
Cancel transaction
End transaction
Select service
Da ta input
Card details
PIN
Am ount required
Message
Slide 17
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
Customer
Deliver cash within 1 minute
Non-funct.
requirements: of amount being confirmed
Provider:
Filled in later
Slide 18
Scenarios

Scenarios add detail to the description of functional
requirements

The description of a scenario may include
•
•
•
•
•
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
Slide 19
VORD event scenarios


In VORD, event scenarios may be used to describe how a
system reacts to events at viewpoint or service level (e.g.
‘start transaction’)
VORD includes a diagrammatic convention for event
scenarios.
•
•
•
•
Input and Output Data
Control information
Exception processing
The next expected event
Slide 20
Data and control analysis diagram - Start transaction
Card present
Valid card
Card
details
PIN
User OK
Request PIN
(check card)
Timeout
Return card
Account
number
PIN
Validate user
(check PIN)
Account
number
Select
service
Incorrect PIN
Re-enter PIN
Invalid card
Return card
Incorrect PIN
Stolen card
Return card
Retain card
Slide 21
Notation for data and control analysis diagrams





Ellipses: viewpoint input/output data
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
Slide 22
Exception description
•
•
•
•
•
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
Incorrect PIN. Another chance to digit the correct PIN is
offered before returning card
[end of ATM Example]
Slide 23
Use cases



Use-cases are a scenario based technique in the UML
(introduced by Jacobson et al. Objectory method, 1993)
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
Slide 24
Library use-cases
Lending services
Library
User
User administration
Supplier
Library
Staff
Catalog services
Slide 25
Sequence diagram for Catalogue Management use-case
Item:
Library Item
Books:
Catalog
Cataloguer:
Library Staff
Bookshop:
Supplier
Acquire
New
Catalog Item
Dispose
Uncatalog Item
Slide 26
Requirements validation
Requir ements
definition and
specification
Requirements
validation
Process
entry
Domain
understanding
Prioritization
Requirements
collection
Conflict
resolution
Classification
Slide 27



Validation: check that the requirements define the system that the Client
really wants
Performed a-posteriori, on the complete set of requirements (elicitation and
analysis work on incomplete requirements)
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
Requirements validation techniques
•
•
•
•
Manual reviews (careful readers from Client and Contractor)
Demonstration of prototype
Test case generation out of requirements - failure to design test cases may
reveal problems in the requirement
Automated analysis by CASE tools (esempio: Quarz, Quality Analyzer of
Requirements Specifications, Gnesi et al., CNR-IEI, Pisa)
Slide 28
Check points





Consistency. Are there any requirements conflicts?
(automatizzabile)
Completeness. Are all functions required by the customer
(and stakeholders) included? (non automatizzabile)
Realism. Can the requirements be implemented given
available budget and technology (non automatizzabile)
Verifiability. Is the requirement realistically testable (in
implementation)?
Traceability. Is the source of the requirement
clearly stated (in case of change)?
Slide 29
Requirements 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
Slide 30
Traceability matrix (req. - req. relations)
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
2.1
2.2
2.3
3.1
R
3.2
U
R
R
R
U
U
U
U
R
R
U : row requirement uses the (facilities specified in the) column requirement
R: weaker relation between two requirements (e.g., they refer to the same subsystem)
Realistic sets of requirements must be stored in a data base.
Traceability matrix can then be produced automatically
Slide 31
Requirements change

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
Slide 32
Requirements change management
Identified
problem
Problem analysis and
change specification
Change analysis
and costing
Change
implementation
Revised
requirements
All phases make use of requirements traceability
Slide 33
Controlled requirements evolution
Requirements
change
Requirements
document V1
System
implementation V1
Requirements
change
System
implementation V2
Requirements and system
inconsistent
Requirements
document V1
Requirements
document V2
System
implementation V1
System
implementation V2
Requirements and system
consistent
Slide 34