Verifying and Validating Requirements

Two Different Questions About the Same Requirement

The Need domain requires a business analyst to check requirements from two distinct angles, and the ECBA exam frequently tests whether a candidate can tell them apart. Verification asks: is this requirement well-written? Validation asks: is this the right requirement? BABOK v3 defines requirements verification as the process of checking that a requirement or design has been documented correctly - that it is at the right level of detail, uses proper structure and terminology, and satisfies the applicable quality standards, including the nine characteristics of good requirements covered in the previous section. BABOK v3 defines requirements validation as the process of confirming that a requirement or design delivers business value and aligns to the business goals, objectives, and needs that justified the change in the first place. A requirement can pass one check and fail the other, and understanding which failure mode applies is a core Need-domain skill.

Verification: Is It Correct?

Verification is a quality-control activity performed against the requirement itself, independent of whether the requirement is still needed. Typical verification checks include:

• Does the requirement follow the organization's approved template and terminology?
• Is it atomic, unambiguous, and testable, as covered in the previous section?
• Is it free of internal contradictions and consistent with related requirements?
• Is it traceable to its source, so its origin can be confirmed later?

Verification is usually performed by peers, quality reviewers, or the BA themselves through a structured review, and can happen before a stakeholder ever sees the final version.

Traceability Supports Both Checks

Both verification and validation lean on traceability - the documented link between a requirement and its source, and between a requirement and the higher-level need it satisfies. Without traceability, verification cannot confirm a requirement's origin, and validation cannot confirm which business objective a requirement is meant to support. When a requirement is traced back to a specific elicitation session, a specific stakeholder, and a specific business objective, both checks become mechanical: a reviewer can trace forward to confirm the requirement still connects to something the organization currently funds, and can trace backward to confirm nothing was lost or altered from the original elicitation. Weak or missing traceability is why validation failures often surface late, well after a requirement has already been implemented, because no one could quickly confirm which objective it was supposed to serve.

Validation: Is It the Right Thing?

Validation looks outward, from the requirement to the business case that justified it. A requirement can be perfectly written and still fail validation if:

• The business objective it supported was cancelled or changed.
• It duplicates value already delivered by another initiative.
• It reflects an individual stakeholder's preference rather than a genuine organizational need.
• The cost of delivering it exceeds the value it would return.

Validation typically involves confirming with the accountable business sponsor or stakeholder that the requirement still supports a current, funded objective, not simply confirming that the words on the page are clear.

Verification vs. Validation at a Glance

Checking Alignment and Flagging Conflicts

Because multiple stakeholders elicit requirements independently, conflicts surface regularly - one department may need a field mandatory while another needs it optional. Part of the Need domain's validation responsibility is actively looking for these conflicts rather than assuming consistency. When a BA finds two requirements that cannot both be true, the correct response is not to silently pick one; it is to document the conflict, trace both requirements back to their underlying business need, and escalate the conflict to the accountable stakeholders for resolution against the organization's actual priorities. This keeps the decision with the people who own the business objective, rather than embedding an undocumented judgment call inside the requirements documentation where it will surface later as a dispute.

Why the Distinction Matters on Exam Day

A situation-based question that describes a requirement passing every quality check yet still not supporting any current business objective is testing a validation failure, not a verification failure - a common wrong-answer trap is to say the requirement needs to be rewritten more clearly when the actual problem is that it doesn't need to exist at all. Conversely, a question describing a requirement that is clearly connected to an active, valuable initiative but is stated ambiguously is testing a verification failure. Keeping the two questions - is it well-written versus is it the right thing - separate is the fastest way to eliminate distractors on Need-domain exam items. When in doubt about which failure a scenario describes, check whether the complaint is about the requirement's wording or about its connection to a funded business objective.