Ein gemeinsames Verständnis der verwendeten Begriffe ist die Grundlage für erfolgreiches RE. Das CPRE Glossar umfasst die Kernbegriffe des Requirements Engineering - es ist das zentrale Nachschlagewerk über alle CPRE Module und Ebenen hinweg! Das RE@Agile Glossar ergänzt das CPRE Glossar durch Begriffe für das Requirements Engineering im agilen Umfeld.
Die Glossare sind in verschiedenen Sprachen auch zum Download verfügbar.
Das CPRE Glossar: Die wichtigsten Begriffe des Requirements Engineering im Überblick
Bitte beachten Sie, dass die Begriffsdefinitionen in den Glossaren bewusst nur auf Englisch existieren, um Unschärfen oder Interpretationsspielraum, die aus Übersetzungen resultieren können, auszuschließen.
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.
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.
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 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 .