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.
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.
A person in some ↑role , a ↑system or a technical device in the context of a subject under consideration that interacts with that subject.
In RE, the subject under consideration typically is a ↑system . In testing, it may be a test ↑object .
An action or a set of actions that a person or group performs to accomplish a ↑task .
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.
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.
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 ].
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.
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.
A collection of definitions of terms that are relevant in some ↑domain .
Frequently, a glossary also contains cross-references, ↑synonyms , ↑homonyms , acronyms, and abbreviations.
A term looking identical to another term, but having a different meaning.
For example, bill as a bank note and bill as a list (of materials) are homonyms.
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 .
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.
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.
A ↑language that people use for speaking and writing in everyday life.
This is in contrast to artificial languages that people have deliberately created for specific purposes such as programming or specifying.
A set of interrelated ↑activities performed in a given order to process information or materials.
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).
An abstract, reusable ↑model of a ↑process which can be used to configure and instantiate a concrete process for a given situation and ↑context .
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.
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.
In most cases, requirements engineer is a ↑role and not a job title.
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.
An evaluation of a ↑work product by an individual or a group in order to find problems or suggest improvements.
Evaluation may be performed with respect to both contents and conformance.
A possible event that threatens the success of an endeavor.
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 .
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.
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.
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)
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 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).
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.
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 ).
A documented set of coherent actions for accomplishing a ↑task or achieving an objective.
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 process of confirming that an ↑item (a system, a work product, or a part thereof) fulfills its ↑specification .
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.
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.
The degree to which an ↑item is comprehensible to its intended users.
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.
Das CPRE Glossar kann auch als PDF Dokument heruntergeladen werden und ist in den folgenden Sprachen verfügbar:
• Chinesisch (Mandarin)
• Portugiesisch (Brasilien)