PREview

PREview (Process and Requirements Viewpoints) is a requirements method which focuses on the early stage of Requirements Engineering: discovering and documenting requirements. PREview uses a Viewpoint-Oriented Approach to enable the conversion of top-level goals (“concerns”) into requirements and constraints.[1] “Preview aims to improve the quality of requirements specification by providing a framework which can support both requirements elicitation and the structuring of the requirements document.[2]”

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.[3] 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[4] was the first method to use viewpoints as an explicit notion. Nuseibeh[5][6] and Greenspan[7] 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.

Process diagram

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 [1] as source. More generic concepts are defined using more standardized definitions.

Table of concepts

Concept Definition
CONCERN A non-negotiable REQUIREMENT whose satisfaction is essential to the success of the enterprise. It is “global” in the sense that it has a wide scope in that it potentially affects every aspect of the system rather than, for example, being satisfiable by a single component. If a “concern” does not meet these criteria, it is not a concern.[1]
REQUIREMENT A statement of the required functionality of a software component. (http://mdp.ivv.nasa.gov/mdp_glossary.html)
EXTERNAL REQUIREMENT REQUIREMENTs against which other REQUIREMENTs are validated. (no source)
QUESTIONSET A set of questions helping the analyst to create a checklist of EXTERNAL REQUIREMENTs to be compliant with those of other VIEWPOINTS.
VIEWPOINT A PREview VIEWPOINT represents a perspective used to map REQUIREMENTs derived from the problem domain onto the system to be developed. It has long been recognised that it is good practice to analyse a software or systems engineering problem 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.[1]
FOCUS In PREview, the FOCUS defines the scope of the VIEWPOINT’s REQUIREMENTs as a function of the problem domain and the components influenced in the system.[1]
CHANGE HISTORY This records changes to the information recorded in the VIEWPOINT over time. For example, a rationale for why a particular concern need not be considered by the VIEWPOINT should appear here.[1]
SOURCE The source explicitly identifies the source of the REQUIREMENTs associated with the requirement. SOURCEs may be individuals, roles, groups, or documents.[1]
REQUIREMENTS DOCUMENT The REQUIREMENTS DOCUMENT clearly states the objectives of the software to be developed, and describes the specific functionality will be included. This document forms the basis for all future design and coding. (http://www.epri.com/eprisoftware/processguide/glossary.html)

Process-data diagram

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.

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).

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.

  Safety Compatibility
ER1 ER2 ER3 ER4 ER5 ER6 ER7
Safe state Assurance SS1 + 0 + 0 0 0 0
SS2 0 + + 0 0 0 0
SS3 0 0 0 0 - - -

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.

See also

References

  1. 1 2 3 4 5 6 7 Sawyer, P., Sommerville, I. and Viller, S. (1996). PREview: Tackling the Real Concerns of Requirements Engineering. Cooperative Systems Engineering Group, Technical Reports 1996
  2. ↑ Sommerville, and I., Sawyer P. (1997). Viewpoints: principles, problems and a practical approach to requirements engineering, Annals of Software Engineering 3 pp.101-130.
  3. ↑ Farooqui, K., Logrippo, L., and de Meer, J. (1995). The ISO Reference Model for Open Distributed Processing: an Introduction. Computer Networks and ISDN Systems, 27(8), pp. 1215-1229.
  4. ↑ Mullery, G. (1979). CORE - A Method for Controlled Requirements Specification. In Proc. 4th Int. Conf. on Software Engineering, Munich. 126—35
  5. ↑ Easterbrook, S. and Nuseibeh, B. (1996). Using ViewPoints for inconsistency management. BCS/IEE Software Eng. J., 11(1): 31-43
  6. ↑ Nuseibeh, B., Kramer, J. and Finkelstein, A. (1994). A Framework for Expressing the Relationships between Multiple Views in Requirements Specifications. IEEE Trans. on Software Eng., 20(10): 760-73
  7. ↑ Greenspan, S. and Feblowitz, M. (1993). Requirements Engineering Using the SOS Paradigm. In Proc. RE’93, San Diego, CA. 260-65
  8. ↑ Sommerville, I., Sawyer, P., & Viller, S. (1998). Viewpoints for Requirements Elicitation: A Practical Approach. Third International Conference on Requirements Engineering (ICRE'98), p. 0074
This article is issued from Wikipedia - version of the Saturday, March 19, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.