The short answer
A useful requirements document states the problem you are solving, what the system must do, what would be nice to have, the volumes and integrations involved, and how you will judge the answers. Keep it short enough that suppliers read it and specific enough that their answers can be compared.
What goes in a requirements document?
| Section | What it says |
|---|---|
| The problem | What isn’t working today and what has to change. One or two paragraphs. |
| Scope | Which teams, sites, countries and processes are included, and which aren’t. |
| Users and volumes | How many people will use it, how often, and the volumes involved: transactions, records, devices, locations. |
| Must-haves | Requirements that rule a supplier out if they can’t meet them. |
| Nice-to-haves | Things that would help but won’t decide the outcome on their own. |
| Integrations | The systems it has to connect to, and what data needs to flow in each direction. |
| Data and security | Where data may be stored, who can access it, and the certifications or reports you expect. |
| Support and service levels | Support hours, response times and availability you need. |
| Commercial basics | Budget range if you’re willing to share it, contract length and payment terms. |
| Timeline | When you need answers, when you’ll decide and when you need it live. |
| How you’ll judge | The criteria and weightings you’ll score answers against. |
How do you separate must-haves from nice-to-haves?
Use the MoSCoW method: mark each requirement as Must have, Should have, Could have or Won’t have this time. The test for a must-have is simple: would you reject a supplier that can’t do it? If not, it isn’t a must-have.
Agree the ranking with everyone involved before the document goes out. Arguing about priorities after the answers come back means arguing about suppliers, not requirements.
How detailed should it be?
Describe outcomes, not features. “Finance can close the month without re-keying invoices” tells a supplier more than “OCR invoice capture”, and it lets them propose a better way if they have one. Add detail where the answer has to be exact: volumes, integrations, data location and service levels.
What mistakes make answers hard to compare?
- Copying a supplier’s spec sheet. It tilts the process towards that supplier from the start.
- Leaving out volumes. Pricing and performance depend on them, so answers come back on different assumptions.
- Open questions with no format. Ask for answers in a set structure, or a table, so you can line them up.
- No weightings. Without them, the slickest presentation tends to win.
- Too long. A document nobody reads gets generic answers.
Should you send an RFI, an RFP or an RFQ?
- RFI (request for information) when you’re still building a longlist and want to understand the options.
- RFP (request for proposal) when you know your requirements and want suppliers to propose how they’d meet them, and at what price.
- RFQ (request for quotation) when the requirement is fixed and you’re comparing prices.
Many purchases don’t need a formal tender at all. A clear requirements document shared with three shortlisted suppliers often does the same job. Public bodies and some regulated firms have their own procurement rules, so check those first.
Not sure you’re ready to write it? The Asand benchmark scores how clearly your need is defined and tells you where to start.