A good software requirements list is not the longest list the team can assemble. It is the smallest set that explains which outcomes, workflows and controls must be protected—and gives every supplier the same observable test.
This guide shows how to turn user evidence into traceable requirements, remove duplicates and solution bias, and separate mandatory gates from preferences. The result is a list a buying team can demonstrate, score and maintain instead of a catalogue of features nobody can defend.
A requirement survives only when it has a real need, is necessary and distinct, and can be tested.
Start with evidence of work, not a blank requirements sheet
Interview and observe the roles that perform, approve and support the target work. Capture the trigger, starting information, decisions, hand-offs, exceptions and evidence of completion. Review incidents, rework, support requests and existing reports. GOV.UK's guidance on user needs similarly starts with who users are, what they are trying to do, how they work today and the barriers they face.
Translate the evidence into a need before naming a product function. “Users need to know whether a customer change has been approved before scheduling work” is a need. “Configurable dashboards” is a possible solution and should not enter the list until the team knows which decision the dashboard must support.
Use one traceability chain for every requirement
Each requirement should connect five elements:
- Need: the observed problem, outcome or control.
- Scenario: the role, starting state, action and exception.
- Requirement: the behavior or constraint the system must satisfy.
- Acceptance evidence: what a demonstration or test must show.
- Owner: who can accept the result and later approve a change.
Example: a finance approver needs to prevent duplicate reimbursement. In a scenario, the same receipt is submitted by two routes. The requirement is not “AI duplicate detection”; it is “the system shall flag a potential duplicate before approval using defined matching fields and show the reviewer why it matched.” The test submits known duplicate and non-duplicate examples and records the result.
Prune every candidate through four questions
Is there evidence of a real need?
Keep the observation, incident, policy or measurable outcome that created the item. If nobody can identify the source, remove the item or create a research task. Do not preserve it as mandatory because it appeared in an old tender.
Is it necessary?
Ask what fails if the item is absent. If the outcome can still be achieved safely through another design, the item may be a preference rather than a gate. “Must have the current spreadsheet's color coding” often becomes “users must distinguish blocked work from ready work,” leaving suppliers free to demonstrate a better method.
Is it distinct?
Combine requirements that describe the same decision in different vocabulary. Split statements that contain several independent tests. Avoid “and,” “fast,” “easy,” “flexible” and “user-friendly” unless the team defines observable conditions.
Can it pass or fail?
Specify representative starting data, user role, action, expected output and exception. If evaluators cannot agree what would pass, rewrite the requirement before sending it to suppliers. NASA's public systems-engineering handbook appendix likewise tests whether requirements are necessary, traceable and verifiable.
Cover seven areas without converting them into feature headings
| Area | Question to derive requirements |
|---|---|
| Outcome | What measurable business result must change? |
| Workflow | Which normal and exception paths must users complete? |
| Data | What must be created, validated, retained, reported, exported or removed? |
| Control | What access, approval, audit, security, privacy or accessibility boundary applies? |
| Integration | Which event and data cross each system boundary, including failures? |
| Operation | Who administers, supports, monitors and changes the service? |
| Exit | What must remain usable if the product is replaced? |
This coverage check finds omissions. It does not justify adding generic requirements in every area. An item exists only when the proposed use needs it.
Separate the shortlist gate from the scorecard
A mandatory requirement is a condition of viability: failing it removes or formally exceptions the product. A weighted preference compares viable options. Label each item before demonstrations. Do not let a strong score in optional automation compensate for a failed access-control, data-export or critical workflow requirement.
Keep the mandatory list short enough to test completely. Store detail as scenario data, evidence notes or implementation conditions rather than assigning equal scoring weight to every sentence.
Control changes without freezing learning
Requirements evolve as demonstrations and prototypes reveal constraints. GOV.UK's technology guidance recommends testing assumptions early and adapting as understanding changes. Version the list; record who changed an item, why, which evidence triggered the change and whether suppliers need an equal opportunity to respond.
Reject post-demo changes that merely make a favored product score better. Accept changes that correct an error, clarify an observable need or respond to new evidence—and rerun the affected comparison fairly.
The one-page requirement card
| Field | Example |
|---|---|
| ID and owner | FIN-07 / Accounts Payable owner |
| Need and source | Prevent duplicate reimbursement / incident sample |
| Scenario | Same receipt submitted through two channels |
| Requirement | Flag potential duplicate before approval and explain the match |
| Class | Mandatory control |
| Acceptance test | Known duplicate and non-duplicate dataset; reviewer sees matching fields |
| Status | Verified / gap / unknown, with evidence link |
If the team cannot complete these fields, the item is not ready to influence a purchase. Pruning is therefore not loss of rigor. It removes unsupported volume so the remaining requirements can receive deeper, comparable evidence.
Review the list with the people who will inherit it
Before issuing the requirements, run a ninety-minute challenge session with a frontline user, process owner, security or privacy representative, data owner and implementation lead. Give each participant one job: identify an unsupported assumption, an exception that the happy path ignores, a requirement that cannot be tested, or a dependency the buyer does not control. Do not use the meeting to add everyone's favourite feature.
End with three explicit lists: accepted requirements, rejected suggestions with reasons, and open questions with owners and deadlines. That separation matters. An unanswered question is not automatically mandatory, and a rejected request should not quietly return during a vendor demonstration.
Measure whether the requirements are ready
A list is ready for supplier evaluation when every mandatory item has an owner, source and observable acceptance test; every preference has a stated decision value; overlaps have been removed; and dependencies are visible. Sample ten requirements at random. If an evaluator cannot describe what evidence would earn a pass, rewrite the item before approaching vendors.
The practical target is not completeness in the abstract. It is decision coverage: enough evidence to rule out unsafe or unsuitable options, compare viable ones and plan the work that remains after selection.