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.
A committee of ↑customer and ↑supplier representatives that decides on ↑change requests .
Abbreviation: CCB
The Change control board should not be confused with a change advisory board, which is a committee that evaluates change requests for a ↑system in operation and typically has no decision power.
A controlled way to effect or deny a requested change of a ↑work product.
In RE: A well-argued request for changing one or more ↑baselined ↑requirements.
A representation of a set of ↑objects of the same kind by describing the structure of the objects, the ways they can be manipulated and how they behave.
A diagrammatic representation of a ↑class model.
A model consisting of a set of ↑classes and relationships between them.
The parts of a ↑product line that are shared by all its members.
1. For a single ↑requirement : The degree to which the specification of a requirement is self-contained.
2. For a ↑work product covering multiple requirements: The degree to which the work product contains all known requirements that are relevant in the scope of this work product.
The adherence of a ↑work product to ↑standards, conventions, regulations, laws, or similar prescriptions.
1. In general: A delimitable part of a ↑system .
2. In software architecture: An encapsulated set of coherent ↑objects or ↑classes that jointly achieve some purpose.
3. In testing: A part of a ↑system that can be tested in isolation.
When viewed in isolation, a component is a ↑system by itself.
1. An ↑item that is composed of a set of items; forming a whole-part relationship.
2. The act of composing a whole from a set of parts.
A consistent set of logically coherent ↑items. The items are individually identifiable ↑work products or parts of work products in at most one ↑version per item.
The degree to which a ↑work product conforms to regulations given in some ↑standard .
The degree to which a set of ↑requirements is free of contradicting statements.
A ↑requirement that limits the solution space beyond what is necessary for meeting the given ↑functional requirements and ↑quality requirements.
1. In general: The network of thoughts and meanings needed for understanding phenomena or utterances.
2. Especially in RE: The part of a ↑system's environment being relevant for understanding the system and its ↑requirements.
Context in the second meaning is also called the ↑system context.
The boundary between the ↑context of a ↑system and those parts of the ↑application domain that are irrelevant for the ↑system and its ↑requirements.
The context boundary separates the relevant part of the environment of a system to be developed from the irrelevant part, i.e., the part that does not influence the system to be developed and, thus, does not have to be considered during Requirements Engineering.
1. A diagrammatic representation of a ↑context model.
2. In ↑Structured Analysis, the context diagram is the root of the ↑data flow diagram hierarchy.
The order in which a set of actions is executed.
The degree to which the information contained in a ↑work product is provably true.
In RE, correctness is sometimes used as a synonym for ↑adequacy , particularly when validating a ↑requirement rigorously against formally stated properties in the ↑context of a ↑system .
A person or organization who receives a ↑system , a ↑product or a ↑service .
Also see ↑stakeholder .
A coarse description of the required capabilities of a ↑system from the ↑customer’s perspective.
A customer requirements specification is usually supplied by the customer.