The process of assessing whether a ↑system satisfies all its ↑requirements.

In agile: Criteria that the implementation of a ↑user story must satisfy in order to be accepted by the ↑stakeholders.

A test that assesses whether a ↑system satisfies its ↑requirements.

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.

A ↑model of the flow of actions in some part of a ↑system .

A person in some ↑role , a ↑system or a technical device in the context of a subject under consideration that interacts with that subject.

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 ).

Those parts of the real world that are relevant for determining the ↑context of a ↑system .

In UML: A relationship between two ↑classes in a ↑UML ↑class model.

A characteristic property of an ↑entity or an ↑object .

A committee of ↑customer and ↑supplier representatives that decides on ↑change requests .

Abbreviation: CCB

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 classification of requirements according to their kind into ↑system requirements (consisting of ↑functional requirements , ↑quality requirements and ↑constraints ), project requirements, and process requirements.

The degree to which a ↑work product or ↑system can be modified without degrading its ↑quality .

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. Analysis of elicited ↑requirements in order to understand and document them.

2. Synonym for ↑Requirements Engineering.

A ↑baseline for a set of ↑requirements.

1. A situation where two or more ↑requirements cannot be satisfied together.

2. A situation where two or more ↑stakeholders disagree about certain ↑requirements.

A document consisting of a ↑requirements specification.

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 ).

A ↑model that has been created with the purpose of specifying ↑requirements.

A ↑process where ↑stakeholders are working toward reaching an agreement to resolve ↑requirements conflicts.

The source from which a ↑requirement has been derived.

A systematically represented collection of ↑requirements , typically for a ↑system , that satisfies given criteria.

A template for specifying ↑requirements.

A coherent chunk of work to be done.

A recorded, intermediate or final result generated in a work ↑process .

A stable, change-controlled ↑configuration of ↑work products.

A diagram plotting the work items that remain to accomplish on a time scale.

The degree to which a ↑system can be used by specified ↑users to achieve specified ↑goals in a specified context of use.

A person who uses the ↑functionality provided by a ↑system .

A ↑requirement expressing a ↑user need.

A sequence of data items flowing from a producer to a consumer.

A diagrammatic representation of a ↑data flow model.

Abbreviation: DFD

A model that describes the ↑functionality of a ↑system by ↑activities , data stores and ↑data flows .

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 ].

A template providing a predefined skeleton structure for a document ( ↑Requirements template ).

A range of relevant things (for some given matter); for example, an ↑application domain .

A ↑model describing phenomena in an ↑application domain .

A ↑domain property in the ↑context of a ↑system that is required to hold.

The adherence of a ↑work product to ↑standards, conventions, regulations, laws, or similar prescriptions.

A tabular representation of a complex decision, specifying which actions to perform for the possible combinations of condition values.

The degree to which an ↑item produces the intended results.

The degree to which resources are expended in relation to results achieved.

An umbrella term for requirements ↑elicitation, ↑negotiation and ↑validation.

1. In general: Anything which is perceivable or conceivable ( ↑item ).

2. In entity-relationship-modeling: an individual ↑item which has an identity and does not depend on another item ( ↑object ).

A diagrammatic representation of an ↑entity-realtionship model .

Abbreviation: ERD

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

In agile development: An abstract description of a ↑stakeholder need which is larger than what can be implemented in a single ↑iteration .

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 .

Anything which is perceivable or conceivable.

The degree to which a ↑requirement is expressed such that it cannot be understood differently by different people.

1. A human action that produces an incorrect result.

2. A discrepancy between an observed ↑behavior or result and the specified behavior or result.

The capability of a ↑system to operate as intended despite the presence of (hardware or software) ↑faults .

A distinguishing characteristic of a ↑system that provides value for ↑stakeholders .

A diagrammatic representation of a ↑feature model .

A ↑model describing the variable features of a ↑product line , including their relationships and dependencies.

A template providing a form with predefined fields to be filled-in. ( ↑Requirements template )

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 ↑requirement stating a business ↑goal , objective or need of an organization.

The parts of a ↑product line that are shared by all its members.

A collection of definitions of terms that are relevant in some ↑domain .

A certain perspective on the ↑requirements of a ↑system .

A term looking identical to another term, but having a different meaning.

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.

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.

1. In modeling: The minimum and maximum number of ↑objects in a relationship.

2. In mathematics: The number of elements in a set.

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.

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.

The boundary between the ↑context of a ↑system and those parts of the ↑application domain that are irrelevant for the ↑system and its ↑requirements.

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 ↑model describing a ↑system in its ↑context .

The degree to which the information contained in a ↑work product is provably true.

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 ↑requirement describing a performance characteristic (timing, speed, volume, capacity, throughput, ...).

A committee that supervises a project.

A person or organization who delivers a ↑product or ↑service to a ↑customer .

The contrary of ↑unambiguity

The degree to which a ↑requirement for a ↑system can be implemented under existing ↑constraints .

The systematic application of a ↑technique (or a set of techniques) to achieve an objective or create a work product.

1. The systematic study of ↑methods in a particular field, in particular, how to select, apply or evaluate methods systematically in a given situation.

2. A set of ↑methods being applied in some combination.

A medium-fidelity ↑prototype that demonstrates characteristics of a user interface without implementing any real ↑functionality .

An abstract representation of an existing part of reality or a part of reality to be created.

A ↑language for expressing ↑models of a certain kind. May be textual, graphic, symbolic or some combination thereof.

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.

