1. VOSE / VORD
Lecture 08

2. Viewpoint-Oriented System Engineering (VOSE)
VOSE was originally proposed as a framework for integrating development methods utilized in development of large, complex systems; it addresses the entire system development with a variety of participants (each with different views)
Each participant’s role in development process and his/her specific view of the problem domain is captured
Each viewpoint is associated with a particular developer --- a viewpoint owner.
VOSE viewpoints (completed templates) are then grouped and analyzed for conflicts and resolved
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

3. Viewpoint-Oriented System Engineering (VOSE)
The VOSE viewpoint is a template which includes:
A Style or a scheme of representing the view
(e.g. designer and req. analyst may use different notational diagrams)
Work-plan that describes the development strategy that uses the style to produce the specification
The problem domain ( the particular perspective) described with the style
Specification of the problem produced according to the Work-Plan
Work history and the current development state
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

4. Standard viewpoint template slots
Style and Work-plan template
Standard viewpoint template slots
STYLE:
Use Case Diagram to show actors
and system’s functional interaction
Work-plan:
Use scenarios to show high level requirements
Identify actors
identify the processing function
associated with each actor
Link the actors to the functions
Draw the system boundary
Problem Domain Description 1
(actor 1 perspective)
Actual Specification in
Use Case diagram
Work record
Problem Domain Description 2
(actor 2 perspective)
Problem Domain Description 3
(actor 3 perspective)
View 1
View 2
View 3
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

5. Library example
Consider a library item presented by the user at the issue desk for borrowing, returning or reserving
‘Library world’ can be partitioned into the domains of the issue desk and the library user
Data-flow and state transition schemes are used to model the library item from point of view each domain
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

6. Data-flow model -Issue desk domain
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

7. State transition model -Issue Desk Domain
State transition - Library user domain
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

8. Conflict resolution
Important to ensure that consistency between different representations of the domains
For similar styles conflicts are resolved by checking for the loss of continuity between the models
For different styles the correspondences between representation schemes need to be identified to facilitate consistency checking
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

9. Consistency checking
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

10. Correspondence between transition and function
Correspondence between state and data
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

11. Mapping on different styles same domain
Mapping on different domains same style
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

12. Viewpoint-Oriented Requirements Definition (VORD)
VORD is another variation on handling requirements with viewpoints
It handle mostly interactive systems
VORD defines two fundamental classes of viewpoints:
Direct Viewpoints:
These correspond directly to the clients of the system who receive services from the system and interacts with the system (through entering data and control information).
Indirect viewpoints:
These correspond to those who have interests (via putting constraints or expectations) in the services of the system but do not interact directly with the system themselves
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

13. Examples of direct and indirect viewpoints
A systems planning viewpoint which is concerned with future delivery of library services
(indirect)
A library user viewpoint which is concerned with accessing the system services through the internet
(direct)
A trade-union viewpoint which is concerned with the effects of system introduction on staffing levels and library staff duties
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

14. Issues to be taken into account for interactive systems
User interface.
The ability to model and represent user interface requirements
To address key role of end user interaction
User classes.
Interactive systems often have varied classes of users with varying y conflicting/requirements and expectations
To enable system to expose potential conflicts
Other systems.
Interactive systems may interface with other systems in their environment
Existing system may generate conflicting requirement for the intended system
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

15. Requirement issues for interactive systems
Indirect system concerns.
The issues related to system design and implementation,
The influence of the system on the organisation and the system’s influence on the environment.
Quality of service.
The closeness of the system to the end-user lends special significance to quality of the service delivered. Quality concerns include:
Availability
Performance
Usability
Form of delivery
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

16. VORD The VORD method is based on three main iterative steps, namely:
1. Viewpoint identification and structuring
2. Viewpoint documentation
3. Viewpoint requirements analysis, specification and validation
Round edged boxes – processes
Square boxes – products
Each product can be viewed as check point for a review process
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

17. Iterative VORD process model
First step in VORD
To identify and structure the relevant VPs in the problem domain
Start point for VP identification is to abstract statements organizational needs etc
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

18. Iterative VORD process model
Second step in VORD
To document identified VPs by documenting
Viewpoint, identifier, label and description
VP Type – direct or indirect
VP Attributes – identify the application domain
VP requirements – a set of required services, control requirement
Event scenario for the description of VPs
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

