I have seen many requirements documents over the years.
Some were 100 pages long and still left major questions unanswered. Others were much shorter, but clear enough for a delivery team to understand what needed to be built and for a vendor to prepare a meaningful proposal.
So, for me, the real question is not:
“Have we documented enough?”
It is:
“Could someone who was not part of all the discussions understand what we need, why we need it, what good looks like, and what they are allowed to assume?”
That is a much tougher test.
Standards such as ISO/IEC/IEEE 29148, and decades of work by practitioners such as Karl Wiegers, Suzanne and James Robertson, Ivar Jacobson and Gojko Adzic, converge on some remarkably consistent ideas: good requirements should be clear, necessary, traceable, feasible and verifiable.
All true.
But when I look at an actual IT or digital project, I tend to use a few much more practical tests.
Can I understand why each requirement exists?
A requirement should connect to something real: a business objective, process problem, user need, compliance obligation, operational risk or measurable outcome.
If nobody can explain why a requirement exists, I would challenge whether it belongs in scope.
Ideally, you should be able to follow the logic:
Business need → Requirement → Expected behaviour → Acceptance criteria
Without that chain, requirements very easily become a wish list.
Are we describing the need, or already designing the solution?
This happens all the time in digital projects.
Someone writes:
“The system must use Power BI and refresh every 15 minutes.”
But what is the actual requirement?
Maybe management needs visibility of a KPI with information no more than 15 minutes old.
Power BI may genuinely be a mandatory technology constraint. Or it may simply be the first solution someone thought of.
The distinction matters, especially when requirements will be handed to an external vendor.
If something is genuinely mandatory — a cloud platform, ERP, identity provider, integration standard or security policy — make it explicit as a constraint.
Otherwise, describe the need and leave room for the delivery team to design the best solution.
Could two sensible people read the same requirement differently?
Certain words always make me suspicious:
fast, flexible, easy, user-friendly, appropriate, real-time.
They sound reasonable, but they can mean almost anything.
“The system must respond quickly” is not particularly useful.
“The system must return 95% of search results within two seconds under agreed load conditions” is something a technical team can actually design and test against.
The same applies to statements such as:
“the solution should integrate seamlessly”
“access should be secure”
“the application should support high volumes”
They may all express valid needs, but they are not yet sufficiently defined requirements.
Have we thought about what happens when things do not go according to plan?
Most requirements workshops describe the happy path.
The user submits the form. The integration works. The approval arrives. The transaction completes.
Real systems do not work like that.
What happens if mandatory information is missing?
What if the ERP or CRM integration is unavailable?
What if an API returns an error?
What if approval never arrives?
What if the user does not have the right permissions?
What if the same request has already been submitted?
One of the simplest techniques I like comes from the thinking behind Gojko Adzic’s Specification by Example:
“Show me an example.”
And then immediately:
“Now show me an example where it should not work.”
The second question is often more revealing than the first.
Are the non-functional requirements really requirements?
“Secure.”
“Scalable.”
“GDPR compliant.”
“Highly available.”
These are important statements, but they do not tell an architect or vendor enough.
In IT projects, some of the most important requirements sit here:
performance, availability, recoverability, auditability, identity and access management, data retention, accessibility, integration behaviour and security.
These requirements often have a direct impact on architecture, effort and cost.
So they need to be specific enough to influence design and eventually be verified.
Could a delivery team estimate this without inventing too much?
This is probably one of my favourite tests.
Give the requirements package to an experienced architect, delivery lead or vendor and ask:
“What do you still need to assume before you can estimate this?”
Every important assumption is a signal.
Maybe a requirement is missing.
Maybe an integration has not been understood.
Maybe data volumes are unknown.
Maybe a security constraint has not been captured.
Maybe the business has not decided what should happen in an exception case.
And when three vendors return very different estimates, it is not always because one is expensive and another is cheap.
Sometimes they are simply pricing three different interpretations of the same project.
Do we know where the requirements came from?
This matters more and more now that AI is entering the process.
Was a requirement explicitly stated by a stakeholder?
Was it derived from an existing process, policy or architecture document?
Was it inferred from another requirement?
Was it suggested by a subject matter expert?
Was it generated by AI and still waiting for validation?
I think this distinction is becoming essential.
The worst possible use of AI in requirements engineering is to generate hundreds of polished requirements that look professional but have no clear connection to what the organisation actually needs.
The better use is to combine stakeholder input, organisational knowledge and structured AI reasoning, while keeping sources, assumptions and validation visible.
And what happens when requirements change?
Because they will.
Business priorities change. Regulation changes. Users learn more. New systems and dependencies appear. New technologies create different options.
Good requirements management is not about pretending that requirements can be frozen forever.
It is about managing change without losing control.
Whenever a new requirement appears, I would ask:
Why has it appeared? What does it affect? Does it contradict anything already agreed? And who decides whether it enters scope?
I like the phrase:
Requirements should be baselined, not fossilised.
A good requirements environment should preserve the history of the need: where it came from, how it changed, why it changed and what else is affected.
So how can you actually test whether the requirements are good enough?
This does not need to become an academic quality exercise.
In practice, I would use five simple tests.
1. Pick a 5% or 10% sample from the requirements package and ask: “Why does this exist?”
If you cannot connect them to a business need, process, risk, user outcome or compliance requirement, challenge them.
2. Give the same requirement to two people and ask what they think it means.
If you get two materially different answers, you probably have an ambiguity problem.
3. Ask: “How will we know this requirement has been met?”
If nobody can explain how it will be demonstrated or accepted, it is probably not yet ready for delivery.
4. Give the package to someone who has to estimate it and ask: “What do you still need to assume?”
This is one of the fastest ways to expose missing integrations, data requirements, dependencies, constraints and business decisions.
5. Pick one requirement that changed recently and ask: “Why did it change, what else does it affect, and who approved it?”
If you cannot answer those questions, the problem is not that requirements are changing.
The problem is that change is not being managed.
None of these tests requires a complex methodology.
They simply force you to look at requirements from the perspective of the people who will actually have to design, estimate, build, test or procure the solution.
So what is the real quality test?
For me, it comes down to this:
Can the next person act on the requirements without having to rediscover the project?
That next person could be an internal product or engineering team, an implementation partner, a system integrator or a vendor preparing an RFP response.
This is also the thinking behind Fungy.ai.
The point is not just to generate requirements faster.
It is to combine stakeholder input, existing organisational knowledge and AI support into something structured, traceable and usable by the people who need to act next.
Because a requirements package can look complete and still leave enormous uncertainty behind.
And in IT projects, that uncertainty usually reappears later as assumptions, change requests, delays and cost.
Further reading
- Karl Wiegers & Joy Beatty — Software Requirements, 3rd Edition
- Suzanne Robertson & James Robertson — Mastering the Requirements Process / Volere Requirements
- Gojko Adzic — Specification by Example: How Successful Teams Deliver the Right Software
- ISO/IEC/IEEE 29148:2018 — Systems and Software Engineering — Life Cycle Processes — Requirements Engineering
- IIBA — A Guide to the Business Analysis Body of Knowledge (BABOK® Guide)