Website requirements document: what it must settle before the first quote

The requirements document, sometimes called a brief or a specification, is the centrepiece of the Organisation area: the document that says what the site has to achieve, for whom and under what constraints. Written before you consult anyone, it sets the common ground every supplier answers on.

What it is for

First, it gets you website quotes you can compare, since every supplier answers the same text. During the project it becomes the reference: the supplier you choose knows what to deliver, and you can check that the delivery matches the request.

The approach has its standards. The European standard EN 16271 frames it as the search for an optimum between the need expressed and what will be supplied to meet it. For a heavier project, the international standard ISO/IEC/IEEE 29148 sets out what a well-formed requirement is and what information a specification should cover.

What it should contain

France Num, the French government’s programme to help small businesses go digital, lists several templates and recommends a seven-part structure:

• Context: who you are, what you sell, to whom, in which markets.
• The site’s objectives, in order of priority.
• Structure and features: the site map, meaning the plan of the pages, and what the site must let people do.
• The tools it has to work with: your customer relationship software (CRM), your management software (ERP), your booking tool, your newsletter. You don’t have to choose the site’s technology, but you do have to name these tools.
• The evaluation criteria, meaning what will count most in your choice.
• The expected deliverables, and the timetable for both the consultation and the project.
• An estimated budget, even a rough one, so suppliers can size their answer. The ranges published for website cost give you a first benchmark.

Add two points this structure leaves out: what must be in your name (domain name, hosting, accounts), and what you get back if you change supplier. That’s what a reversibility clause sets out, and the requirements document is the right place to demand one.

What a fill-in template won’t decide for you

Templates give you the headings. They don’t decide for you what matters most when everything won’t fit in the budget, or what can wait for a second version. A requirements document that lists everything at the same level leaves those trade-offs to the suppliers, and each one makes them differently.

Another guide from the same government programme advises separating the features you need at launch from the ones that can wait, because wanting everything at once is the main cause of budget overruns. The MoSCoW method, as the DSDM agile framework describes it, goes further: it puts in writing what won’t be done this time, which clarifies the scope and stops those requests from creeping back in later.

In a website project, the most expensive outcome is delivering something other than what you needed, and the requirements document is there to prevent it. In a 2014 Project Management Institute survey of 2,066 practitioners, poor requirements management was the main cause of almost half (47%) of the projects that missed their goals, and 5.1% of every dollar spent was wasted because of it. A NASA study of systems comparable to a spacecraft puts a number on the delay: a requirements error found once the system is in operation costs from 29 to more than 1,500 times what it would have cost while the requirements were being written.

Writing a requirements document with AI

AI saves a great deal of time on this document. Give it your rough notes, the minutes of a meeting or the map of your current site: it sorts them under the headings, rewrites what is vague and spots what is missing, such as a feature with no objective or a tool named without saying what it exchanges with the site.

A study presented at the 2025 IEEE International Requirements Engineering Conference, carried out in an IT consulting firm, bears this out: language models cut the time and effort it takes to write specifications, but the quality of the result depends on what they are given and often needs a human review. Another study, published in 2024 and based on a simple example (a university club management system), rates them at the level of an entry-level engineer.

What AI doesn’t know is what matters to your business. Ask it for a requirements document without giving it anything, and it will fill every heading with plausible answers: the document will describe an average site, and suppliers will price that average site. The CNIL, France’s data protection authority, points out that these systems can produce inaccurate results that still look plausible, which the US standards body NIST calls confabulations. Your priorities, what can wait for a second version and the budget you set remain your decisions. Reread every line and ask yourself whether a supplier could price it as it stands.

Check what you hand over to the tool as well. The guidance sheet the same authority published with France Num for small businesses is clear: nothing confidential, personal or strategic in a consumer tool, and the final decision stays with a person. ANSSI, the French national cybersecurity agency, lists a company’s contractual, legal or financial data among the data not to give consumer AI services, and a requirements document often contains some.

We work this way, and we built a tool to keep to it: notabene, released under an open-source licence. Reviewers annotate the document directly on the page, on the passage concerned. An AI agent, meaning a program that carries out tasks, applies their comments, and an approval mode lets you validate each change before keeping it; a log records what changed and why. The comments and the log stay with the document, with no third-party service and no database, and the document exports to PDF to send to suppliers.

When it’s a redesign

A redesign doesn’t start from scratch. The requirements document has to say what exists and what you are keeping: the pages and content to carry over, the current addresses that will have to redirect to the new ones, and what the old site does today that nobody thought to write down.

The starting point is a content inventory, which the Nielsen Norman Group describes as a list of everything the site contains, page by page, and the audit that follows decides what to keep, what to update and what to remove. For addresses, Google’s documentation on site moves is precise: list the old URLs, map each one to its new destination, and keep the redirects for at least a year. A permanent redirect, known as a 301, doesn’t lose the ranking credit the page had built up.

Who should write it

You know what you need; someone still has to know what each line will cost to build. A requirements document written by people who build can be priced line by line, and no line rests on guesswork.

When we write specifications, they are written to be carried out by someone else: they are yours, and you remain free to go elsewhere. If you need to ship a site without a technical team, this document is where the project starts.