Glossary

A searchable reference of all key IREB CPRE-FL terms and definitions.

Acceptance Criteria

Conditions that a system must satisfy to be accepted by a stakeholder. Used to verify that a requirement has been fulfilled.

Activity Diagram

A UML diagram that models the flow of activities in a process, including decisions, parallel execution (fork/join), and swim lanes.

Actor

A person or external system that interacts with the system under development. Represented as a stick figure in use case diagrams.

Aggregation

A "has-a" relationship in class diagrams where the part can exist independently of the whole. Shown as a hollow diamond.

Ambiguity

A quality defect where a requirement can be interpreted in more than one way.

Baseline

A formally agreed-upon and frozen snapshot of requirements at a specific point in time. Changes after baselining must go through change control.

Brainstorming

A creative group elicitation technique for generating many ideas quickly, with rules: no criticism, quantity over quality, build on others' ideas.

Change Control Board (CCB)

A group authorized to evaluate, approve, or reject change requests to baselined requirements.

Change Request

A formal proposal to modify a baselined requirement. Must include impact analysis before approval.

Class Diagram

A UML diagram showing the data structure of a domain: classes (entities), their attributes, and relationships (associations, generalizations, aggregations, compositions).

Composition

A strong "has-a" relationship in class diagrams where the part cannot exist without the whole. Shown as a filled diamond.

Conflict

A situation where two or more requirements contradict each other, or stakeholders have incompatible expectations.

Constraint

A requirement that restricts the solution space. Imposed by organizational, technological, legal, or physical factors. Typically non-negotiable.

Context Boundary

The boundary separating the relevant system context from the irrelevant environment.

Context Diagram

A high-level diagram showing the system under development, its boundary, external entities (users, systems), and the interactions between them.

Document Analysis

An elicitation technique that studies existing documentation (forms, reports, manuals) to extract requirements. Also called "archaeology."

Elicitation

The RE activity of discovering, gathering, and developing requirements from stakeholders and other sources.

Entity-Relationship Diagram

A data modeling diagram showing entities, their attributes, and relationships with cardinalities. Similar purpose to class diagrams.

Extend (Use Case)

A relationship where an extending use case optionally adds behavior to a base use case under certain conditions. Arrow points from extending to base use case.

Feasibility

A quality criterion: the requirement can realistically be implemented within the given constraints (technical, budget, time).

Fork

An element in activity diagrams (thick bar) that splits a single flow into multiple concurrent (parallel) flows.

Functional Requirement

A requirement describing what the system does — a function, behavior, or data it must provide.

Generalization (Actor)

In use case diagrams, an actor that inherits all use cases of a more general actor (e.g., Admin inherits from User).

Generalization (Class)

In class diagrams, inheritance — a subclass inherits attributes and operations from a superclass.

Glossary

A collection of agreed-upon term definitions used in a project to avoid ambiguity and ensure shared understanding among stakeholders.

Goal Model

A model showing stakeholder goals and their decomposition into sub-goals, eventually leading to concrete requirements.

Guard Condition

A boolean condition (in square brackets) on a state machine transition that must be true for the transition to occur.

Impact Analysis

The process of determining what artifacts (requirements, design, code, tests) are affected by a proposed change. Enabled by traceability.

Include (Use Case)

A relationship where a base use case always incorporates the behavior of the included use case. The included behavior is mandatory.

Inspection

The most formal review technique with defined roles (moderator, author, reviewers, scribe), mandatory preparation, and a structured process for defect detection.

Interview

An elicitation technique: a structured or semi-structured conversation with a stakeholder to explore their needs and perspectives in depth.

Join

An element in activity diagrams (thick bar) that synchronizes multiple concurrent flows back into a single flow.

Kano Classification

A prioritization technique classifying requirements by customer satisfaction impact: basic (expected), performance (proportional), excitement (delighter).

MoSCoW

A prioritization technique categorizing requirements as Must have, Should have, Could have, or Won't have (this time).

Model

An abstract representation of a system or domain aspect using a defined notation. Used to reduce ambiguity and provide specific perspectives.

