Lezione 5. RE e Viewpoints

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) don’t 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 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

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 (Eventscenarios)

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 changeduring 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