Why write requirements first
Once you have seen a polished product, it is hard to ignore it. Features you never asked for start to seem essential, and gaps you would have caught become easy to overlook. Writing requirements before vendor conversations fixes the yardstick in advance. It also gives every supplier the same brief, which makes their answers comparable, and it gives your own team something to point to when opinions differ.
A requirements list does not need to be long or formal. It needs to be clear, agreed by the people affected, and specific enough to check.
Start from the work, not the features
Begin by describing what people need to get done and what is going wrong today. Talk to the people who do the work: observe a task being performed, ask where it slows down, find out what workarounds exist. Many requirements only surface this way, such as the spreadsheet someone maintains on the side to fill a gap in the current tool.
Cover a range of voices. Daily users, administrators, managers who need reports, and colleagues in finance, security or legal each see different needs. A brief stakeholder mapping exercise helps you remember who to ask. If people from several sites or departments use the process, be aware that they may describe it differently; the question of what to standardize and what to leave local is considered under multi-site operations.
Group the requirements
Sorting requirements into categories makes gaps easier to spot:
- Functional: what the tool must do, such as route a request for approval.
- Data: what information it holds, what it imports and exports, how long it keeps it.
- Integration: which systems it must connect to.
- Users and access: who can see and change what.
- Reporting: which outputs people need.
- Non-functional: performance, availability, accessibility, usability, support.
- Commercial and vendor: contract flexibility, data ownership, exit conditions.
- Security and compliance: general expectations to be defined with your specialists.
For security and compliance, involve qualified people early; this guide gives general information and not professional advice.
Separate must-haves from nice-to-haves
Without discipline, every requirement becomes essential. A simple, widely used way to sort them is into three groups:
- Must have. Without it the tool is unusable or unacceptable. Failing a must-have removes an option from consideration.
- Should have. Important and valuable, but there may be workarounds.
- Could have. Pleasant extras that should not drive the decision.
A useful test is to ask: “If a product lacked this, would we still use it?” If the answer is yes, it is not a must-have. Keep the must-haves to a small number. A list in which most items are must-haves is not telling you anything, and will eliminate everything, or nothing.
Record the reason for each must-have. A requirement with no reason attached is often a preference or a habit carried over from the old system. The question to ask is what the requirement is for, since the purpose can sometimes be met in a different way.
Make each requirement testable
A testable requirement is one where two people could look at a product and agree whether it is met. Compare these:
-
Vague: “The system should be fast.”
-
Testable: “A standard search across our full record set returns results in a few seconds during the trial, on ordinary office computers.” (Agree the specific threshold with your own users.)
-
Vague: “Easy to use.”
-
Testable: “A new user can submit a standard request without help after a short introduction, observed in the trial.”
-
Vague: “Good reporting.”
-
Testable: “Managers can produce the monthly summary of open requests by team without technical help.”
-
Vague: “Integrates with our systems.”
-
Testable: “Approved invoices pass automatically to the accounting system each day, with totals matching.”
Good wording usually names who is doing what, in what situation, with what observable result. Where a number is needed, base it on your own measurements. Recording how things work today, a practice discussed under performance baseline, gives you realistic targets.
Describe the need, not the solution
Avoid specifying a particular technology or screen layout unless it is truly mandatory. “Users can sign in with their existing company login” describes a need; naming a particular implementation can rule out products that would meet it differently. Leaving room lets suppliers propose better approaches, and keeps you from copying the weaknesses of your current tool.
Review, agree and keep it stable
Circulate a draft to the people who contributed and ask them to find omissions and contradictions. Agree the final list with the decision owner, then version it. Changes after vendors have seen the list are sometimes necessary, but they should be conscious and recorded, because shifting requirements midway can favour whichever product happens to match the new wording.
Share the same document with every shortlisted vendor and ask them to respond requirement by requirement, indicating whether each is met out of the box, met through configuration, requires custom work, or is not met. Treat claims as claims until tested, a point developed under software pilot and the neutral evaluation process as a whole.
Keep it proportionate
A small purchase may need one page. A large cross-department system may need a fuller document, with workshops and sign-off. What matters is that the list exists before the sales conversations, that it separates the essential from the desirable, and that it can be used later as the basis for scoring and for testing. Review it again after the purchase to see which requirements proved important, so the next list is better.