The basis for successful RE is a common understanding of the terms used. The CPRE Glossary covers the core terms of Requirements Engineering—it is the central reference work across all CPRE modules and levels!
The glossaries are also available in various languages for download.
The CPRE Glossary: An overview of the most important Requirements Engineering terms
Please note that the definitions of terms in the glossaries are deliberately in English only in order to exclude any ambiguities or scope for interpretation that may result from translations.
The capability of a ↑system to achieve an acceptable level of probability that the system, under defined conditions, will not reach a state in which human life, health, property, or the environment is endangered.
Safety ↑requirements may be stated as ↑quality requirements or in terms of ↑functional requirements.
1. In general:
A description of a potential sequence of events that lead to a desired (or unwanted) result.
2. In RE:
An ordered sequence of interactions between partners, in particular between a ↑system and external ↑actors . May be a concrete sequence (instance scenario) or a set of potential sequences (type scenario, ↑use case ).
The range of things that can be shaped and designed when developing a ↑system .
The degree to which a ↑system protects its data and resources against unauthorized access or use and secures unobstructed access and use for its legitimate ↑users.
Security requirements may be stated as ↑quality requirements or in terms of ↑functional requirements.
The meaning of a sign or a set of signs in a ↑language .
Something which is formal to some extent, but not completely.
A ↑work product is called semi-formal if it contains formal parts, but isn’t formalized totally. Typically, a semi-formal work product has a defined ↑syntax , while the ↑semantics is partially defined only.
The provision of some ↑functionality to a human or a ↑system by a provider (a system, organization, group or individual) that delivers value to the receiver.
A ↑requirements specification pertaining to a software ↑system .
Abbreviation: SRS
1. As a work product:
A systematically represented description of the properties of an ↑item (a ↑system , a device, etc.) that satisfies given criteria.
2. As a process:
The process of specifying ( ↑eliciting , documenting and ↑validating ) the properties of an ↑item .
A specification may be about required properties ( ↑requirements specification ) or implemented properties (e.g., a technical product specification).
A ↑technique that specifies test cases and ↑requirements for a ↑system by providing examples of how the system should behave.
An artificial ↑language that has been created for expressing ↑specifications .
In agile development: A task aimed at gaining insight or gathering information, rather than at producing a ↑product ↑increment .
An ↑iteration in ↑agile development, particularly when using ↑Scrum.
A set of ↑product backlog items that have been selected to be implemented in the current ↑sprint .
A person or organization who influences a ↑system’s ↑requirements or who is impacted by that system.
Influence can also be indirect. For example, some stakeholders may have to follow instructions issued by their managers or organizations.
A ↑requirement expressing a ↑stakeholder desire or need.
Stakeholder requirements are typically written by stakeholders and express their desires and needs from their perspective.
A formal, possibly mandatory set of regulations for how to interpret, develop, manufacture or execute something.
In RE, there are RE-relevant standards issued by ISO/IEC and IEEE.
A diagrammatic representation of a ↑state machine .
A ↑state machine having states that are hierarchically and/or orthogonally decomposed.
A committee that supervises a project.
A short narrative describing a piece of required ↑functionality or ↑quality .
1. Stories may describe
- funtionality or quality from a user’s perspective ( ↑user story ),
- required infrastructure functionality or quality,
- work items that enable required ↑features or properties of a ↑system .
2. In agile development, stories are frequently considered to be atomic ↑backlog items , that is, items which are not further decomposed in the ↑backlog .
A two-dimensional arrangement of ↑stories or other ↑backlog items .
A story map helps understand the ↑functionality of a ↑system , identify gaps and plan releases.
A series of sketches or pictures that visualize the execution of a ↑scenario .
An approach for specifying the ↑functionality of a system based on a hierarchy of ↑data flow diagrams. Data flows as well as persistent data are defined in a data dictionary. A ↑context diagram models the sources of incoming and the destinations of outgoing ↑data flows.
A word having the same meaning as another word.
The rules for constructing structured signs in a ↑language .
1. In general:
A principle for ordering and structuring.
2. In engineering:
A coherent, delimitable set of elements that – by coordinated action – achieve some purpose.
1. A system may comprise other systems or ↑components as sub-systems.
2. The purposes achieved by a system may be delivered by
- deploying the system at the place(s) where it is used,
- selling/providing the system as a ↑product to its ↑users ,
- having providers who offer the system’s capabilities as ↑services to users.
3. Systems containing both software and physical ↑components are called cyber-physical systems.
4. Systems spanning software, hardware, people and organizational aspects are called socio-technical systems.
Important: In this glossary, system is used as an umbrella term which includes
- ↑products provided to customers,
- ↑services made available to customers,
- other ↑work products such as devices, procedures or tools that help people or organizations achieve some ↑goal ,
- system ↑components or ↑compositions of systems.
1. The system boundary delimits the system as it shall be after its implementation and deployment.
2. At the system boundary, the external interfaces between a ↑system and its ↑context have to be defined.
3. The system boundary frequently coincides with the ↑scope of a ↑system (which denotes the range of things that can be shaped and designed). However, this is not always the case: there may be components within the system boundary that have to be re-used as they are (i.e., cannot be shaped nor designed), while in the system context there may be things that can be re-designed when the system is developed (which means that they are in scope).
The part of a ↑system’s environment that is relevant for the definition as well as the understanding of the ↑requirements of a ↑system to be developed.
A ↑requirement pertaining to a ↑system .
A ↑requirements specification pertaining to a ↑system .
A system requirements specification is frequently considered to be a synonym for ↑requirements specification.
Abbreviation: SyRS