A website requirements document is a numbered list of what the finished site must do, written so each line can be tested and signed off. It sits between the brief and the build: the brief says what you want and why, and the requirements document says exactly what "done" means.

Copy the template below, then look at the filled-in example for a fictional dental practice.

Brief or requirements document?

	Web design brief	Requirements document
Purpose	Direction and goals	Testable scope
Written by	Client	Agency with client
Language	Descriptive	"Must" statements
Used for	Starting design	Build, QA and sign-off

If you do not have a brief yet, start with how to write a web design brief. The requirements document comes next, in week 2 of our 12-week website project plan.

How to write a requirement you can test

Every requirement needs four things: an ID, a priority, one statement of behaviour and the test that proves it.

Vague	Testable
Fast website	LCP within 2.5s on mobile
Accessible	Meets WCAG 2.2 AA
Easy to update	Editor adds a page without code
Modern design	Matches signed-off design v3
Good contact form	Enquiry reaches inbox in 1 minute
Mobile friendly	No sideways scroll at 320px wide

The left column causes arguments at sign-off. The right column gets a pass or a fail.

Use MoSCoW for priority: Must, Should, Could, Won't. Keep Must for things the site cannot launch without, and treat Should and Could as the room you have when time runs short. Won't is the most useful of the four, because writing "Won't: online payments" ends a conversation you would otherwise have in week 10.

Keep the statement about behaviour and leave the method to the team. "Show customer reviews on the homepage" is a requirement. "Use a carousel plugin" is a design decision that has been slipped in early.

Website requirements document template

Copy this into a document and fill in the brackets. Delete any section that does not apply.

WEBSITE REQUIREMENTS DOCUMENTProject: [Site name]Client: [Company]Agency: [Company]Version: [1.0] Date: [date]Document owner: [Name]1. GOALSWhy this site exists: [one sentence]Success measures: [measure, baseline, target, date]2. USERS AND TASKSPrimary users: [who they are]Top tasks: [the 1 to 3 things they come to do]3. SCOPEIn scope: [pages and features]Out of scope: [what is not included]Phase 2: [deferred items]4. FUNCTIONAL REQUIREMENTSID | Priority | Requirement | TestF1 | Must | [what the site must do] | [how we prove it]F2 | Should | [ ] | [ ]5. DESIGN REQUIREMENTSD1 | Must | Follows brand guide version [x] | [ ]D2 | Must | Mobile and desktop for every template | [ ]D3 | Must | Hover, focus, error and empty states | [ ]6. CONTENT REQUIREMENTSC1 | Must | Copy for [pages] supplied by [date] | [ ]C2 | Must | Images at [size] with usage rights | [ ]7. TECHNICAL AND QUALITY REQUIREMENTST1 | Must | Supported browsers: [list] | [ ]T2 | Must | Core Web Vitals targets: [values] | [ ]T3 | Must | Accessibility level: [standard] | [ ]T4 | Must | Hosting and backups: [details] | [ ]8. INTEGRATIONSI1 | Must | [System, data, direction] | [ ]9. SEO AND LEGALL1 | Must | Consent before non-essential cookies | [ ]L2 | Must | Privacy policy supplied by [name] | [ ]L3 | Must | 301 redirects for all changed URLs | [ ]10. ASSUMPTIONS AND DEPENDENCIESA1 [What must be true for this plan to work]11. SIGN-OFFClient sponsor: [Name] Signed: [ ] Date: [ ]Agency lead: [Name] Signed: [ ] Date: [ ]

Save countless hours on your projects

Raise tasks in under 3 seconds using our revolutionary widget

Filled-in example: Harbour Dental

Harbour Dental is a made-up two-surgery practice replacing an 8-page brochure site. Everything below is invented to show the format.

Goal: Increase new patient enquiries from the website, from 30 a month to 45 a month within 90 days of launch.

Primary users: Local adults looking for a dentist and existing patients checking opening times.

Top tasks: Find a treatment and its price, request an appointment, find opening hours and parking.

Out of scope: Online payments, patient portal and live chat.

ID	Priority	Requirement	Test
F1	Must	Appointment request form	Reaches reception in 1 minute
F2	Must	Treatment pages show prices	Match current price list
F3	Must	Tap-to-call phone number	Opens dialler on a phone
F4	Should	Filter team by treatment	Shows the right dentists
F5	Could	Google reviews feed	Reviews display and link out
F6	Won't	Online payments	Moved to phase 2
D1	Must	Follows 2026 brand guide	Designer checks against guide
D2	Must	Mobile and desktop templates	Signed-off Figma file
C1	Must	Copy for 8 pages by week 6	Received by content owner
C2	Must	Team photos with permission	Consent forms on file
T1	Must	Latest two Chrome, Safari, Edge	Pass on test matrix
T2	Must	LCP within 2.5s on mobile	PageSpeed on 3 key pages
T3	Must	WCAG 2.2 AA	Easy Checks plus an audit
T4	Must	Daily backups kept 30 days	Restore tested before launch
I1	Must	Form copies to practice CRM	Test lead appears in CRM
L1	Must	Consent before analytics	No tags fire before opt-in
L2	Must	Privacy policy page	Supplied by practice manager
L3	Must	301s for all old URLs	Crawl of redirect map passes

Assumptions: The practice supplies CRM API access by week 4. Prices are confirmed by the practice manager before content entry.

Where the numbers come from

Pick standards you can point at, because they stop debates about what "fast" or "accessible" means.

Speed:Core Web Vitals give clear targets: LCP within 2.5 seconds, INP of 200ms or less and CLS of 0.1 or less.
Accessibility: WCAG 2.2 AA is a common target, and UK public sector sites must meet it and publish an accessibility statement. Our WCAG compliance guide explains the principles.
Cookies: The ICO's guidance says you need consent before setting non-essential cookies, so write that as a testable line.

Common mistakes

Everything is a Must. If nothing can be dropped, the team has no room when time runs out.
No out-of-scope list. Whatever is not ruled out will be assumed.
Ownerless content. A line that says "copy to be supplied" with no name or date is how launches end up late.
Skipping quality requirements. Speed, accessibility and browser support are the first things to be disputed if they are not written down.
No version control. Number each version and sign one. Everyone should be testing against the same document.

Using it at sign-off and UAT

Each test in the document becomes a test case. The UAT test plan template gives you a format for running them, and any failure is raised against its requirement ID.

If you log issues in a website feedback tool such as QualityHive, put the ID in the task description, for example "F1: form does not reach reception". The board then shows you which requirements still fail.

Changes after sign-off get a new ID, a priority and a cost. That keeps the original scope intact and makes each addition a visible decision.

Revolutionise your QA processes

FAQ

What are the requirements for a website design?

At a minimum: brand rules to follow, layouts for each template on mobile and desktop, interaction states such as hover, focus and error, accessibility targets, and the real content the design must hold. Write each one so a reviewer can pass or fail it.

Who should write a website requirements document?

The agency or project lead usually writes it, working with the client. The client sponsor and the agency lead both sign it, so neither side can say later that it was not agreed.

How long should a website requirements document be?

Long enough to cover each page type, function and quality target. For a small marketing site that is often 3 to 6 pages. A longer document that nobody reads protects no one.