Requirements validation
Requirements validation is checking that the documented requirements describe what the stakeholders actually need, before the software is built. It asks whether the right thing is being specified, and it is done through reviews, walkthroughs, prototypes and early acceptance test cases. Verification, by contrast, checks that what was built matches the requirements.
The longer version
Validation puts the written requirements in front of the people whose needs they claim to describe and asks whether they are right. A requirement can be clear, consistent and testable and still be wrong, because the author misread the business or the need has since changed. Verification does not find this, and without requirements validation, only acceptance testing finds it, late. A test written from the requirement will pass on a product that faithfully builds the mistake.
The techniques are mostly conversations with an artefact in front of the group. A review with stakeholders reads each requirement aloud, a walkthrough follows a user through the flow, and a prototype or mock-up lets people react to something they can see. Drafting acceptance test cases from a requirement brings the vague ones into the open, because nobody can write a test for them.
A reviewer checks for completeness, for contradictions between requirements, for feasibility and for testability, and asks that each requirement trace to a stakeholder need. The last check is where a requirements traceability matrix helps, since a requirement that traces to no need is a candidate for removal.
The distinction sits inside the larger verification and validation pair, where validation asks whether the team is building the right product and verification asks whether it is building the product right. User acceptance testing puts the validation question to the finished software, and requirements validation puts it to the specification before anything is built.
Common questions
What is the difference between requirements validation and verification?
Requirements validation checks that the requirements capture what stakeholders need. Verification checks that the product or a work product matches its specification. Validation asks whether the team is building the right thing, and verification asks whether it is built correctly.
What techniques are used for requirements validation?
Common techniques are reviews and inspections with stakeholders, walkthroughs of user flows, prototypes and mock-ups, and drafting test cases from the requirements. Each puts the written text in front of someone who knows the need and can say where it is wrong.
When does requirements validation happen?
A first pass comes when requirements are drafted, and checks recur whenever they change. In agile teams it happens at refinement and in Three Amigos conversations, and it comes round again when users see the result in acceptance testing.
Who validates requirements?
Stakeholders and users judge whether the requirements describe the real need, and the product owner or business analyst brings them together. Testers contribute by finding statements that cannot be tested, and developers by flagging what is infeasible.
What is the output of requirements validation?
The output is a list of defects found in the requirements, such as ambiguities, contradictions and gaps, and an agreed version that stakeholders have confirmed. That version is the baseline the team builds and tests against.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.