The requirements document was thorough. Forty-seven pages of functional specifications, user stories, acceptance criteria, and process flows. Stakeholders had been interviewed. Workshops had been conducted. Everything was documented.
Six months into development, the project was in trouble. The system being built matched the requirements perfectly, and it was completely wrong. Users didn’t want what had been specified. The documented processes didn’t reflect how work actually happened. The carefully gathered requirements had captured what people said they needed, not what they actually needed.
This isn’t a story about one failed project. It’s the story of requirements gathering itself. The process is broken in ways that are structural, not incidental. Understanding why helps explain what to do instead.
Why stakeholders describe solutions, not problems
When you ask someone what they need, they tell you what they think will solve their problem. They’ve already done the analysis in their head: identified the issue, imagined a solution, and now they’re presenting that solution as a requirement.
“We need a dashboard that shows daily sales by region.”
That’s not a requirement. That’s a solution. The actual need might be: “I don’t know if we’re on track until the monthly report, and by then it’s too late to do anything about it.” Or: “My boss keeps asking me questions I can’t answer without spending two hours pulling data.” Or: “I suspect the West region is underperforming but I can’t prove it.”
Each of those underlying problems might lead to a dashboard, or might lead to something completely different. An automated alert when sales drop below threshold. A weekly email summary. A conversation with the West region manager. The dashboard is one possible solution; it’s not the requirement.
But requirements gathering typically accepts the stated solution as the requirement. The document captures “dashboard showing daily sales by region” and moves on to the next item. The underlying problem is never surfaced, never examined, never validated.
How current-state constraints become future-state requirements
People describe what they need in terms of what they know. Their mental model is shaped by the current system, current process, current constraints. When they imagine improvement, they imagine the current state made slightly better, not a fundamentally different approach.
“The new system should have the same reports as the old system.”
Why? Because those reports exist. Because people are used to them. Because imagining different reports requires imagining a different way of working, which is hard to do when you’re busy doing the actual work.
This is how current-state limitations get baked into future-state requirements. The workaround becomes a feature request. The constraint becomes a specification. The thing people do because they have no choice becomes the thing the new system must support.
Consider a typical company replacing its order management system. The requirements include: “Users must be able to enter orders into a staging queue for batch processing at end of day.” This is a limitation of the old system: orders couldn’t process in real time, so they accumulated for batch runs. But it has become “how we do orders.” The requirement isn’t actually about batch processing; it’s about order entry. Real-time processing would be better. But no one can imagine it because no one has experienced it.
The edge case problem
Requirements workshops spend disproportionate time on edge cases. Someone raises an unusual scenario. The room discusses how to handle it. The discussion is engaging because edge cases are interesting: they’re puzzles to solve. Meanwhile, the core workflow that happens a thousand times a day gets documented in two sentences because “everyone knows how that works.”
The result: detailed requirements for situations that occur monthly, vague handwaving for situations that occur hourly.
Edge cases also accumulate. Every stakeholder has a “but what about...” scenario. Each one gets added to the requirements. The specification grows to handle every possible situation, no matter how rare. The system becomes complex to accommodate complexity that barely exists in practice.
A typical example: elaborate handling for international orders with split shipments to multiple countries with different tax jurisdictions. A scenario like that might occur twice in a year, yet it consumes weeks of development effort and creates ongoing maintenance burden, because it made it into the requirements.
The people problem
Requirements are typically gathered from managers and subject matter experts, people who can articulate processes and attend workshops. These aren’t always the people who do the work.
The manager describes how the process is supposed to work. The people doing the actual work know how it really works: the shortcuts, the workarounds, the unofficial procedures that keep things moving. But they’re not in the requirements sessions. They’re doing the work.
This creates a documentation gap. The requirements capture the official process. The system gets built to the official process. Users receive a system that doesn’t match how they actually work, because no one asked them.
Even when front-line workers are included, there’s a power dynamic. They defer to managers in the room. They describe what they think they’re supposed to do, not what they actually do. The unofficial becomes invisible.
Requirements as political artifacts
Requirements documents aren’t neutral. They reflect organizational politics, competing priorities, and stakeholder influence. The executive who wants their pet feature gets it in the requirements. The department with more political capital gets more of their needs addressed. The team that shows up to more workshops has more input.
This means requirements often represent negotiated compromises rather than actual needs. Features get included to satisfy stakeholders, not because users need them. Scope gets expanded to give everyone something, even when a focused solution would be better.
We’ve seen requirements documents that were obviously designed to justify a predetermined conclusion. The “requirements gathering” was theater: the decision had already been made, and the documentation was constructed to support it. This is more common than anyone admits.
What works instead
The alternative to traditional requirements gathering isn’t no requirements. It’s different approaches that surface actual needs rather than stated solutions.
Start with problems, not solutions. Before asking what people need, understand what’s not working. What takes too long? What causes errors? What frustrates users? What do customers complain about? Problems are more honest than requirements: harder to game, harder to dress up.
Observe, don’t just interview. Watch people do the work. Sit with them. See the workarounds, the frustrations, the unofficial procedures. Observation reveals what interviews miss. People can’t always articulate what they do, but you can see it.
Prototype before specifying. Build something rough and let people react to it. A working prototype surfaces requirements that no amount of discussion would reveal. “I don’t know what I want, but I know it’s not this” is useful information. Iterate from there.
Distinguish must-have from nice-to-have ruthlessly. Most requirements are preferences, not necessities. Force prioritization. What would make this project a failure if omitted? That’s a requirement. Everything else is negotiable.
Validate with the people who do the work. Before finalizing requirements, review them with front-line users. Not in a big meeting with managers present, but separately, where they can speak honestly. Does this match how you actually work? What’s missing? What doesn’t make sense?
Living with imperfect requirements
Requirements will never be perfect. Even the best process produces specifications that will need to change. The question is whether your approach accommodates this reality or fights it.
Build in iteration. Plan for requirements to evolve. The first release won’t be right, so create space to learn and adjust.
Keep requirements lightweight. Heavy documentation creates inertia. When changing a requirement means updating forty pages of specifications, requirements don’t change, even when they should.
Maintain proximity between builders and users. The tighter the feedback loop between the people building and the people using, the faster misalignment gets caught and corrected. Distance (organizational, physical, procedural) lets bad requirements persist.
Treat requirements as hypotheses, not facts. “We believe users need X” is more honest than “Users need X.” Hypotheses get tested; facts get implemented without question.
The requirements problem isn’t solvable. It’s manageable. The organizations that build what’s actually needed aren’t the ones with better requirements documents. They’re the ones with better processes for discovering what’s needed, validating assumptions, and adapting when they’re wrong.
Strategic Advisory helps organizations rethink how they discover and validate requirements, moving from documentation exercises to genuine problem discovery.
Enterprise Engineering builds with iteration in mind, creating systems designed to evolve as understanding deepens, not locked to initial specifications.