Requirements: Elicit Them from Stakeholders, Do Not Assume Them

Most rework on projects comes not from weak execution but from a vague ask. A sentence like "we need the system to be fast" passes through a meeting unchallenged and then detonates at handover: one person meant sub-second response time, another meant early delivery. Requirements are the discipline that converts such phrases into conditions that can be measured and tested before anything is built on them. Their placement in the Eighth Edition says something important: this is a process inside the Scope performance domain, not an activity that precedes it.

Definition and Foundation

A requirement is a condition or capability that must be present in a product, service, or result to satisfy a business need. Requirements documentation is a description of how individual requirements should meet the business needs of the project. Requirements may start at a high level and become progressively more detailed as more information becomes known. Before being baselined, they should be:

• Unambiguous — that is, measurable and testable.
• Traceable — able to be traced back to their origin and forward to their deliverable.
• Complete and consistent — omitting no need and contradicting no other requirement.
• Acceptable to key stakeholders — not merely written into a document.

These five are conditions together, not options. A requirement that cannot be tested can be neither accepted nor rejected at handover, so it becomes material for argument instead of the standard that settles one. Acceptability to key stakeholders is the most frequently skipped of the five: documenting a requirement is not the same as its owner agreeing to it, and the gap between the two surfaces at the first review.

The Eighth Edition classifies requirements into categories: business requirements, outlining the strategic objectives and high-level needs of the organization; stakeholder requirements, describing the needs of a stakeholder or group; solution requirements, describing the features, functions, and characteristics of the product, split into functional ones describing the behaviors of the product such as actions, processes, data, and interactions, and nonfunctional ones that complement them by specifying performance, security, and operational criteria — reliability, safety, level of service, supportability, retention; and transition and readiness requirements, describing temporary capabilities such as data conversion and training needed to move from the current as-is state to the desired future state.

How It Works in Practice

Eliciting and analyzing

The objective of Elicit and Analyze Requirements is to define and document the stakeholders' needs associated with the features and functions required in the product, service, or result, to assure quality and value will be delivered. Its stated tools in the Eighth Edition include expert judgment; data gathering through benchmarking, brainstorming, focus groups, interviews, questionnaires and surveys, and document analysis; and interpersonal skills and the nominal group technique. Its key benefit is that it provides direction and a starting point for defining a product, service, or result that will add value to stakeholders. Its stated inputs include the project charter, the project management plan, and project documents — the assumption log, lessons learned register, stakeholder register, requirements management plan, and scope management plan — plus enterprise environmental factors and organizational process assets. Elicitation does not begin from a blank page but from context already documented.

The requirements traceability matrix

A grid that links product requirements from their origin to the deliverables that satisfy them. Implementing one helps ensure each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping ensure that requirements approved in the documentation are delivered at the end of the project, and it provides a structure for managing changes to the product scope. It typically covers business needs, opportunities, goals, and objectives; project objectives; project scope and WBS deliverables; product design; product development; test strategy and test scenarios; and high-level requirements down to more detailed ones.

Attributes of each requirement

Attributes recorded in the matrix define key information about a requirement: a unique identifier, a textual description, the rationale for inclusion, the owner, source, priority, version, current status — active, canceled, deferred, added, approved, assigned, completed — and status date. Additional attributes helping ensure stakeholder satisfaction include stability, complexity, and acceptance criteria. The source field in particular is what makes revisiting a requirement months later possible: who asked for it and why. The rationale-for-inclusion field completes it by answering a harder question — why the request was accepted at all, which is the question that returns whenever budget tightens and requirements are proposed for removal.

Requirements in adaptive environments

In an adaptive environment requirements are collected in the form of user stories that are then prioritized in a backlog. The difference is not only one of format: the backlog is a dynamic, prioritized list, so prioritization itself is part of managing requirements rather than a step that follows it. The unambiguity condition holds in both cases, even where the form of expression changes. In agile projects scope is typically considered at a high level, often represented by the product roadmap with its releases, with requirements elaborated progressively inside the iterations.

On the Exam

The 2026 ECO gives requirements no separate task, folding them into Domain II, Process, under Task 2, develop and manage project scope, through the enablers "define scope" and "obtain stakeholder agreement on project scope." Task 3, help ensure value-based delivery, is related through its enabler "prioritize work based on value and stakeholder feedback."

The dominant pattern is a scenario presenting a disputed requirement and asking for the action. Four keys settle most of it:

• A vague, unmeasurable requirement → returned to its owner for clarification before being baselined.
• A delivered requirement with no source in the matrix → it never went through elicitation, so its route is change control.
• A conflict between two stakeholders' requirements → resolved in analysis before documentation, not deferred to execution.
• A question about ensuring every requirement is covered → the traceability matrix.

What deceives is options offering "assuming what the customer meant" in phrasing that sounds proactive, and offering to defer clarification to testing "to save time." Both move the cost of ambiguity somewhere more expensive: the first to handover, the second to testing, by which point the build rests on a wrong reading. So does conflating a nonfunctional requirement with a nice-to-have: nonfunctional requirements are not a luxury but performance, security, and operational criteria essential to product effectiveness and user satisfaction.

Detailed Mistakes

Baselining a requirement before it satisfies the five conditions

The guide requires that before being baselined, requirements be unambiguous, traceable, complete, consistent, and acceptable to key stakeholders. Skipping any of them pushes the disagreement past approval, where resolving it becomes a formal change request with its cost and delay, instead of a wording adjustment in a meeting.

Treating the matrix as an archive

The traceability matrix is a structure for managing changes to the product scope, not a document filled once and filed. The status, version, and stability fields exist because they change. A matrix untouched since planning tells you what the team thought it would build, not what it is building. The practical difference shows when a change request arrives: a live matrix reveals in minutes which deliverables the request touches and which requirements attach to it, while a neglected one sends you back to individual memory.

Neglecting transition and readiness requirements

This is a category in its own right in the Eighth Edition: temporary capabilities such as data conversion and training, needed to transition from the current state to the desired future one. Omitting them produces a project that delivers a correct product nobody can use on go-live day, so the cost surfaces after project closure, where there is no budget for it.

Where It Does Not Apply

Strict up-front documentation of requirements presumes a need that can be specified before building. Where the need itself is the thing being discovered, the weight shifts from prior documentation to progressive exploration: requirements are collected as stories in a backlog that is continually reprioritized, and the baseline is defined at the beginning of each iteration, aligned with the prioritized requirements. This does not remove the unambiguity condition but relocates it: from the requirements document to the acceptance criteria and the definition of done. One last caution holds throughout: requirements start at a high level and become progressively more detailed as information becomes known — demanding complete detail on day one is not discipline but a refusal to accept how progressive elaboration works.