1. Viewpoint Oriented Requirement Definition (VORD) Amna Shifia Nisafani amna@is.its.ac.id Department of Information Systems Subject : Requirement Engineering

2. Page 2  To introduce the notion of VORD and how to use it to restructuring requirement and specification

3. Page 3  An Overview of Viewpoint  Viewpoint Process  Example #1  Example #2

4. AN OVERVIEW OF VIEWPOINT

5. Page 5  To understand the requirements for a system, we need to understand a number things:  The services the system provides...  The application domain of the system  Non-functional constraints on the system and its development process  The environment where the system is to be installed and organizational issues affecting the system’s operation.  Why are these issues important to the analysis and specification of requirements?

6. Page 6  Consequently, the requirements engineering process involves the capture, analysis and resolution of many ideas, perspectives and relationships at varying levels of detail.  To address this problem a number of methods have evolved based on the notion of viewpoints.

7. Page 7  They explicitly recognize of the diversity of the sources of requirements  They provide a mechanism for organization and structuring diverse information  They provide a means for requirements sources or stakeholders to identify and check their contribution to the requirements  They provide a framework for exposing conflicting requirements

8. Page 8  Viewpoint-based method primarily intended to specify interactive systems  VORD is based on viewpoints that focus on user issues and organizational concerns  The model adopted for viewpoints is a service- oriented model  Viewpoints are analogous to clients in a client-server system  The system delivers services to viewpoints and viewpoints pass control information to the system

9. Page 9  VORD viewpoints fall into two classes:  Direct viewpoints These correspond directly to clients in that they receive services from the system and send control information and data to the system. o Are either system operators/users or other systems which are interfaced to the system being developed  Indirect viewpoints Indirect viewpoints have an ‘interest’ in some or all the services which are delivered by the system but do not interact directly with it. o Indirect viewpoints may generate requirements which constrain the services delivered to direct viewpoints o Indirect viewpoints vary greatly

10. VIEWPOINT PROCESS

11. Page 11 VORD is based on three main iterative steps, namely: 1.Viewpoint identification and structuring  Concerned with identifying and structuring relevant problem domain viewpoints 2.Viewpoint documentation  Concerned with documenting the documenting the viewpoints 3.Viewpoint requirements analysis and specification  Identifying errors and inconsistencies in the viewpoint documentation and resolving them

12. Page 12

13. Page 13 (Event scenarios)

14. Page 14  VORD uses a simple graphical notation to represent a viewpoint:  A rectangular box represents the viewpoint.  The viewpoint identifier is shown on the top left-hand corner of the box and the viewpoint label in the lower half of the box.  The viewpoint type is shown on the top right half of the box.  A viewpoint attribute is indicated by a vertical line dropping from the left side of the box.  Viewpoint specializations or sub-classes are shown from left to right.  The notation is augmented with viewpoint information templates

15. Page 15 15

16. Page 16  “System authorities” are people or documents with an interest or specialist knowledge of the application domain.  A set of viewpoint classes, which can be used as a starting point for finding viewpoints specific to the problem domain

17. Page 17  Prune the abstract viewpoint class hierarchy to eliminate viewpoint classes which are not relevant for the specific system being specified.  Consider the system stakeholders, i.e. those people who will be effected by the introduction of the system.  Using a model of system architecture, identify system viewpoints, i.e. viewpoints representing other systems.  This model may either be derived from the existing system models or may have to be developed as part of RE.  Identify system operators who use the system on a regular basis, who use the system on an occasional basis, who request others to use the system for them.  For each indirect viewpoint class which has been identified, consider the roles of the principal individual who might be associated with that class.

18. Page 18  VORD uses event scenarios to model the dynamic behavior of the system.  An event scenario is defined as a sequence of events together with exceptions which may arise during the interchange of information between the viewpoint and the intended system  Viewpoint events are a reflection of control requirements as perceived by the user.  VORD uses an extended state transition notation to model event scenarios  All interactions between direct viewpoints and the system should be described using event scenarios  Individual scenarios combine to model the complete system behavior

19. Page 19

20. Page 20

21. Page 21  In VORD user interface requirements are represented as constraints on viewpoint services  They are associated with constraints that describe the mode and presentation of viewpoint services  The process of constructing the user interface is informed by viewpoint event scenarios which describe the interaction between the viewpoint and the system

22. Page 22

23. Page 23  The objective of viewpoint requirements analysis is to establish that viewpoint requirements are correct and ‘complete’. There are two main stages to this:  Requirements checking is concerned with ensuring the viewpoint documentation is consistent and correct  Conflict analysis and requirements negotiation is concerned with ensuring that conflicting requirements are exposed and conflicts resolved

24. Page 24

25. EXAMPLE #1 - AUTOTELLER SYSTEM (BANCOMAT)

26. Page 26  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

27. Page 27

28. Page 28  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

29. Page 29 Unallocated services may suggest new viewpoints (* e.g. Software Maintenance)

30. Page 30 Basis for assignment of reqs. priorities and structuring of subsequent development Also control/data info is inherited

31. Page 31

32. Page 32

33. Page 33  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

34. Page 34  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

35. Page 35 (check card) (check PIN) details

36. Page 36  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

37. Page 37  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]

38. EXAMPLE #2 -VIDEO ON DEMAND SERVICE

39. Page 39  Consider the requirements of a system intended to provide its users with a video-on demand service (pay-per-view).  The system users are to be provided with decoders to access the system and request for their favorite films to be played.  The system is intended to support two types of customers; standard and gold. o Standard customers will allowed to view any 4 films no more than once in a day o Gold customers will be allowed continuos viewing of any 5 films in a day. In addition gold customers will be allowed to ‘pause’, ‘rewind’ and ‘forward’ their films

40. Page 40  More requirements for the video-on demand service (pay-per-view).  The system is intended to support multiple requests for a film by up to 5 users.  The system is to be interfaced to a digitized video archive for film access  The quality manager requires that the system delivers a minimum film quality of 22 frames/sec (at any one time) with good sound quality  The users of system would like a service availability of no less than 98%  The system administrator requires that system be taken down for maintenance twice every month month

41. Page 41

42. Page 42

43. Page 43

44. Page 44

45. Page 45

46. Page 46

47. Page 47  Ian Sommerville, Gerald Kotonya. Requirement Engineering Processes and Technique. John Wiley & Sons, 1998.  Raimundas Matulevičius. VORD - Viewpoint Oriented Requirements Definition. SIF 8060 - Modellering av informasjonssystemer, 2003  Frederick T Sheldon. Viewpoint-Oriented Requirements Definition. Software Requirements Analysis and Specification