Series 5: Requirements
Part 1 of 4: Where Wishes End and Requirements Begin
By the time a project reaches requirements, it usually feels like the hard part is over.
Stakeholders have been interviewed.
Priorities have been surfaced and negotiated.
Leadership has approved the work.
What's left, it seems, is simply writing down what everyone wants.
That assumption is where a surprising number of projects quietly go wrong.
A requirement is not a record of what a stakeholder wants. It's a validated, traceable statement of what the business needs in order to succeed.
The difference between those two things determines whether a project builds the right thing the first time — or discovers, much later, that it built exactly what was asked for and still missed the point.
What a Wish List Actually Contains
Ask a stakeholder what they want, and they'll give you an honest answer.
It just won't necessarily be a requirement.
"I want this to be faster." Faster than what? By how much? For whom?
"I want a dashboard that shows everything important." Important to which stakeholder, measured against which goal?
"I want this to work the way the old system did, but better." Which parts of the old system, and better in what specific way?
None of these statements are wrong. They are simply not requirements — yet.
They're the raw material requirements get built from — preferences, frustrations, half-formed solutions — captured before anyone has tested them against what the business actually needs.
A wish list captures what people say. A requirement captures what's been verified.
Where "Validated" Does the Real Work
The word doing the heavy lifting in a real requirement is validated.
Validation means the statement has been checked against something beyond the person who said it.
It has been checked against the priorities surfaced during stakeholder alignment, against how the work actually happens today, against the people who will use what gets built, and against what "success" was defined to mean before anyone started designing a solution.
A wish becomes a requirement only after it survives that scrutiny.
Most of what stakeholders initially ask for survives in some form. Some of it doesn't — and finding out which is which before a solution gets built is not a delay in the project.
It is the project.
Traceability: The Test Most Wish Lists Fail
There's a simple test that separates a requirement from a wish: can you trace it back to a validated business need, and forward to how it will be confirmed as delivered?
A genuine requirement can answer both questions.
Backward: Why does this requirement exist? It traces to a business problem, a stakeholder priority, or a decision made during the alignment process — not simply to "a stakeholder mentioned it."
Forward: How will we know this was delivered correctly? It connects to an acceptance criterion specific enough that two different people would agree, independently, on whether the requirement was met.
A wish list item usually fails one of these, often both. It exists because someone said it out loud, and no one has yet defined what "done" would look like.
Traceability isn't paperwork. It's the mechanism that keeps a requirement honest.
Why This Distinction Is Worth Defending
It would be easier, in the moment, to treat every stakeholder request as a requirement. It feels more responsive. It avoids the uncomfortable conversation where someone has to say, "that's not quite what we need."
That comfort is expensive.
Every unvalidated wish that makes it into a requirements document becomes something a team builds, tests, and delivers — using real time, real budget, and real organizational attention.
If it turns out not to reflect an actual business need, the cost of that mistake isn't paid at the requirements stage. It's paid much later, when the feature ships and no one uses it the way it was designed to be used.
Requirements discipline isn't about being difficult with stakeholders. It's about making sure their time, and the organization's investment, goes toward something that was actually validated — not just something that was asked for first.
Closing Thought
Stakeholders are rarely wrong about what frustrates them. They're not always right about what will fix it.
The job of requirements work isn't to take their words at face value or to overrule them.
It's to turn a legitimate concern into something specific enough to build, test, and confirm — before anyone commits resources to finding out the hard way whether it was the right thing to build.
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 2: Where Requirements Break Down Before Anyone Notices
Requirements that look complete on paper can still fail the business they were written for. In the next issue, we'll look at how vague, assumed, or unvalidated requirements pass every review meeting — and only reveal themselves as defects, rework, or mismatched expectations once the build is already underway.