Multiplicity

In class/ER diagrams, the number of instances that can participate in a relationship. Notations: 1, 0..1, 0..*, 1..*, etc.

Natural Language

Requirements written in everyday human language. Universally readable but prone to ambiguity.

Negotiation

The process of resolving conflicts between stakeholders with incompatible requirements or expectations.

Nominalization

A language defect in requirements where verbs are turned into nouns, hiding the actor and action (e.g., "the calculation" instead of "the system calculates").

Observation

An elicitation technique where the RE watches stakeholders perform their actual work to discover tacit knowledge and real workflows.

Pairwise Comparison

A prioritization technique that systematically compares every requirement against every other to produce a relative ranking.

Perspective-Based Reading

A review/elicitation technique where documents are examined from specific stakeholder perspectives (user, developer, tester) to find different types of issues.

Post-Requirements Traceability

Links from requirements forward to downstream artifacts: design, code, and test cases.

Pre-Requirements Traceability

Links from requirements backward to their sources: stakeholders, regulations, business goals.

Prioritization

The process of determining the relative importance of requirements to guide implementation order and scope decisions.

Prototyping

Creating a preliminary model of the system (throwaway or evolutionary) to help stakeholders understand and refine requirements.

Quality Requirement

A requirement specifying how well the system performs its functions: performance, usability, reliability, security, maintainability, portability. Also called non-functional requirement.

Questionnaire

An elicitation technique using written questions distributed to many stakeholders. Scalable but lacks interactive follow-up.

Requirement

A condition or capability needed by a stakeholder to solve a problem or achieve an objective, that must be met or possessed by a system or system component.

Requirements Attribute

Metadata attached to a requirement: ID, priority, status, source, author, version, risk, stability, etc.

Requirements Engineer

The person responsible for eliciting, documenting, validating, and managing requirements. Acts as a mediator between stakeholders and the development team.

Requirements Engineering

The systematic approach to eliciting, documenting, validating, and managing requirements throughout a project.

Requirements Management

The RE activity of organizing, tracking, and controlling requirements: attributes, prioritization, traceability, versioning, and change management.

Requirements Specification

A document describing WHAT the system must do from the stakeholder perspective (problem-oriented). Contrast with System Specification.

Sentence Template

A standardized syntactic pattern for writing requirements (e.g., "The <system> shall <verb> <object> <condition>") to ensure consistency and reduce ambiguity.

Shall / Should / May

Obligation keywords: "shall" = mandatory, "should" = recommended, "may"/"can" = optional. Based on RFC 2119 conventions.

Stakeholder

A person or organization that has a direct or indirect influence on the system's requirements, or is affected by the system.

State Machine Diagram

A UML diagram showing the states an entity can be in, the transitions between states, and the events/guards/actions that trigger transitions.

System Boundary

The boundary separating the system under development from its environment (the system context).

System Context

The part of the environment that is relevant to defining the system's requirements: interacting users, external systems, processes, regulations.

System Specification

A document describing HOW the system will behave from the developer perspective (solution-oriented). Contrast with Requirements Specification.

System under Development (SuD)

The system currently being specified and built. The focus of the RE effort.

Traceability

The ability to follow a requirement from its origin (source), through its specification, to its implementation and verification in downstream artifacts.

Traceability Matrix

A table linking requirements to their sources, design elements, code modules, and test cases.

Use Case

A description of a specific interaction between an actor and the system to achieve a goal. Includes main flow, alternative flows, and exception flows.

Use Case Diagram

A UML diagram showing actors, use cases, the system boundary, and relationships (association, include, extend, generalization).

Validation

Checking that requirements correctly reflect stakeholder intentions and meet quality criteria. "Are we building the right thing?"

Verification

Checking that an artifact conforms to its specification. "Are we building the thing right?"

Versioning

Tracking changes to requirements by assigning version numbers and maintaining a change history.

Walkthrough

A review technique where the author leads reviewers through a document, explaining its content. Low to medium formality.

Workshop

A facilitated group session with multiple stakeholders to collaboratively define, discuss, and prioritize requirements.