1 / 34

Lezione 5. RE e Viewpoints

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. Requirements elicitation and analysis in context.

orsen
Download Presentation

Lezione 5. RE e Viewpoints

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related