Requirements Validation

Why it matters

Every later activity copies the requirement. Developers build it, testers derive test conditions and expected results from it, and the tests pass. If the requirement describes the wrong need, the whole chain agrees with itself and is still wrong, and the gap appears only when real users meet the product: in acceptance testing, or in production as complaints, workarounds and change requests. The ISTQB Foundation syllabus (CTFL v4.0) makes the same point about stakeholder feedback: with too little stakeholder involvement the product may not match what stakeholders want, which can mean costly rework, missed deadlines and, at worst, a failed project.

For a tester, validation is where an expected result gets its authority. An expected result taken from an unvalidated requirement is someone’s assumption written down. Taking part in validation also lets you hear the reasons behind the rules, which tells you which scenarios and data matter most, and lets you raise a doubt about the need while changing it still costs a conversation rather than a rebuild.

What requirements validation checks

Validation compares a requirement with the needs of the people it serves. Those people are the stakeholders: end users, the customer or business owner who asked for the change, and everyone whose work it touches, such as support, operations, finance and compliance. Much of what they know is written down nowhere, so validation always means asking them and, where possible, watching them work.

• Right problem: does the requirement solve the problem the stakeholder actually has, or someone’s guess at it?
• Right users and situations: who uses it, on which device, at what time, under what pressure? A rule that suits head office can fail in a busy store at closing time.
• Right rules and numbers: are the limits, fees, deadlines and permissions the ones the business really applies, including exceptions such as public holidays or special customer groups?
• Nothing missing: what do users take so much for granted that nobody wrote it down?
• No hidden conflict: do two stakeholders need different things? The product owner decides; a conflict must not be settled quietly in code or in a test case.

How validation differs from a requirements review

The requirements review you met earlier in this module is verification. It compares the requirement with the qualities of a good requirement and with the documents around it: is it clear, complete, consistent, testable and feasible? Validation compares the requirement with the stakeholders’ needs. The reference point moves from documents to people and their work. The review checklist does ask whether a requirement is correct, but reviewers around a table can only record a doubt; validation settles it with the people who know.

Both are usually static testing, because nothing runs, and the CTFL v4.0 syllabus notes that static testing can serve verification and validation alike. A walkthrough with future users is a review too. What makes an activity validation is what the requirement is compared with, not the meeting format.

The two find different problems, so neither replaces the other. A requirement can pass the review and fail validation, like the order cancellation rule: well written, testable and wrong. It can also please stakeholders in a meeting and fail the review, because "cancel quickly" sounded fine aloud but has no testable meaning.

• A review asks "is it written right?"; validation asks "is it the right need?"
• A review can be done within the delivery team, for example the product owner, a developer and a tester with a checklist; validation needs the people who own the need, or their closest representatives.
• A review finding goes back to the author as a review comment; a validation finding is a decision for the product owner: confirm the requirement, change it or add a new one.
• Some teams and requirements-engineering textbooks use "requirements validation" for the whole check of a requirements document, consistency and completeness included. When you hear the term, ask which question is meant.

Four validation techniques

Each technique makes the need concrete enough for stakeholders to react to. Choose by what the requirement is about and combine them: business rules are best validated with examples, screens and workflows with prototypes, and flows across several roles with walkthroughs. User acceptance testing of the finished product validates too, but it comes late, when learning that a requirement was wrong is already expensive; these techniques work while the requirement is still words.

• Stakeholder review: the requirement is read with the people who own the need, not only by the delivery team. Ask about their work rather than the wording: "Walk me through the last time you did this", "What happens on your busiest day?", "Who else is affected?" Long documents sent out for sign-off tend to be approved unread, so review a few stories at a time, in conversation where you can.
• Walkthrough: the author, usually the product owner or business analyst, leads stakeholders through the requirement as a story: "A customer orders at 21:30 on a Thursday, then…". In CTFL v4.0 the walkthrough is the review type led by the author; its objectives include gaining consensus and educating participants as well as finding anomalies.
• Prototype: a paper sketch, wireframe or clickable mock-up on which stakeholders try real tasks while you watch where they hesitate. It reveals needs that users cannot describe in advance. It shows only the surface, not the rules behind it, and a polished prototype can make people believe the product is almost finished.
• Acceptance tests as examples: concrete cases with an input and an expected result, written before coding and confirmed by the stakeholder: "Order at 15:00 for the 17:00 slot: accepted. Is that right?" This is the idea behind acceptance test-driven development (ATDD) in CTFL v4.0. A disagreement about one expected result exposes a wrong or missing rule, and the agreed examples later run as acceptance tests.

Try it: Acceptance Criteria Generator Try it: User Story → Test Scenarios

Worked example: validating a click-and-collect rule

A grocery chain adds click and collect. REQ-17 says: "Customers choose a one-hour collection slot between 10:00 and 22:00 on one of the next three days. An order must be placed at least 2 hours before its slot starts. Each slot accepts up to 20 orders." The requirements review passed it: every number is explicit and each rule can be tested. The product owner then validates it with the people whose work it changes, and the tester joins every session.

Each session used a different technique, and each found something no review checklist could have found, because REQ-17 was clear, consistent and testable:

• Stakeholder review with two store managers: opening hours differ by branch and change during Ramadan, so fixed slots from 10:00 to 22:00 would offer times when some stores are closed. Slots must follow the opening hours of each branch.
• Walkthrough with the pickers who assemble orders: walking through a busy Thursday evening shows that 20 small orders and 20 orders of 60 items take very different times to pick. The real limit is picking capacity, not the number of orders.
• Prototype session with five customers: in a clickable mock-up, three of them chose a slot before noticing it belonged to a different branch from the one they meant. The branch must be chosen, and stay visible, before slots appear.
• Acceptance examples with the business owner: "Order at 15:00 for the 17:00 slot: accepted" was confirmed. "Order at 07:30 for the 10:00 slot: accepted" was not: picking starts at 09:00, so that order would get one hour of picking. The 2 hours mean picking time, a rule nobody had written down.

REQ-17 validation log
V1  Stakeholder review · store managers
    Wrong rule: slots ignore the opening hours of each branch.
V2  Walkthrough · pickers
    Wrong rule: the limit counts orders, but picking time depends on items.
V3  Prototype · 5 customers
    Missing need: 3 of 5 chose a slot before noticing the branch.
V4  Acceptance examples · business owner
    Missing rule: "2 hours" means picking time, not clock time.

Product owner: V1, V3 and V4 change REQ-17 before the sprint. V2 becomes
its own story once operations estimate picking times. REQ-17 v2 goes
through review again, then V1, V3 and V4 are confirmed with the people
who raised them.

Try it: Requirements → Test Scenarios

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• Certified Tester Acceptance Testing (CT-AcT)ISTQB · 2019ISTQB's specialist syllabus on acceptance testing: user, contractual and regulatory acceptance testing, alpha and beta testing, and how testers work with product owners and business analysts.
• The 2020 Scrum GuideKen Schwaber and Jeff Sutherland · 2020The definition of Scrum: its accountabilities, events and artifacts, including the Definition of Done that testing helps meet.