Die Requirements Engineering Terminologie in verschiedenen Sprachen
Das CPRE Glossar umfasst die Kernbegriffe des Requirements Engineerings. Die Definitionen der Begriffe sind generell auf Englisch angegeben und nicht übersetzt. Dadurch werden Unschärfen oder Interpretationsspielräume, die sich aus Übersetzungen ergeben können, vermieden. Zudem sind die Begriffe des CPRE Glossars mit der Terminologie des ISTQB harmonisiert.
Das Online-Glossar entspricht der zum Download bereitliegenden Version und ist die zentrale Referenz für den CPRE Foundation Level und alle CPRE Advanced Level Module. Für den Advanced Level RE@Agile ist ein ergänzendes Glossar, das die Begriffe für das Requirements Engineering im agilen Umfeld definiert, zum Download verfügbar.
The degree to which a ↑requirement expresses the ↑stakeholders' true and agreed desires and needs (i.e., those they had actually in mind when stating the requirement).
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.
Änderungsmanagement
Change management
A controlled way to effect or deny a requested change of a ↑work product.
Agil
Agile
Synonym:
Agilität
In general:
(a) Able to move quickly and easily.
(b) Quick, smart, and clever.
In software development: A development approach which builds a product ↑incrementally by dividing work into ↑iterations of fixed duration ( ↑timeboxes ).
Note:
Agile development is characterized by focusing on delivering a working product in each iteration, collaboration with ↑stakeholders with frequent feedback and adaptation of plans after each iteration based on feedback and changed ↑requirements.
Akteur
Actor
A person in some ↑role , a ↑system or a technical device in the context of a subject under consideration that interacts with that subject.
Note:
In RE, the subject under consideration typically is a ↑system . In testing, it may be a test ↑object .
Aktivität
Activity
An action or a set of actions that a person or group performs to accomplish a ↑task .
Aktivitätsdiagramm
Activity diagram
A diagram type in ↑UML which models the flow of actions in some part of a ↑system including ↑data flows and areas of responsibility where necessary.
Aktivitätsmodell
Activity model
A ↑model of the flow of actions in some part of a ↑system .
The process of seeking, capturing and consolidating ↑requirements from available ↑sources, potentially including the re-construction or creation of requirements.
The process of managing existing ↑requirements and requirements-related ↑work products, including the storing, changing and tracing of requirements ( ↑traceability ).
User requirements are typically about what a system should do for certain users and how they can interact with the system. User requirements are a subset of ↑stakeholder requirements .
Incoming data flows trigger activities which then consume the received data, transform them, read/write persistent data held in data stores and then produce new data flows which may be intermediate results that trigger other activities or final results that leave the system.
Defekt
Defect
Synonym:
Bug
An imperfection or deficiency in a ↑work product that impairs its intended use.
A plan or drawing produced to show how something will look, function or be structured before it is made.
The activity of creating a design.
A decorative pattern [This meaning does not apply in the software engineering ↑domain ].
Note:
In software product development, we distinguish between creative design which shapes the look and feel of the product, i.e., its perceivable form, function and quality, and technical design (also called software design) which determines the inner structure of the product, in particular the software architecture.
The creative design of products is also called product design.
The creative design of digital solutions is called digital design.
Dokumentvorlage
Document template
A template providing a predefined skeleton structure for a document ( ↑Requirements template ).
A ↑model of data that are relevant for a ↑system or of the data of an ↑application domain , consisting of a set of entity types that are each characterized by ↑attributes and linked by relationships.
Abbreviation: ER Model
Entscheidungstabelle
Decision table
A tabular representation of a complex decision, specifying which actions to perform for the possible combinations of condition values.
Epic
Epic
Synonym:
Erzählung
In agile development: An abstract description of a ↑stakeholder need which is larger than what can be implemented in a single ↑iteration .
A distinguishing characteristic of a ↑system that provides value for ↑stakeholders .
Note:
A feature typically comprises several ↑requirements and is used for communicating with ↑stakeholders on a higher level of abstraction and for expressing variable or optional characteristics.
A ↑model describing the variable features of a ↑product line , including their relationships and dependencies.
Fehler
Error
A human action that produces an incorrect result.
A discrepancy between an observed ↑behavior or result and the specified behavior or result.
Note:
In practice, both meanings are used. Where needed, the meaning of error can be disambiguated by using human error and observed error or observed fault, respectively.
Fehlertoleranz
Fault tolerance
The capability of a ↑system to operate as intended despite the presence of (hardware or software) ↑faults .
The parts of a ↑product line that are shared by all its members.
Geschäftsanforderung
Business requirement
A ↑requirement stating a business ↑goal , objective or need of an organization.
Note:
Business requirements typically state those business goals, objectives and needs that shall be achieved by employing a ↑system or a collection of systems.
Typical viewpoints are perspectives that a ↑stakeholder or stakeholder group has (for example, an end user’s perspective or an operator’s perspective). However, there can also be topical viewpoints such as a security viewpoint.
Glossar
Glossary
A collection of definitions of terms that are relevant in some ↑domain .
Note:
Frequently, a glossary also contains cross-references, ↑synonyms , ↑homonyms , acronyms, and abbreviations.
H
Homonym
Homonym
A term looking identical to another term, but having a different meaning.
Note:
For example, bill as a bank note and bill as a list (of materials) are homonyms.
I
Inkrement (in der Softwareentwicklung)
Increment (in software development)
An addition to a ↑system under development that extends, enhances or refactors ( ↑refactoring ) the existing parts of the ↑system .
A formal ↑review of a ↑work product by a group of experts according to given criteria, following a defined procedure.
Iteration
Iteration
In general: The repetition of something, for example, a procedure, a process or a piece of program code.
In agile development: A ↑timeboxed unit of work in which a development team implements an ↑increment to the ↑system under development.
Note:
In agile development, iteration and ↑sprint are frequently used as synonyms.
K
Kardinalität
Cardinality
In modeling: The minimum and maximum number of ↑objects in a relationship.
In mathematics: The number of elements in a set.
Note:
In ↑UML , the term multiplicity is used for cardinality.
Klasse
Class
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.
In software architecture: An encapsulated set of coherent ↑objects or ↑classes that jointly achieve some purpose.
In testing: A part of a ↑system that can be tested in isolation.
Note:
When viewed in isolation, a component is a ↑system by itself.
Komposition (in einem technischen Kontext)
Composition (in a technical context)
An ↑item that is composed of a set of items; forming a whole-part relationship.
The act of composing a whole from a set of parts.
Konfiguration
Configuration
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 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.
The degree to which the information contained in a ↑work product is provably true.
Note:
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 coarse description of the required capabilities of a ↑system from the ↑customer’s perspective.
Note:
A customer requirements specification is usually supplied by the customer.
Leistungsanforderung
Performance requirement
A ↑requirement describing a performance characteristic (timing, speed, volume, capacity, throughput, ...).
Note:
In this glossary, performance requirements are regarded as a sub-category of ↑quality requirements. However, they can also be considered as a ↑kind of requirements of its own.
A high-fidelity ↑prototype that implements critical parts of a ↑system to an extent that ↑stakeholders can use the prototype to see whether the prototyped part of the system will work and behave as expected.
Natürliche Sprache
Natural language
A ↑language that people use for speaking and writing in everyday life.
Note:
This is in contrast to artificial languages that people have deliberately created for specific purposes such as programming or specifying.
↑Performance requirements may be regarded as another category of non-functional requirements. In this glossary, performance requirements are considered to be a sub-category of ↑quality requirements .
Norm
Standard
A formal, possibly mandatory set of regulations for how to interpret, develop, manufacture or execute something.
Note:
In RE, there are RE-relevant standards issued by ISO/IEC and IEEE.
In general: Anything which is perceivable or conceivable ( ↑item ).
In software engineering: an individual ↑item which has an identity, is characterized by the values of its ↑attributes and does not depend on another item ( ↑entity ).
The product owner maintains and prioritizes the ↑product backlog , makes sure that the ↑stakeholders’↑requirements as well as market needs are elicited and adequately documented in the ↑product backlog and represents the stakeholders when communicating with the development team.
A jointly managed set of systems (provided as products or services) that share a common core and have a configurable set of ↑variants for satisfying needs of particular customers or market segments.
Note:
The points in a product line where there is more than one ↑variant to select from are called ↑variation points.
Prototyp
Prototype
In manufacturing: A piece which is built prior to the start of mass production.
In software and systems engineering: A preliminary, partial realization of certain characteristics of a ↑system .
In design: A preliminary, partial instance of a design solution.
A set of interrelated ↑activities performed in a given order to process information or materials.
Note:
The notion of process includes business processes (e.g., how to commission and send ordered goods to ↑customers ), information processes (e.g., how to deliver records from a database that match a given query), and technical processes (e.g., cruise control in a car).
Prozessmodell
Process model
A ↑model describing a ↑process or a set of related processes.
Prozessmuster
Process pattern
An abstract, reusable ↑model of a ↑process which can be used to configure and instantiate a concrete process for a given situation and ↑context .
Q
Qualität
Quality
In general: The degree to which a set of inherent characteristics of an item fulfills ↑requirements.
In systems and software engineering: The degree to which a ↑system satisfies stated and implied needs of its ↑stakeholders.
Note:
Quality in this definition means fitness for intended use, as stated in the ↑requirements. This is in contrast to the colloquial notion of quality which is typically connoted with goodness or excellence.
A person who – in collaboration with ↑stakeholders – elicits, documents, validates, and manages ↑requirements.
Note:
In most cases, requirements engineer is a ↑role and not a job title.
Requirements Engineering
Requirements Engineering
The systematic and disciplined approach to the ↑specification and management of ↑requirements with the goal of understanding the ↑stakeholders’ desires and needs and minimizing the risk of delivering a ↑system that does not meet these desires and needs.
Abbreviation: RE
Review
Review
Synonym:
Durchsicht
An evaluation of a ↑work product by an individual or a group in order to find problems or suggest improvements.
Note:
Evaluation may be performed with respect to both contents and conformance.
Risiko
Risk
A possible event that threatens the success of an endeavor.
Note:
A risk is typically assessed in terms of its probability and potential damage.
The meaning of a sign or a set of signs in a ↑language .
Sequenzdiagramm
Sequence diagram
A diagram type in ↑UML which models the interactions between a selected set of ↑objects and/or ↑actors in the sequential order in which those interactions occur.
Service
Service
Synonym:
Dienst
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.
Note:
In systems engineering, software engineering and Requirements Engineering, services are typically provided by a ↑system for a ↑user or another system.
Sicherheit (im Sinn von Nutzungssicherheit)
Safety
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.
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.
A story map helps understand the ↑functionality of a ↑system , identify gaps and plan releases.
Storyboard
Storyboard
A series of sketches or pictures that visualize the execution of a ↑scenario .
Strukturierte Analyse
Structured Analysis
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.
Synonym
Synonym
A word having the same meaning as another word.
Syntax
Syntax
The rules for constructing structured signs in a ↑language .
System
System
In general: A principle for ordering and structuring.
In engineering: A coherent, delimitable set of elements that – by coordinated action – achieve some purpose.
Note:
A system may comprise other systems or ↑components as sub-systems.
The purposes achieved by a system may be delivered by
deploying the system at the place(s) where it is used,
The boundary between a ↑system and its surrounding ↑context .
Note:
The system boundary delimits the system as it shall be after its implementation and deployment.
At the system boundary, the external interfaces between a ↑system and its ↑context have to be defined.
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).
Systemkontext
System context
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.
Szenario
Scenario
In general: A description of a potential sequence of events that lead to a desired (or unwanted) result.
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 ).
T
Technik
Technique
A documented set of coherent actions for accomplishing a ↑task or achieving an objective.
Teilformal
Semi-formal
Something which is formal to some extent, but not completely.
Note:
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.
Thematische Sammlung
Theme
In agile development: A collection of related ↑user stories .
U
Überprüfbarkeit (von Anforderungen)
Verifiability (of requirements)
The degree to which the fulfillment of a ↑requirement by an implemented ↑system can be verified.
The range of things that can be shaped and designed when developing a ↑system .
UML
UML
Abbreviation for Unified Modeling Language, a standardized language for modeling problems or solutions.
Use Case
Use case
A set of possible interactions between external ↑actors and a ↑system that provide a benefit for the actor(s) involved.
Note:
Use cases specify a system from a user’s (or other external actor’s) perspective: every use case describes some ↑functionality that the system must provide for the actors involved in the use case.
In RE, validation is the process of confirming that the documented ↑requirements match their ↑stakeholders’ needs; in other words: whether the right requirements have been specified.
Variabilität
Variability
The degree to which a ↑system can be changed or customized.
In product lines: The ↑features that can differ among the members of the ↑product line .
Variante
Variant
One of the possible forms that an ↑item (e.g., a ↑requirement ) may have.
Variationspunkt
Variation point
A point in a ↑product line where an element of the product line (typically a variable or a ↑feature ) can be chosen from a set of ↑variants .
Verfolgbarkeit
Traceability
In general: The ability to establish explicit relationships between related ↑work products or ↑items within work products.
In RE: The ability to trace a ↑requirement
(a) back to its origins,
(b) forward to its implementation in design and code and its associated tests,
(c) to requirements it depends on (and vice-versa).
Verhalten
Behavior
The way in which a ↑system reacts to stimuli, changes its state and produces observable results.
Note:
Stimuli may be events or changes of conditions. Their origin may be external or system-internal.
The process of confirming that an ↑item (a system, a work product, or a part thereof) fulfills its ↑specification .
Note:
Requirements verification is the process of confirming that the ↑requirements have been documented properly and satisfy the ↑quality criteria for requirements; in other words, whether the requirements have been specified right.
Version
Version
An occurrence of an ↑item which exists in multiple, time-ordered occurrences where each occurrence has been created by modifying one of its previous occurrences.
Verstehbarkeit
Understandability
The degree to which an ↑item is comprehensible to its intended users.
A conceptual imagination of a future ↑system or ↑product , describing its key characteristics and how it will create value for its ↑users .
Vollständigkeit (von Anforderungen)
Completeness (of requirements)
For a single ↑requirement : The degree to which the specification of a requirement is self-contained.
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.
W
Walkthrough
Walkthrough
A ↑review in which the author of a ↑work product leads the reviewers systematically through the work product and the reviewers ask questions and make comments about possible issues.
Wartbarkeit
Maintainability
Synonym:
Pflegbarkeit
The ease with which a ↑system can be modified by the intended maintainers.
Synonym:
Drahtmodell (Im RE-Kontext sinngemäß oft besser: Papier-und-Bleistift Modell)
A low-fidelity ↑prototype built with simple materials that primarily serves for discussing and validating requirements, design ideas or user interface concepts.
Note:
When prototyping digital systems, wireframes are typically built with paper. Such prototypes are also called paper prototypes.
Z
Zeitrahmen (mit fester Länge)
Timebox
Synonym:
Timebox
A fixed, non-extendable amount of time for completing a set of ↑tasks .
Ziel
Goal
A desired state of affairs (that a ↑stakeholder wants to achieve).
Note:
Goals describe intentions of stakeholders. They may conflict with one another.
Zielmodell
Goal model
A ↑model representing a set ↑goals, sub-goals and the relationships between them.
Note:
Goal models may also include tasks and resources needed to achieve a goal, actors who want to achieve a goal, and obstacles that impede the achievement of a goal.
A ↑model describing the behavior of a ↑system by a finite set of states and state transitions. State transitions are triggered by events and can in turn trigger actions and new events.
Zuverlässigkeit
Reliability
The degree to which a ↑system performs specified functions under specified conditions for a specified period of time.
A branch is created by making a copy of some configuration or work product version and making this copy the root of the branch. A branch may be merged with the main line or with another branch at some later point in time.
Downloads
Das CPRE Glossar kann auch als PDF Dokument heruntergeladen werden und ist in den folgenden Sprachen verfügbar:
• Chinesisch (Mandarin)
• Deutsch
• Englisch
• Französisch
• Italienisch
• Niederländisch
• Persisch
• Polnisch
• Portugiesisch (Brasilien)
• Russisch
• Schwedisch
• Spanisch
