Viewpoint-oriented approaches to requirements engineering (Mullery, 1979) (Finkelstein, et al., 1990) (Kotonya and Sommerville, 1992, Kotonya and Sommerville, 1996) organise both the elicitation process and the requirements themselves using different viewpoints. A viewpoint is a way of organising the requirements for a software system, based on some perspective such as an end-user perspective or a manager’s perspective.
A key strength of viewpoint-oriented analysis is that it recognises the existence of multiple perspectives and provides a framework for discovering conflicts in the requirements proposed by different stakeholders. Viewpoints can be used as a way of classifying different types of stakeholder and other sources of requirements.
There are three generic types of viewpoint:
- Interactor viewpoints that represent people or other systems that interact directly with the system. In the bank ATM system, examples of interactor viewpoints are the bank’s customers and the bank’s account database.
- Indirect viewpoints that represent stakeholders who do not use the system themselves but who influence the requirements in some way. In the bank ATM system, examples of indirect viewpoints are the management of the bank and the bank security staff.
- Domain viewpoints that represent domain characteristics and constraints that influence the system requirements. In the bank ATM system, an example of a domain viewpoint would be the standards that have been developed for inter-bank communications.
Typically, these viewpoints will provide different types of requirement. Interactor viewpoints provide detailed system requirements covering the system features and interfaces. Indirect viewpoints are more likely to provide higher-level organisational requirements and constraints. Domain viewpoints normally provide domain constraints that apply to the system.
Almost all organisational systems must inter-operate with other systems in the organisation. When a new system is planned, the interactions with other systems must be planned. The interfaces offered by these other systems have already been designed. These may place requirements and constraints on the new system. Furthermore, new systems may have to conform to existing regulations and standards and these constrain the system requirements.
You should identify high-level business and non-functional requirements early in the RE process. The sources of these requirements may be useful viewpoints in a more detailed process. They may be able to expand and develop the high-level requirements into more specific system requirements.
As well as viewpoints associated with the system buyer and users, you may also identify engineering viewpoints. Engineering viewpoints may be important for two reasons. Firstly, the engineers developing the system may have experience of similar types of system and may be able to suggest requirements from their experience. Secondly, technical staff who have to manage and maintain the system may have requirements that will help simplify this task. System management requirements are increasingly important as system management costs are an increasing proportion of the total lifetime costs for a system.
Finally, viewpoints that provide requirements may come from the marketing and external affairs departments in an organisation. This is especially true for web-based systems, particularly e-commerce systems and shrink-wrapped software products. Web-based systems must present a favourable image of the organisation running the system as well as delivering functionality to the user. For software products, the marketing department should know what system features will make the system more marketable to potential buyers.
References
Mullery, G. (1979). “CORE – A Method for Controlled Requirements Specification”. Proc. 4th Int. Conf. on Software Engineering, Munich, IEEE Press.
Finkelstein, A., Kramer, J., et al. (1990). “Viewpoint oriented software development”. Proc. 3rd Int. Workshop on Software Engineering and its Applications, Toulouse, France.
Kotonya, G. and Sommerville, I. (1992). “Viewpoints for requirements definition”. BCS/IEE Software Engineering J., 7(6): 375–87.
Kotonya, G. and Sommerville, I. (1996). “Requirements engineering with viewpoints”. BCS/IEE Software Engineering J., 11(1): 5–18.