Series 5: Requirements
Part 2 of 4: Passing Review, Failing Reality
Requirements documents rarely fail loudly.
They get written. They get reviewed. They get signed off by the stakeholders who requested them.
By every visible measure, the requirements process worked.
Then the build finishes, and someone says the sentence every project dreads: "This isn't what we asked for."
Except, often, it is exactly what was asked for. It just wasn't what was needed. The gap between those two things opened up long before the build started.
It simply had nowhere to show itself until now.
The Review Meeting Doesn't Test What You Think It Tests
A requirements review meeting confirms that stakeholders read the document and didn't object.
It does not confirm that every stakeholder interpreted each requirement the same way.
It does not confirm that the requirement was validated against an actual business need rather than a convenient assumption.
It does not confirm that the requirement will still make sense once it collides with a different requirement, written by a different stakeholder, three pages later.
A review meeting is a checkpoint for visibility, not a checkpoint for accuracy. Stakeholders can approve a document in good faith and still be approving three incompatible interpretations of the same sentence.
Four Places Requirements Quietly Fail
Requirements breakdowns tend to cluster in a small number of predictable places.
Ambiguous language treated as precise. "The system should process requests quickly" reads like a requirement. It functions like a wish, because "quickly" hasn't been defined against any threshold anyone can test against.
Assumed context that was never stated. A requirement written by someone close to the process often leaves out the exceptions and edge cases that person considers too obvious to mention. They may be obvious, but they should never be left to the build team to guess.
Requirements that conflict without anyone noticing. One stakeholder's requirement optimizes for speed. Another's optimizes for a validation step that adds time. Both get approved, because they were reviewed separately, by different people, in different meetings.
Requirements validated against the wrong person. A requirement confirmed by a manager who describes how the work is supposed to happen can still be wrong, if the manager's description doesn't match how the work is actually performed by the people doing it.
None of these failures look dramatic when they happen. They look like normal, well-documented decisions. The drama arrives later.
Why the Damage Doesn't Show Up Until Later
A flawed requirement is inert right up until something forces it to be specific.
Ambiguous language stays comfortable until a developer has to pick one interpretation to build.
Conflicting requirements stay invisible until a test case forces both to be satisfied at once.
A requirement validated against the wrong person stays convincing right up until an actual end user tries to use what was built.
That's what makes requirements breakdowns so costly: they are discovered downstream, by a different team, working from a document everyone already approved.
By the time the flaw surfaces, it isn't a requirements conversation anymore. It's a defect, a change request, or a delay — with all the added cost that reclassification brings.
Why Sign-Off Isn't the Same as Validation
Sign-off answers a narrow question: did the right people see this document and agree to move forward?
Validation answers a different question: does this requirement accurately and specifically reflect a real business need, confirmed against how the work actually happens?
A requirement can pass the first test and fail the second, especially when sign-off happens quickly, under time pressure, by stakeholders reviewing a document alongside a dozen other priorities.
Treating sign-off as validation is one of the quieter ways a requirements process can look rigorous while still leaving significant risk unaddressed.
Closing Thought
The requirements documents that caused the most trouble in my experience were rarely the incomplete ones — those tend to get caught.
The dangerous ones were thorough, well-organized, and confidently approved by everyone in the room. They failed the same way agreement fails without alignment: quietly, and only once something forced the gap into the open.
Catching that gap during requirements is uncomfortable. It's far less costly than catching it during a defect triage call, three weeks before go-live.
Professional Note
This article is informed by recognized business analysis and change management guidance, including IIBA’s BABOK® Guide, PMI’s Guide to Business Analysis, PMI’s Business Analysis for Practitioners, and Prosci’s ADKAR® model where relevant. The discussion reflects my professional interpretation and field experience, particularly in the areas of stakeholder readiness, adoption risk, implementation planning, and organizational change.
Next in the Series
Part 3: How Business Analysis Turns Priorities into Requirements
Knowing where requirements break down is only useful if there's a discipline for preventing it. In the next issue, we'll look at the elicitation, traceability, and validation techniques business analysis uses to turn a stakeholder's priority into a requirement a team can actually build against.
