CPRE key terms

A person or group with an interest in a system because they affect it, are affected by it, or depend on it to meet their own goals and responsibilities.

The activity of gathering requirements from stakeholders and other sources through techniques such as interviews, workshops, observation, and document study, rather than simply collecting what is written down.

A structured method such as an interview, workshop, observation session, questionnaire, or document analysis used to draw out requirements and the underlying needs behind them.

A conversation with one or a few stakeholders, guided by prepared questions, used to uncover needs, context, and expectations that documents alone would not reveal.

A facilitated group session in which stakeholders jointly identify, discuss, and agree on requirements, helping to surface conflicts and build shared understanding early.

A technique in which the analyst watches stakeholders perform their real work to discover tacit knowledge, workarounds, and environmental constraints that people rarely articulate in interviews.

Know-how and context that people hold but seldom state explicitly, so it must be drawn out through observation, probing questions, and discussion rather than direct requests.

The process of identifying who is affected by a system, assessing their influence and interest, and deciding how to involve them in requirements work.

A statement of a capability or condition that a system must satisfy, expressed at a level of detail sufficient for it to be validated and later realized.

A statement describing what the system must do, such as a behavior, calculation, or service it provides to its users or to other systems.

A statement describing a quality or constraint the system must meet, such as performance, security, usability, or reliability, rather than a specific behavior.

A measurable property of a system such as response time, availability, or maintainability, which must be stated with concrete criteria so it can be verified.

A restriction imposed on the solution that limits the space of acceptable designs, such as a mandated technology, budget ceiling, legal rule, or interface standard.

A statement accepted as true for planning purposes without proof, which must be recorded and later confirmed because it can undermine requirements if wrong.

A high-level statement of why the organization undertakes a project and what business outcome it expects, providing the rationale from which system requirements are derived.

A concise description of the desired future state and the value a system will deliver, aligning stakeholders before detailed requirements are written.

A desired outcome an organization or stakeholder wants to achieve, which requirements should support and against which their contribution can be assessed.

A description of a sequence of interactions between a system and external actors that delivers a observable result of value to one of those actors.

A person, role, or external system that interacts with the system under consideration, exchanging information or triggering behavior across its boundary.

A concrete narrative of one path through a use case, illustrating a specific situation with particular inputs, events, and expected outcomes.

The dividing line between what the system under consideration is responsible for and what remains in its environment, defining scope for requirements work.

The agreed extent of what a project or system will and will not address, used to decide whether a given requirement is in or out of the work.

The structured written record of requirements, their rationale, and related models, produced so that stakeholders can review, agree, and later rely on them.

A structured document or model that states the agreed requirements precisely enough to guide design, testing, and acceptance decisions.

Metadata attached to a requirement, such as its identifier, source, priority, status, or owner, which supports management and traceability.

The ability to link a requirement to its source, related design elements, tests, and change history, so impact and coverage can be examined.

The process of ranking requirements by value, risk, cost, or urgency to guide planning and resolve conflicts when resources are limited.

The activity of confirming that stated requirements describe what stakeholders actually need and are of acceptable quality, before they are implemented.

The activity of checking that a requirement statement is correct, complete, consistent, unambiguous, and testable as written.

The property of a requirement being stated so precisely that a test or inspection can objectively determine whether it has been met.

A defect in a requirement where the wording allows more than one reasonable interpretation, leading to divergent designs or disputed acceptance.

The process of identifying incompatible requirements or stakeholder goals, negotiating trade-offs, and reaching a documented agreement on what will be built.

The controlled process for proposing, assessing, approving, and implementing changes to agreed requirements while keeping related artifacts consistent.

A formally agreed and frozen version of requirements that serves as the reference for further work and against which changes are evaluated.

An uncertain event or condition that, if it occurs, affects project objectives, often arising from unclear, unstable, or unachievable requirements.

Software that stores requirements with their attributes and links, supporting traceability, prioritization, reporting, and controlled change across the lifecycle.