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.
In agile: Criteria that the implementation of a ↑user story must satisfy in order to be accepted by the ↑stakeholders.
Acceptance criteria may also be written for ↑backlog items other than user stories.
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.
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).
1. In general:
(a) Able to move quickly and easily.
(b) Quick, smart, and clever.
2. In software development: A development approach which builds a product ↑incrementally by dividing work into ↑iterations of fixed duration ( ↑timeboxes ).
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 stable, change-controlled ↑configuration of ↑work products.
Baselines serve for ↑release planning and release definition as well as for project management purposes such as effort estimation.
The way in which a ↑system reacts to stimuli, changes its state and produces observable results.
Stimuli may be events or changes of conditions. Their origin may be external or system-internal.
A ↑model describing the ↑behavior of a ↑system , e.g., by a ↑state machine.
A ↑requirement stating a business ↑goal , objective or need of an organization.
Business requirements typically state those business goals, objectives and needs that shall be achieved by employing a ↑system or a collection of systems.
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.
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.
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.
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.
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.
Synonym: bug, fault
An imperfection or deficiency in a ↑work product that impairs its intended use.
1. A plan or drawing produced to show how something will look, function or be structured before it is made.
2. The activity of creating a design.
3. A decorative pattern [This meaning does not apply in the software engineering ↑domain ].
1. 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.
2. The creative design of products is also called product design.
3. The creative design of digital solutions is called digital design.
A range of relevant things (for some given matter); for example, an ↑application domain .
A ↑model describing phenomena in an ↑application domain .
1. In RE, domain models are created with the intention to understand the ↑application domain in which a planned ↑system will be situated.
2. Static domain models specify (business) objects and their relationships in a ↑domain of interest.
3. Domain story models specify visual stories about how actors interact with devices, artifacts and other items in a ↑domain .
The degree to which resources are expended in relation to results achieved.
An umbrella term for requirements ↑elicitation, ↑negotiation and ↑validation.
1. A human action that produces an incorrect result.
2. A discrepancy between an observed ↑behavior or result and the specified behavior or result.
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.
A pilot system forming the core of a ↑system to be developed.
A throwaway ↑prototype used to create shared understanding, clarify ↑requirements or validate ↑requirements .
The capability of a ↑system to operate as intended despite the presence of (hardware or software) ↑faults .
Fault tolerance may be stated as a ↑quality requirement .
A distinguishing characteristic of a ↑system that provides value for ↑stakeholders .
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 ↑requirement concerning a result or ↑behavior that shall be provided by a function of a ↑system .
The capabilities of a ↑system as stated by its ↑functional requirements .
A desired state of affairs (that a ↑stakeholder wants to achieve).
Goals describe intentions of stakeholders. They may conflict with one another.
An addition to a ↑system under development that extends, enhances or refactors ( ↑refactoring ) the existing parts of the ↑system .
In ↑agile development, every ↑iteration produces an increment.
A formal ↑review of a ↑work product by a group of experts according to given criteria, following a defined procedure.
1. In general: The repetition of something, for example, a procedure, a process or a piece of program code.
2. In agile development: A ↑timeboxed unit of work in which a development team implements an ↑increment to the ↑system under development.
In agile development, iteration and ↑sprint are frequently used as synonyms.
A classification of requirements according to their kind into ↑system requirements (consisting of ↑functional requirements , ↑quality requirements and ↑constraints ), project requirements, and process requirements.
1. RE is primarily concerned with system requirements.
2. Quality requirements and constraints are also called ↑non-functional requirements .
A medium-fidelity ↑prototype that demonstrates characteristics of a user interface without implementing any real ↑functionality .
In RE, a mock-up primarily serves for specifying and validating user interfaces.
An abstract representation of an existing part of reality or a part of reality to be created.
1. The notion of reality includes any conceivable set of elements, phenomena or concepts, including other models.
2. Models are always built for specific purposes in a specific context.
3. With respect to a model, the modeled part of reality is called the original.
4. In RE, ↑requirements can be specified with models.
The degree to which a ↑work product or ↑system can be modified without degrading its ↑quality .
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.
The degree to which an individual ↑requirement is a necessary part of the ↑requirements specification of a ↑system .
A ↑quality requirement or a ↑constraint .
↑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 .
1. In general: Anything which is perceivable or conceivable ( ↑item ).
2. 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 ).
A ↑requirement describing a performance characteristic (timing, speed, volume, capacity, throughput, ...).
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.
The level of importance assigned to an ↑item , e.g., a ↑requirement or a ↑defect , according to certain criteria.
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).
A software-based ↑system or a ↑service provided by a system which is developed and marketed by a ↑supplier and used by ↑customers.
An ordered, typically prioritized collection of work items that a development team has to work on when developing or evolving a ↑system .
Items include ↑requirements , ↑defects to be fixed, or ↑refactorings to be done.
1. In manufacturing: A piece which is built prior to the start of mass production.
2. In software and systems engineering: A preliminary, partial realization of certain characteristics of a ↑system .
3. In design: A preliminary, partial instance of a design solution.
1. In RE, prototypes are used as a means for requirements ↑elicitation (see ↑specification by example ) and ↑validation .
2. Prototypes in RE can be classified
(a) with respect to their degree of fidelity into ↑native prototypes, ↑mock-ups and ↑wireframes;
(b) with respect to their purpose into ↑exploratory prototypes and ↑evolutionary prototypes.
1. In general: The degree to which a set of inherent characteristics of an item fulfills ↑requirements.
2. 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.
A ↑requirement that pertains to a quality concern that is not covered by ↑functional requirements.
A ↑configuration that has been released for installation and use by ↑customers.
The degree to which a ↑system performs specified functions under specified conditions for a specified period of time.
Reliability may be stated as a ↑quality requirement .
1. A need perceived by a ↑stakeholder .
2. A capability or property that a ↑system shall have.
3. A documented representation of a need, capability or property.
1. A situation where two or more ↑requirements cannot be satisfied together.
2. A situation where two or more ↑stakeholders disagree about certain ↑requirements.
Requirements conflicts have to be solved by ↑requirements negotiation.
A document consisting of a ↑requirements specification.
Requirements document is frequently used as a synonym for requirements specification.
Synonym: elicitation (of requirements)
The process of seeking, capturing and consolidating ↑requirements from available ↑sources, potentially including the re-construction or creation of requirements.
A person who – in collaboration with ↑stakeholders – elicits, documents, validates, and manages ↑requirements.
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.
Abbreviation: RE
The process of managing existing ↑requirements and requirements-related ↑work products, including the storing, changing and tracing of requirements ( ↑traceability ).
A ↑process where ↑stakeholders are working toward reaching an agreement to resolve ↑requirements conflicts.
The source from which a ↑requirement has been derived.
Typical sources are ↑stakeholders, documents, existing ↑systems and observations.
A systematically represented collection of ↑requirements , typically for a ↑system , that satisfies given criteria.
1. In some situations we distinguish between a ↑customer requirements specification (typically written by the customer) and a ↑system requirements specification or ↑software requirements specification (written by the supplier).
2. Requirements specification may also denote the ↑process of specifying ( ↑eliciting , documenting and ↑validating ) requirements.
A template for specifying ↑requirements.
In RE, several forms of templates are used. ↑Phrase templates are used for specifying individual ↑requirements or ↑user stories . ↑Form templates can be used to specify ↑use cases or ↑quality requirements. ↑Document templates provide a predefined structure for ↑requirements documents.
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.
1. A part played by a person in a given context.
2. In ↑UML ↑class models : The parts played by the linked ↑objects in an ↑association .
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
In RE, tools support ↑requirements management as well as modeling, documenting, and validating ↑requirements.
1. In general: The ability to establish explicit relationships between related ↑work products or ↑items within work products.
2. 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).
Abbreviation for Unified Modeling Language, a standardized language for modeling problems or solutions.
The degree to which a ↑requirement is expressed such that it cannot be understood differently by different people.
The degree to which an ↑item is comprehensible to its intended users.
Typical items are: a ↑system , a ↑work product , or a part thereof.
A set of possible interactions between external ↑actors and a ↑system that provide a benefit for the actor(s) involved.
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.
A diagram type in UML that models the ↑actors and the ↑use cases of a ↑system .
The boundary between the actors and the use cases constitutes the ↑system boundary.
A person who uses the ↑functionality provided by a ↑system .
Users (also called end users) always are ↑stakeholders of a ↑system .
A ↑requirement expressing a ↑user need.
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 .
A description of a need from a ↑user’s perspective together with the expected benefit when this need is satisfied.
1. User stories are typically written in ↑natural language using a ↑phrase template and are accompanied by ↑acceptance criteria .
2. In ↑agile development, user stories are the main means for communicating needs between a ↑product owner and the development team.
The ↑process of confirming that an ↑item (a ↑system , a ↑work product or a part thereof) matches its ↑stakeholders’ needs.
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.
The degree to which the fulfillment of a ↑requirement by an implemented ↑system can be verified.
Such ↑verification can be performed, for example by defining ↑acceptance test cases, measurements or ↑inspection procedures.
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.
An excerpt from a ↑work product , containing only those parts one is currently interested in.
A view can abstract or aggregate parts of the work product.
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.
A low-fidelity ↑prototype built with simple materials that primarily serves for discussing and validating requirements, design ideas or user interface concepts.
When prototyping digital systems, wireframes are typically built with paper. Such prototypes are also called paper prototypes.
Synonym: artifact
A recorded, intermediate or final result generated in a work ↑process .