PREview

From Wikipedia, the free encyclopedia

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].”

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.

Contents

[edit] Reasons to use PREview

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.

[edit] 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.

[edit] Process diagram

Figure 1: PREview Process Diagram
Figure 1: PREview 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.

[edit] 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)

[edit] Process-data diagram

Figure 1: PREview Process-Data Diagram
Figure 1: PREview Process-Data Diagram

[edit] The PREview process

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

[edit] Requirements discovery

The requirements discovery phase consists of several sub-activities.

[edit] 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.

[edit] 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.

[edit] 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” [8]. Viewpoints fall into one of these classes:

  • Interactors (Human operators and modules of the system)
  • Stakeholders
  • 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).

[edit] Discover requirements

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

[edit] 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.

[edit] 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.

[edit] Requirements definition

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

This concludes the PREview process.

[edit] References

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

[edit] See also