[S2000, Cap. 6]

1
Lezione 5. RE e Viewpoints

• S2000, Cap. 6
• Analisi dei requisiti
• Viewpoint oriented analysis
• Metodo VORD ed esempio ATM (Bancomat)
• Event scenarios - VORD and UML Use Cases
• Validazione dei requisiti
• Evoluzione dei requisiti

2
Requirements elicitation and analysis in context
Consistenti Completi Realistici

(specification)
User requirements requirements definition in
Sommerville 5th edition System requirements
requirements specification in Sommerville 5th
edition

3
Requirements analysis process
shall should
4
Problems of requirements analysis

• Stakeholders (sources of requirements) dont know
  what they really want
• and may express unrealistic requests
• 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
• including a managers personal interest...
• The requirements change during the analysis
  process, and new stakeholders may emerge
• e.g. because of restructuring in the Clients
  organisation, changes in management or economic
  scenario

5
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

6
Multiple problem viewpoints
7
Types of viewpoint

• Data sources or sinks
• 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)
• Representation frameworks
• 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)

8
External viewpoints (receivers of services)

• Natural way to structure requirements elicitation
• they directly correspond to stakeholders and
  end-users
• It is relatively easy to decide if a viewpoint is
  valid
• 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

9
The VORD method
Viewpoint Oriented Requirements
Definition Kotonya, Sommerville 92
10
VORD process model

• Viewpoint identification
• Discover viewpoints which receive system services
  and identify the services provided to each
  viewpoint
• 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
• Refine the description of the identified
  viewpoints and services
• Viewpoint-system mapping
• Transform the analysis to an object-oriented
  design

11
VORD standard forms
(Event scenarios)
12
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

13
Viewpoint and service identification


14
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

15
Viewpoint-service mapping
Unallocated services may suggest new viewpoints
( e.g. Software Maintenance)
16
Viewpoint hierarchy
Also control/data info is inherited
Basis for assignment of reqs. priorities and
structuring of subsequent development
17
Viewpoint data/control
18
Customer/cash withdrawal templates
19
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

20
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

21
Data and control analysis diagram - Start
transaction
details
(check card)
(check PIN)
22
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

23
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

24
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

25
Library use-cases
26
Sequence diagram for Catalogue Management use-case
27
Requirements validation
28

• 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)

29
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)?

30
Requirements traceability

• Traceability is concerned with the relationships
  between requirements, their sources and the
  system design
• 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

31
Traceability matrix (req. - req. relations)
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
32
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

33
Requirements change management
All phases make use of requirements traceability
34
Controlled requirements evolution