Free template · No signup
Website Requirements Document Template
The client asked for 'a simple site with booking', and everyone in the kickoff pictured a different one. A website requirements document writes down what the site must do before anyone designs it, with a priority and an acceptance check for every requirement. Fill in the template below or start from the completed example.
Copy as Markdown or download Word. Your draft stays in this browser.
Editable document · 4 sections · 17 fields
Write your website requirements
Your draft stays in this browser. Copy or download it to share.
Use the document with any project tool. The example is illustrative, so replace its details and targets with ones your client has agreed.
Completed example
A website requirements document example
Larch Physio is an illustrative three-clinic practice redesigning its site. The names, dates and targets are examples.
Select “Fill with example” in the form to adapt it and include your changes in the Word or Markdown export.
- Project, version and date
- Example. Larch Physio website redesign, requirements v1.2, week 2 of the project
- Purpose and background
- Larch Physio runs three clinics. New patients can only book by phone, and the clinic pages show out-of-date opening hours. The redesign moves booking online and gives each clinic a page the front desk can keep current.
- Goals and success measures
- 1. Make online booking the main way new patients book. Compare booking completions per month with the three months before launch, reviewed 90 days after launch. 2. Reduce phone calls asking for opening hours and directions. The front desk keeps a tally for four weeks before and after launch.
- Audiences and their top tasks
- New patients with an injury. Find the nearest clinic, check the treatment is offered and book a first appointment. Returning patients. Rebook with the same physiotherapist. Referring doctors and insurers. Find referral details and the right clinic contact.
- Stakeholders and final approver
- Sam, agency project lead, owns this document. The three clinic managers and the front desk lead give input. Alex, practice director, is the final approver. Names and project are illustrative.
- In scope and out of scope
- In scope. Redesign of the main pages and their templates, online booking through the practice's existing booking system, three clinic pages, physiotherapist profiles, and migration of the current blog articles. Out of scope. A patient portal, online payment, new photography, copy for new blog articles and a new logo.
- Sitemap and page templates
- Home Services, one page per treatment Clinics, one page per clinic Team, profiles filtered by clinic and specialty Book Blog, article template plus the migrated articles About, Contact, Privacy Redirects. Every /locations/ page moves to /clinics/ with a 301 to its new page.
- Content, assets and migration
- The agency copywriter rewrites the service pages and the clinic managers check them for accuracy, due week 4. The practice supplies team photos and bios, due week 3. Blog articles move unchanged, with their titles and URLs kept.
- Brand, design and references
- Keep the current logo and brand colors from the brand guide. The client likes competitor sites where the booking button stays visible on every page. Avoid stock photography of people in suits.
- Functional requirements
- R1 · Must · A visitor can book a first appointment at any clinic from every service and clinic page. Accepted when a test booking reaches the booking system and the visitor receives a confirmation email. R2 · Must · Each clinic page shows the address, opening hours, a map and parking notes, and a clinic manager can edit them without a developer. Accepted when a clinic manager updates opening hours on staging unaided. R3 · Should · Visitors can filter physiotherapists by clinic and specialty. Accepted when every filter combination returns the right profiles. R4 · Could · Blog articles can be tagged by condition. Accepted when a tag page lists every tagged article. R5 · Won't this phase · Online payment for appointments. Moved to the phase two list.
- Performance, accessibility and security
- Largest Contentful Paint under 2.5 seconds on key pages, tested on a mid-range phone. WCAG 2.2 AA, checked on the booking flow and the clinic pages. Current versions of Safari, Chrome, Edge and Firefox, on iOS, Android and desktop. Booking details go only to the booking system, over HTTPS.
- Platform, integrations and maintenance
- WordPress on the current host. Booking runs through the practice's existing booking system, embedded or linked, decided in week 2. Analytics stays on the current property. The practice edits content after launch and the agency handles updates under a support agreement.
- SEO, analytics and tracking
- Keep the URLs of the service and clinic pages that bring new-patient searches today, or 301 them. Keep blog URLs unchanged. Track booking starts and booking completions as analytics events.
- Budget, dates and constraints
- Budget as agreed in the proposal. Launch before the third clinic's opening day, with the old site kept restorable for two weeks after launch. No patient health information is collected on the website.
- Review, acceptance and changes
- Design review on mockups, one consolidated round, three working days. Build review on staging, with comments pinned to the page and the requirement ID in each comment, three working days and one retest round. Accepted when every Must requirement passes its check on staging and Alex records acceptance. New requests go to the phase two list, or become a change request with its own estimate.
- Assumptions and open questions
- Assumption. The booking system allows embedding on the site. Morgan, developer, confirms by Friday of week 2. Open. Will each clinic manager edit their own page? Alex answers by Friday of week 1.
- Approval
- Alex, practice director, approved v1.2 on Friday of week 2.
How to write a website requirements document
01
Start with the purpose and the approver
Agree on why before you list what.
Everyone agrees why the site exists, who it serves and who makes the final call.
- Write the purpose in plain language, including what the current site gets wrong.
- Set two or three goals, each with a measure and a review date.
- List the stakeholders who give input and name one final approver.
Done whenThe approver agrees with the purpose, the goals and their role.
02
Define the scope, pages and content
What is out of scope matters as much as what is in.
The team and the client share one list of pages and one list of exclusions.
- List every page or repeating template, then write the exclusions just as clearly.
- Name who writes, supplies and approves each piece of content, with due dates.
- For a redesign, list the old URLs that move and the page each one redirects to.
Done whenThe client has read and accepted the page list and the exclusions.
03
Write requirements someone can test
If you cannot check it, it is a wish.
Every requirement says what the site must do and how anyone can confirm it does.
- Give each requirement an ID, a priority of Must, Should, Could or Won't this phase, and an accepted-when check.
- Describe what the site must do, not how to build it. 'Visitors can book online' leaves the team free to pick the right tool.
- Set performance, accessibility, browser and security targets as numbers or named standards, such as WCAG 2.2 AA.
Done whenEvery Must requirement has a check someone can run on staging.
04
Agree how the build will be reviewed and accepted
Decide what done means before the build exists.
The client knows where to give feedback, by when, and what counts as accepted.
- Agree where feedback is given, the review deadline and how many rounds are included.
- Define accepted as every Must requirement passing its check on the staging site.
- Agree how new requests are handled, as a change request with its own estimate or a phase two item.
Done whenThe review process, the acceptance rule and the change process are written into the document.
05
Approve the document and keep it current
One approved version, then changes on the record.
The team builds from an approved version, and every later change is visible.
- Send the document to the approver and record the version and date they approved.
- Log every later change with its date, its reason and its effect on budget or dates.
- Carry the requirement IDs into QA and bug reports, so each expected result points to an approved requirement.
Done whenAn approved version, a change log, and requirement IDs the QA pass can test against.
From requirement to test to bug report
Give a requirement an ID once and it works for the rest of the project. R1 in the example becomes a test in the QA pass, and if the test fails, the bug report's expected result points back to R1. Nobody has to argue about what the site was supposed to do.
| In the requirements document | In the QA pass | In the bug report |
|---|---|---|
| R1 · Must · A visitor can book a first appointment from every service and clinic page. Accepted when a test booking reaches the booking system and sends a confirmation email. | Book a test appointment from each service and clinic page on the browsers in the quality section. | Expected result. The booking reaches the booking system and a confirmation email arrives, as R1 requires. |
Use the website QA checklist to run the pass, the bug report template to report a failed check, and the website redesign checklist when the project replaces an existing site.
Trusted by 600+ agencies, freelancers, and enterprises
Trusted by Agencies,
Loved by Clients
See why web professionals call Simple Commenter the best website feedback tool, and never look back.
/ Rated 5.0 on Product Hunt & 4.8 on G2
Simple. Effective. Game Changer
@Dsouldiva
Finally, a feedback tool my clients actually enjoy
@craigfenton
A Game-Changer for Web Feedback – Worth Every Penny!
@ryanbarilla
The tool I've been searching for
@alexs89
Simple, yet ingenious
@koen.kerkvliet
Great feedback app and so easy to use!
@iamvictor
Hidden Gem
@greg319
Fantastic tool for working with clients
@devdbydesign
An Essential Tool for Enhancing Communication with Clients
@Fiorenzomi
Great product!
@gramir
Very useful product and excellent support
@Ulrich86098
Simple Commenter has changed the way I work
@Jim Langman
Deserves +1000 tacos
@IgnacioJadue
Clients LOVED using Simple Commenter
@Katelyn
Phantastic
@user6961b
They fixed my issue in literal seconds from emailing them
@100587018771155070259
Super handy tool. The developer is very responsive.
@neposeda
I didn't realize how much I needed this tool!
@koen.kerkvliet
Life changed in under 5 minutes
@Dsouldiva
My clients have been engaged like never before
@Jim Langman
Simple. Effective. Game Changer
@Dsouldiva
Finally, a feedback tool my clients actually enjoy
@craigfenton
A Game-Changer for Web Feedback – Worth Every Penny!
@ryanbarilla
The tool I've been searching for
@alexs89
Simple, yet ingenious
@koen.kerkvliet
Great feedback app and so easy to use!
@iamvictor
Hidden Gem
@greg319
Fantastic tool for working with clients
@devdbydesign
An Essential Tool for Enhancing Communication with Clients
@Fiorenzomi
Great product!
@gramir
Very useful product and excellent support
@Ulrich86098
Simple Commenter has changed the way I work
@Jim Langman
Deserves +1000 tacos
@IgnacioJadue
Clients LOVED using Simple Commenter
@Katelyn
Phantastic
@user6961b
They fixed my issue in literal seconds from emailing them
@100587018771155070259
Super handy tool. The developer is very responsive.
@neposeda
I didn't realize how much I needed this tool!
@koen.kerkvliet
Life changed in under 5 minutes
@Dsouldiva
My clients have been engaged like never before
@Jim Langman
FAQ
Questions people ask before they try it
Something missing? Email info@simplecommenter.com and you’ll get an answer from the person who built it.
- What is a website requirements document?
- A website requirements document records what a website must do, who it is for and how the team will know it is done, agreed before design starts. It covers the purpose and goals, audiences, scope, pages, functional and technical requirements, and how the finished build will be reviewed and approved. It is the reference everyone checks when a request turns up mid-project.
- What should be included in a website requirements document?
- Include the purpose and goals with measures, the audiences and their top tasks, stakeholders and one final approver, what is in and out of scope, the sitemap and content owners, functional requirements, performance, accessibility and security targets, the platform and integrations, SEO and tracking needs, budget and dates, and the review and acceptance process. End with open questions and a recorded approval.
- What is the difference between functional and non-functional requirements for a website?
- Functional requirements describe what the site does, such as letting a visitor book an appointment, filter a team page or submit a form. Non-functional requirements describe how well it does it, such as load time, accessibility level, browser support and security. Both need a check. 'The site is fast' is a wish, while 'Largest Contentful Paint under 2.5 seconds on key pages' can be tested.
- How detailed should a website requirements document be?
- Detailed enough that every Must requirement has a check someone can run, and short enough that the approver actually reads it. Describe outcomes, not implementation. If a section has no decision in it yet, list it under open questions with an owner and a date instead of guessing.
- Who writes the website requirements document?
- Usually the agency's project lead or strategist writes it, using input gathered from the client's stakeholders at kickoff. The fields on this page work as a requirements gathering template for that meeting. The developer checks that each requirement can be built and tested, and the client's named approver signs it off.
- How is a requirements document different from a project plan or a creative brief?
- The requirements document says what the site must do. The project plan says who does the work and when, and a creative brief sets the direction for the design and messaging. Agree on the requirements first, then schedule them in the project plan.
- Can requirements change after the document is approved?
- Yes, but on the record. Log each change with its date, reason and effect on budget or dates, and have the approver accept it as a new version. A change that skips the log turns into an argument at acceptance.
- Is this website requirements template free?
- Yes. Fill it in on this page, copy it as Markdown, or download a Word .docx without an email or account. Choose Fill with example to adapt the completed version, or start from an empty form. Your draft stays in this browser.
Check every requirement on the real build
Use the template to agree on what the site must do. When the staging site is ready, clients can comment on the page with Simple Commenter, without an account, and mention the requirement ID so each comment traces back to the document. Try it free for 14 days, no credit card needed.
No credit card required.
Schedule the work with the website project plan template, test against the requirements with the website QA checklist, and log anything that fails with the bug report template.