19. Iterative VORD process model
Third step in VORD
To identify and resolve errors and conflicts
End result is ‘ Requirement Specification Document’
Viewpoint specializations or subclasses.
Viewpoint history that describes the evolution of viewpoint requirements
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

20. Interactive system definition
Interactive systems can be defined as:
The class of systems whose operations involve a significant degree of user interaction.
Common media for interaction include the keyboard, voice recognition, video, touch screen, mouse etc.
The process of formulating the software requirements for such systems must take into account the important issues associated with such systems.
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

21. Using VORD to specify an interactive system
The ATM is a good example of an interactive system
it embodies all the attributes discussed earlier.
VORD method can be used to formulate the requirements of the ATM.
VORD has been primarily developed to support the specification of interactive systems and focuses on the external entities that interact with the system or affect its development.
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

22. ATM requirements
A simplified ATM contains an embedded software system to drive the machine hardware and to communicate with the bank’s customer database.
1. The system accepts customer requests and produces cash and account information, and provides for limited message passing and funds transfer.
2. The ATM is also required to make provisions for major classes of customers, namely customers whose account is with the bank which owns the ATM (home customers) and customers from other banks who have ATM access (foreign customers).
3. ATM users are issued with a cash-card and a personal identification number (PIN) that they must use to access the ATM services.
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

23. ATM requirements (contd..)
4. Home customers receive all the services provided by the ATM. Foreign customers can only receive a subset of ATM services (i.e. they can only access the ATM to withdraw cash).
5. The ATM is also required to update the customer account database each time there is a cash withdrawal or funds transfer.
6. All the services provided by the ATM are subject to certain conditions, which can be considered at different levels.
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

24. ATM requirements (contd.)
6.1 The top level sets out conditions necessary for accessing the services. These include a valid ATM cash-card and correct personal identification number (PIN).
6.2 The next level is concerned with service requests and is subject to the availability of particular services.
6.3 At lowest level, all services provided by the ATM are subject to specific conditions set out for their provision.
For example, customers can only withdraw cash to a maximum of their balance.
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

25. Viewpoint notation
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
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

26. Identifying ATM Viewpoints
The process of understanding the system under analysis, places a lot of reliance on the ‘system authorities’
These are people or documents with an interest or specialist knowledge of the application domain.
They include system end-users, system procurers, system engineers and documentation of existing system(s).
VORD has generalised these ‘system authorities’ into a set of abstract viewpoint classes, which can be used as a starting point for finding viewpoints specific to the problem domain.
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

27. Abstract viewpoint classes
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

28. Using abstract viewpoints to identify application specific viewpoints
Eliminate viewpoint classes which are not relevant for the specific system being specified.
In the ATM example,
let us assume that there is no external certification authority and no environmental effects.
We therefore do not need to look for viewpoints under these headings.
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

29. Using abstract viewpoints to identify application specific viewpoints
Consider the system stakeholders i.e. those people who will be affected by the introduction of the system.
If these stakeholders fall into classes which are not part the organisational class hierarchy, add these classes to it.
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

30. Using abstract viewpoints to identify application specific viewpoints
Using a model of the system architecture, identify system viewpoints, i.e. viewpoints representing other systems.
In the example of the ATM we can identify two main sub- system, the customer database and card database.
We note that architectural models of systems almost always exist because new systems must be integrated with existing organisational systems.
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

31. Using abstract viewpoints to identify application specific viewpoints
Identify system operators who use the system on a regular basis, who use the system on an occasional basis and who request others to use the system for them.
All of these are potential viewpoints.
We can identify four instances of direct viewpoint in this example namely the bank customer (regular), ATM operator (occasional), the bank manager (occasional).
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

32. Using abstract viewpoints to identify application specific viewpoints
For each indirect viewpoint class which has been identified, consider the roles of the principal individual who might be associated with that class.
For example, under the viewpoint class ‘customer’, we might be interested in the roles of ‘regulations officer’, ‘maintenance manager’, ‘operations manager’ etc.
There are often viewpoints associated with these roles.
In the ATM example, there are many possible indirect viewpoints but we will confine our analysis to a security officer and a organisational policy, represented by the bank viewpoint.
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

33. ATM viewpoints
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

34. Bank staff viewpoint documentation
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

35. Bank customer viewpoint documentation
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

36. Documenting other viewpoints
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST

37. Documenting viewpoint attributes
Software Requirement Engineering, by Asst Prof Athar Mohsin-MCS-NUST