is a requirement
In engineering, a requirement is a singular documented physical and functional need that a particular product or service must be or perform. It is most commonly used in a formal sense in systems engineering, software engineering, or enterprise engineering...
Methodology is generally a guideline for solving a problem, with specificcomponents such as phases, tasks, methods, techniques and tools . It can be defined also as follows:...
which focuses on the early stage of Requirements Engineering
Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users...
: discovering and documenting requirements. PREview uses a Viewpoint-Oriented Approach to enable the conversion of top-level goals (“concerns”) into requirements and constraints. “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
A system requirements specification A structured collection of information that embodies the requirements of a system....
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
Distributed computing is a field of computer science that studies distributed systems. A distributed system consists of multiple autonomous computers that communicate through a computer network. The computers interact with each other in order to achieve a common goal...
) Reference Model
A reference model in systems, enterprise, and software engineering is a model of something that embodies the basic goal or idea of something and can then be looked at as a reference for various purposes.- Overview :...
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.
Table of concepts
|| 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.
|| 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)
|| A set of questions helping the analyst to create a checklist of EXTERNAL REQUIREMENTs to be compliant with those of other VIEWPOINTS.
|| 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.
|| 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.
| 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.
|| The source explicitly identifies the source of the REQUIREMENTs associated with the requirement. SOURCEs may be individuals, roles, groups, or documents.
| 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)
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
A problem domain is the area of expertise or application that needs to be examined to solve a problem. A problem domain is simply looking at only the topics you are interested in, and excluding everything else. For example, if you were developing a system trying to measure good practice in...
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.
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
Natural language processing is a field of computer science and linguistics concerned with the interactions between computers and human languages; it began as a branch of artificial intelligence....
, 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
Quality function deployment is a “method to transform user demands into design quality, to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process.”, as...
(QFD). The table below shows an example for an on-board train protection system (GAAP), taken from . 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).
: Detection of excess speed.
: Detection of overshooting.
: The system shall detect the occurrence of excess speed.
: The system shall detect the occurrence of overshoot.
: The system shall apply emergency braking when either excess speed or overshoot is detected.
| Safe state Assurance
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:
: The GAAP software must execute within the application cycle of the existing onboard software.
: The reaction time of the GAAP software to the change of state of one bit in the variants table must be 312ms.
: 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.
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.
Compliance and mutually consistent requirements will be integrated and formatted into a requirements specification document.
This concludes the PREview process.