3.6. Validating Requirements Through Delivery
💡 First Principle: Gathering requirements is the beginning of BA work, not the whole job. The role continues through delivery — defining what "done, correctly" looks like, and checking the delivered result against that definition before calling the work complete.
Defining acceptance criteria. Acceptance criteria are the specific, testable conditions a deliverable must meet to be considered acceptable. They translate a requirement ("the system should let users reset their password") into something checkable ("a user can request a reset email, receive it within 2 minutes, and set a new password that meets the stated complexity rules"). Vague requirements produce vague, undebatable disputes about whether something is "done"; well-written acceptance criteria prevent that argument before it starts.
Confirming delivery readiness. Before a product or project is considered ready for delivery, the BA checks the result against the RTM (predictive) or backlog (adaptive) — every traced requirement should have a corresponding, verified deliverable. A gap here (a requirement with no corresponding tested deliverable) is exactly what the traceability artifact exists to catch.
⚠️ Exam Trap: "The features were built" is not the same as "the requirements were validated." A scenario describing a team that shipped everything on the backlog without checking each item against its acceptance criteria is describing incomplete BA work, even though the deliverable technically exists.
A worked example. A predictive project's RTM lists 40 requirements, each linked to a test case. At the end of the project, 38 requirements show a passed test and 2 show no linked test result at all. Those 2 unresolved rows are exactly what the RTM is designed to surface — the project isn't actually ready for delivery until someone confirms whether those 2 requirements were deliberately descoped, still in progress, or simply missed. Declaring the project "done" without resolving that gap is the failure mode this subsection is testing for.
Why this closes the loop back to requirements gathering. Acceptance criteria only work as a validation tool if they were written clearly enough, back when the requirement was first gathered, to be checked objectively later. A vague original requirement produces vague acceptance criteria, which produces a delivery validation step that can't actually confirm anything — which is one more reason requirements gathering (3.3) and delivery validation aren't separate, disconnected activities but two ends of the same traceability chain.
When good criteria still don't prevent disputes. A team can write clear, well-specified acceptance criteria for every requirement and still find itself in repeated arguments about whether items are genuinely done. When that happens, the criteria themselves usually aren't the problem — the more likely explanation is that validation isn't being consistently applied against those criteria in practice. Well-written standards only do their intended job properly if someone is actually and consistently checking delivered work against them every single time, not just some of the time.
Prioritizing validation when time runs short. Near the end of a project, a team sometimes faces a choice between finishing final validation on the last few requirements and taking on one more unscoped request that just came in. Confirming that the originally agreed scope was actually delivered correctly is the core delivery obligation, and it takes priority over adding new work this late — validating what was promised comes before expanding what's promised, especially this close to sign-off, since an unfinished validation pass leaves the project's true completeness genuinely uncertain, and uncertainty at sign-off is exactly what this whole validation discipline exists to eliminate.