The degree to which an individual ↑requirement is a necessary part of the ↑requirements specification of a ↑system .

A ↑quality requirement or a ↑constraint .

A formal, possibly mandatory set of regulations for how to interpret, develop, manufacture or execute something.

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 diagrammatic representation of an ↑object model .

A ↑model describing a set of ↑objects and relationships between them.

A fictitious character representing a group of ↑users with similar needs, values and habits who are expected to use a ↑system in a similar way.

The ease with which a ↑system can be transferred to another platform while preserving its characteristics.

A proven way of how to carry out certain types of ↑tasks or ↑activities.

The process of assigning priorities to a set of ↑items.

The level of importance assigned to an ↑item , e.g., a ↑requirement or a ↑defect , according to certain criteria.

A difficulty, open question or undesirable condition that needs investigation, consideration, or solution.

A set of interrelated ↑activities performed in a given order to process information or materials.

A ↑model describing a ↑process or a set of related processes.

An abstract, reusable ↑model of a ↑process which can be used to configure and instantiate a concrete process for a given situation and ↑context .

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 .

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.

A person responsible for a ↑product in terms of ↑functionality , value and ↑risk .

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.

A ↑process that involves the creation and evaluation of ↑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.

A ↑requirement that pertains to a quality concern that is not covered by ↑functional requirements.

A ↑requirement that limits the solution space beyond what is necessary for meeting the given ↑functional requirements and ↑quality requirements.

Multiple occurrence of the same information or resource.

The improvement of the internal ↑quality of source code, particularly the structure of the code, without changing its observable behavior.

A ↑configuration that has been released for installation and use by ↑customers.

A person who – in collaboration with ↑stakeholders – elicits, documents, validates, and manages ↑requirements.

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

An evaluation of a ↑work product by an individual or a group in order to find problems or suggest improvements.

A possible event that threatens the success of an endeavor.

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 order in which a set of actions is executed.

A structured set of signs for expressing and communicating information.

A template for the syntactic structure of a phrase that expresses an individual ↑requirement or a ↑user story in ↑natural language. ( ↑requirements template )

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.

1. In general: A description of a potential sequence of events that lead to a desired (or unwanted) result.

2. 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 popular ↑process framework for ↑agile development of 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.

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.

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 ↑technique that specifies test cases and ↑requirements for a ↑system by providing examples of how the system should behave.

An artificial ↑language that has been created for expressing ↑specifications .

In agile development: A task aimed at gaining insight or gathering information, rather than at producing a ↑product ↑increment .

An ↑iteration in ↑agile development, particularly when using ↑Scrum.

A set of ↑product backlog items that have been selected to be implemented in the current ↑sprint .

A person or organization who influences a ↑system’s ↑requirements or who is impacted by that system.

A ↑requirement expressing a ↑stakeholder desire or need.

A ↑state machine having states that are hierarchically and/or orthogonally decomposed.

A two-dimensional arrangement of ↑user stories .

A series of sketches or pictures that visualize the execution of a ↑scenario .

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.

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.

The boundary between a ↑system and its surrounding ↑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.

A ↑requirement pertaining to a ↑system .

A ↑requirements specification pertaining to a ↑system .

An excerpt from a ↑work product , containing only those parts one is currently interested in.

Something which is formal to some extent, but not completely.

A documented set of coherent actions for accomplishing a ↑task or achieving an objective.

In agile development: A collection of related ↑user stories .

The range of things that can be shaped and designed when developing a ↑system .

Abbreviation for Unified Modeling Language, a standardized language for modeling problems or solutions.

A set of possible interactions between external ↑actors and a ↑system that provide a benefit for the actor(s) involved.

A diagram type in UML that models the ↑actors and the ↑use cases of a ↑system .

A ↑model consisting of a set of ↑use cases , typically together with a ↑use case diagram.

A description of a need from a ↑user’s perspective together with the expected benefit when this need is satisfied.

The degree to which the fulfillment of a ↑requirement by an implemented ↑system can be verified.

The way in which a ↑system reacts to stimuli, changes its state and produces observable results.

A ↑model describing the ↑behavior of a ↑system , e.g., by a ↑state machine.

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.

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).

The degree to which an ↑item is comprehensible to its intended users.

The ↑process of confirming that an ↑item (a ↑system , a ↑work product or a part thereof) matches its ↑stakeholders’ needs.

1. The degree to which a ↑system can be changed or customized.

2. In product lines: The ↑features that can differ among the members of the ↑product line .

One of the possible forms that an ↑item (e.g., a ↑requirement ) may have.

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 .

The process of confirming that an ↑item (a system, a work product, or a part thereof) fulfills its ↑specification .

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.

A conceptual imagination of a future ↑system or ↑product , describing its key characteristics and how it will create value for its ↑users .

The ease with which a ↑system can be modified by the intended maintainers.

A (software) ↑system that helps develop, operate and maintain ↑systems.

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.

A line of ↑configurations or ↑work product ↑versions that forks away from the main line (or from another branch) at some point in time.

A desired state of affairs (that a ↑stakeholder wants to achieve).

A ↑model representing a set ↑goals, sub-goals and the relationships between them.

The degree to which a ↑system performs specified functions under specified conditions for a specified period of time.

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.

A diagrammatic representation of a ↑state machine .

A fixed, non-extendable amount of time for completing a set of ↑tasks .