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 RE@Agile Glossary supplements the CPRE Glossary with terms for Requirements Engineering in an agile environment.
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.
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 .
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).
An ↑iteration in ↑agile development, particularly when using ↑Scrum.
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 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 all definitions referring to system in this glossary, system is 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