How to Write a Website Requirements Document
A requirements document exists so that you and the developer are describing the same website. It does not have to be long. A four-page brief that both sides have actually read prevents more disputes than a fifty-page specification that neither has finished.
This guide covers what belongs in it, what to leave out, and how to write the section that matters most: what the project is not.
What a requirements document is for#
It has three jobs: let several developers quote the same thing so the quotes are comparable, give you a reference when there is a disagreement about scope, and force you to make decisions while they are still cheap.
It is not a design brief, and it is not a technical specification. Saying "the site must load quickly" is a requirement; saying "use Redis for object caching" is a solution, and choosing it before you have hired anyone removes the expertise you are paying for.
- State outcomes and constraints, not implementations.
- Write it so someone outside your organisation can understand it without a call.
- Keep it short enough that it is read in one sitting — four to eight pages is plenty for most sites.
- Date it and version it, because it will change.
The sections worth including#
This structure covers most website development projects. Skip anything that does not apply rather than padding it out.
| Section | What goes in it |
|---|---|
| Background | What the organisation does and why the site is being built or replaced |
| Goals | The primary goal, secondary goals, and how success is measured |
| Audience | Two or three visitor groups and the question each arrives with |
| Page structure | Every page, grouped into sections, marked launch-critical or later |
| Functional requirements | Forms, search, accounts, filtering, booking, checkout — what each must do |
| Integrations | Every external system, with a named contact and API documentation link |
| Content | Who writes each page, who approves it, when it is due |
| Non-functional | Performance, accessibility, browser and device support, languages, security |
| Out of scope | Explicitly excluded work — the most valuable section |
| Constraints | Budget range, deadline and any fixed decision (existing host, mandated CMS) |
Write requirements you can test#
A requirement is useful when both sides can agree afterwards whether it was met. "The site should be fast" cannot be tested; "the product listing page reaches Largest Contentful Paint under 2.5 seconds on a mid-range Android over 4G" can.
The same applies to functionality. "A contact form" leaves out every question that matters.
| Vague | Testable |
|---|---|
| A contact form | Six fields, spam protection, stores to database, emails two addresses, GDPR consent line |
| Mobile friendly | Usable at 320px, all touch targets at least 44px, no horizontal scroll |
| Fast | LCP under 2.5s and CLS under 0.1 on the four main templates, measured on 4G |
| Accessible | WCAG 2.2 AA on templates, verified with keyboard-only and screen-reader passes |
| SEO friendly | Editable titles and descriptions, clean URLs, sitemap, structured data on articles |
| Multilingual | Three languages, translated URLs, hreflang tags, language switcher on every page |
The out-of-scope list#
This is the section people skip and the one that saves the project. Write down the things a reasonable person might assume are included, and say plainly that they are not — or move them in, if they should be.
Doing this before quotes arrive means the quotes are comparable. Doing it afterwards means an argument.
- Content writing and proofreading — assume it is yours unless the quote says otherwise.
- Photography, illustration and stock licences.
- Content entry: who types 200 products into the CMS?
- Email setup, DNS migration and hosting account transfer.
- Ongoing SEO work as distinct from technical SEO setup at launch.
- Training, documentation and handover.
- Post-launch support: what is covered, for how long, and what is billable.
A good developer will add to this list unprompted. One who agrees to everything without questions has usually not read it, and the disagreement is simply deferred.
Frequently asked questions
How long should a requirements document be?
Four to eight pages covers most business websites. Stores and applications run longer because the functional section grows, but if it passes twenty pages ask what is being described that a conversation could not settle. The measure is whether both sides have read it, not whether it is comprehensive.
Should I specify the technology?
Only where you have a genuine constraint: an existing CMS your team knows, a host you must stay on, a system that must be integrated. Otherwise state the outcome and let the people you are hiring choose the implementation. Specifying a stack you do not understand narrows your options and gives you a worse answer.
Do I need wireframes as well?
Low-fidelity wireframes for the three or four most important templates remove a lot of ambiguity for very little effort, and they are far cheaper to change than a design. They are not a substitute for the written requirements — they show arrangement, not behaviour — but the two together price much more accurately than either alone.
What if I do not know some of the answers?
Write "to be decided" and name who decides and by when. An honest gap with an owner is fine; an invented answer is not, because the quote will be built on it. Developers price uncertainty either way, so making the uncertainty visible usually gets you a better number than hiding it.
website requirements documentwebsite briefwebsite specificationwebsite rfpwebsite scope of workweb development requirements
