Most software projects do not fail because of poor engineering.
They fail because they start with documents that describe what people want instead of what systems must survive.
In Kenya, requirements documents are often treated as a contractual formality rather than a thinking tool. The result is predictable misalignment, endless change requests, and systems that technically meet requirements but fail operationally.
This article explains why most requirements documents are useless, and what should replace them.
1. Requirements Describe Wishes, Not Constraints
Typical requirements documents focus on:
- Features
- Screens
- User flows
- Permissions
They rarely define:
- Failure conditions
- Load expectations
- Data ownership
- Regulatory exposure
- Long-term maintenance assumptions
Systems do not fail because features are missing.
They fail because constraints were never articulated.
2. Ambiguity Is Mistaken for Flexibility
Vague requirements are often defended as “flexibility.”
In reality, ambiguity:
- Pushes decisions downstream
- Transfers risk to engineering
- Creates false alignment
- Explodes cost later
Every unclear requirement is a delayed decision that someone else will pay for.
3. Requirements Ignore Time
Most documents assume the system exists at a single moment.
They do not describe:
- How the system evolves
- What happens when data doubles
- How regulations change
- What breaks first under stress
Software lives in time.
Requirements that ignore time are incomplete.
4. What Works Better Than Traditional Requirements
Successful teams replace rigid requirement documents with:
- Problem statements
- Decision maps
- Constraints lists
- Failure-mode discussions
- Ownership definitions
The goal is not completeness.
It is shared understanding of reality.
Final Thought
Good software is not built from exhaustive requirements.
It is built from clear constraints, explicit trade-offs, and disciplined thinking.
