PREview

Overview

PREview focuses on viewpoints for requirements engineering of computer-based systems but the viewpoint-concept is also used in various other areas of expertise. In communications, the ODP (Open Distributed Processing) Reference Model defines viewpoints from which a system can be specified. In CSCW viewpoints are also used to structure organisational analyses. However, these have not adapted the explicit notion of a viewpoint, but use it as a general multiple perspective approach to analysis.

The CORE method developed by Mullery was the first method to use viewpoints as an explicit notion. Nuseibeh and Greenspan have developed similar methods, in which viewpoints are a central notion.

PREview is a pragmatic adaptation of these older methods. The traditional viewpoint-oriented approaches are quite inflexible, which makes it hard to introduce these methods into existing businesses. PREview is not prescriptive about the methods and notations to be used, thereby making it easier to be integrated into existing requirements methods.

PREview aims to improve the quality of requirements specification by providing a framework for the early phases of the requirements process.

PREview Process-Data Diagram

Using meta-modelling, the PREview process will be explained in the coming paragraphs.

Figure 1 shows the activities within the PREview process. For clarity, the definition of these activities will not be shown in a table, as is common in meta-modelling, but will be explained in the chapter #The PREview process.

These activities have several concepts, or deliverables, which can be found in the meta-data table below. These concepts are linked to the Process-diagram above, creating the process-data diagram. Some of the concepts in the table have a definition unique to the PREview method, and will be defined using as source. More generic concepts are defined using more standardized definitions.

The PREview process

The activities in the process-data model are explained in this paragraph.

Requirements discovery

The requirements discovery phase consists of several sub-activities.

Identify Concerns: Concerns are identified through discussion with the principal stakeholders. These are typically the client and the developer. The stakeholders’ principal concerns for the system are elicited through interviews and questionnaires.

Elaborate concerns : Once identified, concerns must be elaborated into a form which is directly applicable. The concerns are elaborated into external requirements and questions sets which will function as a checklist. These questions will be used as a test of compliance when the viewpoints are first discovered. By using this check-list, PREview will identify conflicts between two or more requirements in an early stage.

Identify viewpoints : A PREview Viewpoint represents a perspective used to map requirements derived from the problem domain onto the system to be developed. This way the software or systems engineering problem is analysed from the perspectives of the various actors (human or machine) who must interact with the system or who have some stake in the system. “The term 'viewpoint' is broadly synonymous with perspective”. Viewpoints fall into one of these classes:

Interactors (Human operators and modules of the system)

Indirect Stakeholders (e.g. operating organisation / standards / regulatory bodies

Domain Phenomena (Restrictions of the system in terms of technical restraints)

Viewpoints should be decomposed until they represent a single cohesive perspective, known as the focus of the viewpoint, and they’re source can be identified (see meta model).

Discover requirements : The requirements, elicited from the set of different viewpoints will be documented and analysed in the next stage of the process.

Requirements analysis

The requirements collected during the discovery phase are integrated and analysed. Usually, this will result in the identification of missing requirements, inconsistencies and requirements conflicts.

Typically, the requirements in a large system will be documented by a mixture of natural language, semi-formal, formal and graphical notation. A systematic approach to discovering inconsistency is used in PREview, loosely based on the House of Quality used by Quality Function Deployment (QFD). The table below shows an example for an on-board train protection system (GAAP), taken from [1]. Here the safe state assurance concerns (SS1, SS2, SS3) are plotted against the external requirements from, in this case, safety and compatibility concerns (ER1-7).

SS1: Detection of excess speed.

SS2: Detection of overshooting.

ER1: The system shall detect the occurrence of excess speed.

ER2: The system shall detect the occurrence of overshoot.

ER3: The system shall apply emergency braking when either excess speed or overshoot is detected.

As can be expected, SS1 shows a reinforcing effect on ER1 and ER3, and SS2 shows a reinforcing effect on ER2 and ER3. A zero means there is no relation, or a neutral effect. More interesting of course are the possible conflicts that arise.

In this case, SS3 shows conflicts with the following external requirements:

ER5: The GAAP software must execute within the application cycle of the existing onboard software.

ER6: The reaction time of the GAAP software to the change of state of one bit in the variants table must be 312ms.

ER7: The real-time performance of the existing on-board software must be maintained.

All conflicting, redundant and non-compliant requirements will be moved to the next stage of the PREview process: Requirements Negotiation. Compliant and mutually consistent requirements will be moved to the final stage of the PREview: #Requirements definition.

Requirements negotiation

Any inconsistencies between requirements or incompleteness of these requirements will lead to re-entry of the requirement discovery phase, to discover further information and refine existing but incomplete information.

Requirements definition

Compliance and mutually consistent requirements will be integrated and formatted into a requirements specification document.

This concludes the PREview process.