Write evidence-led requirements
A long feature list makes almost every product look plausible. A short, prioritised requirements sheet makes it clear which conditions are essential, what evidence would prove them and who can accept a trade-off.
Write requirements as observable outcomes with an importance, owner, evidence source and decision rule. Include users, workflow, integrations, data, accessibility, security, support, pricing, implementation and exit. Mark a condition as non-negotiable only when failure cannot be accepted or safely mitigated.
Use a requirements sheet that can decide
- Outcome and workflow: the job, handover and success measure.
- Users: roles, access needs, training capacity and administrator ownership.
- Information: data types, records, imports, exports, retention and quality needs.
- Connections: sign-in, devices, integrations, formats, network and fallback.
- Controls: permissions, audit needs, recovery, configuration and review responsibility.
- Commercial terms: seats, usage, implementation, support, renewal and cancellation.
- Adoption: rollout, migration, help, change communication and measurement.
- Exit: data export, offboarding, transfer, deletion and continuity plan.
Give every requirement a decision rule
| Requirement | Importance | Evidence | Decision rule |
|---|---|---|---|
| Named users can complete a critical task. | Non-negotiable | Representative trial task. | Fail if a risky workaround is needed. |
| Important records can be exported. | Non-negotiable | Current documentation and sample export. | Fail if records cannot be recovered in a usable format. |
| Dashboard is configurable. | Preference | Demonstration or trial. | Score only after red lines are met. |
Do not score unknowns as strengths
“We think it can do that” is not evidence. Keep unverified claims separate from confirmed evidence and decide whether the uncertainty is material enough to test, contract for or reject.
Software requirements FAQs
How many requirements should we have?
Enough to protect the real decision, but few enough to use. Start with the critical workflow, red lines and a limited set of weighted preferences. Remove duplicates and vague aspirations.
What makes a requirement testable?
It states who must do what, under which conditions, what proof is needed and what result is acceptable. “Easy to use” becomes a real task completed by a representative person.
Should we include future needs?
Yes, where they are credible and material. Label them separately from today’s must-haves so a speculative roadmap does not overrule a current critical need.
Continue the software decision
Keep the workflow, evidence, people and exit route visible until the decision is made. The next useful step is usually the one that reduces the uncertainty most likely to cause expensive rework later.
