SurfingBearHome › Blog › Writing a requirements document
Writing requirements a vendor can actually quote against
When quotes vary wildly between vendors, the cause is usually not the vendors but the requirements document. If two people read the same document and picture different scope, they will price it differently.
6 required sections Common omissions Reducing quote variance
The short answer
The purpose of a requirements document is not to explain what you want. It is to make every reader picture the same scope. That distinction accounts for most of the variance in quotes.
So a good document is not characterised by rich description but by clear boundaries — what is in and what is out, where the data comes from, and what counts as done.
The six required sections
The five omissions that move a quote most
| Omitted | What happens to the price |
|---|---|
| Non-functional requirements (concurrency, response time) | The vendor assumes something, then rework follows a performance problem |
| Scope of data migration | Migrating existing data arrives as a separate quote |
| Support and maintenance period | Post-delivery response is not in the contract, so every fix is billable |
| Acceptance process and window | Acceptance drags and the final payment date becomes unclear |
| Explicit exclusions | Something you expected is handled as "out of scope" |
Writing what is excluded matters more than what is included
Give the document its own "not in this scope" section. New design work, cleaning up existing data, a mobile app, multiple languages, building a new external system — those are the usual candidates.
Two things improve when that section exists. Quote variance narrows, and mid-project disputes over "we assumed that was obviously included" become rarer. Those disputes almost never come from bad faith; they come from different default assumptions.
And attach a timing note to each exclusion: "out of this phase, to be reviewed in phase two". Permanently excluded and deferred are different, and they change the vendor’s design decisions.
Where AI helps here
It is well suited to structuring the draft. Have it generate the question list that fills the six sections, then organise the answers. That is fast.
Letting it invent the feature list is the risky part. Features nobody needs end up on the list, get priced, and increase the cost. Features are decided by people who know the work.
The definition of done also has to come from a person. Checkable numbers come from your current volumes, and those numbers live outside the document.
Frequently asked questions
Must every requirement be settled before starting?
Not every one. But the must-have features, the exclusions and the definition of done are worth fixing. If those three move, schedule and cost keep moving with them.
Is a longer document better?
No. Since the goal is that every reader pictures the same scope, a short document with sharp boundaries beats a long vague one. Clear data, integration and done criteria produce more accurate quotes than lots of screen description.
Our quotes vary by a factor of three.
That is usually a signal that scope is open in the document. Add priorities, exclusions and whether the integration targets have APIs, then re-request — the spread narrows sharply.
Is an RFP the same as a requirements document?
An RFP requests proposals and carries company background, timeline, evaluation criteria and contract terms. The requirements document is the part inside it that says what is being built.
Draft the RFP
Get your requirements into document form
The RFP generator drafts a request document covering background, features, data and acceptance criteria. Free, no sign-up.