Website requirements specification: the ten areas that shape your project

We have read many requirements specifications for new websites. The ones that work have one thing in common, and it is not their length. They are clear about what the website needs to achieve and which systems it must connect to, but flexible about how it should look. The ones that fail do the opposite: vague goals, but design and functionality prescribed in detail.

Here are the ten areas we believe a requirements specification for a new website should cover. We explore two in depth, because they are where most projects succeed or fail.

This list comes from the checklist in our guide Website procurement. You can use it as a template for your document or as a starting point for a conversation with the agency, whatever you call your website requirements document.

1. Purpose and goals. Why you need a new website, and how you will know it is better than the old one.
2. Functionality. What the website needs to do, how easy the CMS should be for your editors to use and which systems it must connect to.
3. Design and usability. Visual identity, how navigation should work and the level of accessibility the website must meet.
4. SEO and performance. Requirements for heading structure, metadata and URLs, a target loading time and an audit of what already appears in Google.
5. Content strategy. Who will write the copy, how many languages are needed and how much content must be migrated from the current website.
6. Analytics and tracking. Which tools need to be in place and who is responsible for setting them up.
7. Timeline and budget. A target launch date and an agreed budget.
8. Legal requirements. GDPR for forms and client data, how cookies and consent will be managed, and whether the website falls under the Swedish Accessibility Act or the Act on Accessibility to Digital Public Services.
9. Internal project team. Who will be involved on your side, and who will be the internal project manager.
10. Ongoing management and support. Support and maintenance after launch, response times in an SLA, backups and a plan for when something breaks.

This list is not a form where every line needs the same level of detail. Some areas need to be set out in full. For others, it is enough to have made a decision.

The rule of thumb is simple: fix what will be expensive to change later.

Fixed: goals and measurement, integrations, budget, legal requirements (including accessibility) and who makes the decisions. Change these mid-project and the price, timeline and sometimes even the choice of platform will change too. We cover that last point below.

Open: how pages look, how the menu is structured and exactly which components are needed. This is where the agency has the most to offer, and where user testing often changes the direction.

That does not mean design is unimportant. It means design should serve the goals, not be decided before anyone knows what those goals are.

The two areas we explore below are the ones most often left too vague. Both belong firmly in the fixed category.

This is the first thing an agency needs to understand. The clearer it is, the better the agency can recommend the right solution, rather than simply building exactly what was on the feature list.

Here we combine areas 1 and 6 from the checklist. A goal you cannot measure is a wish, and measurement without a goal produces numbers nobody looks at.

Explain in one or two sentences why you need a new website. Common purposes include:

• strengthening the brand
• generating leads or increasing sales
• improving the user experience and accessibility
• reaching new audiences online
• improving efficiency through integrations

Choose one or two. If everything is equally important, the agency will set the priorities for you.

You should be able to measure progress against a goal after launch. It does not have to be perfect, but it needs to exist. For example:

• 30 per cent more quote requests
• halving mobile loading times
• no more than two clicks from the home page to the contact form
• 20 per cent more visits from Google to service pages

Record your current figures too, if you have them. A goal of more enquiries means nothing if nobody knows how many you receive today.

This is where area 1 becomes genuinely useful. When the goal comes first, you can assess every proposed feature against it. A chat feature should be there because it reduces calls to the service team, not because a competitor has one.

A feature that cannot be linked to a goal is not necessarily a bad idea. But it should be among the first to go if the budget falls short, and the document should make that clear.

Without a definition, you cannot say whether the new website performs better. Write down what counts as a conversion: an enquiry, a booking, a download or a purchase. Specify where the information should go, such as your CRM, and whether it needs to be processed internally.

This is the line most often missing. List the tools you use today, such as Google Analytics 4 or Matomo for analytics, and Google Tag Manager or Meta Pixel for marketing. Specify which ones the new website needs, and whether the agency, your team or a third party is responsible for setting them up.

If nobody is given responsibility, nobody will take it.

Four lines. That is enough for the agency to understand what needs to be built, and for you to evaluate the project afterwards.

Integrations are the costliest and riskiest part of a web project. Connections to CRM, ERP, booking or inventory systems often have more influence on the price than design does. When those connections are unknown, the agency is pricing a website that may not be the one you need to build.

In the checklist, integrations sit under area 2, functionality. We have given them their own section here because they deserve one in your document.

Before listing systems, describe what the visitor does and what happens next. The visitor fills in the form, the enquiry goes into our CRM and the sales representative receives a notification. It does not need to look polished.

If you cannot map the flow, you are not ready to ask for a fixed price for the integrations. That applies, for example, if you do not yet know which systems the website needs to connect to. Instead, ask the agency to quote for a discovery phase that defines the flow, then request a fixed price afterwards. This is a typical digital strategy engagement.

For every system the website needs to connect to, answer six questions:

1. Which system? Name it: HubSpot, Salesforce, Lime CRM, Fortnox or your booking system.
2. What needs to be sent or retrieved? Leads, client data, orders, product data or stock levels.
3. In which direction? From the website to the system, the other way round, or both.
4. How often? In real time, once a day or when someone presses a button.
5. Who owns the system? And is an API available, or does access cost extra? If you do not know, say so and ask the agency to assess what kind of connection is needed.
6. What happens if the connection stops working? Should the enquiry be saved and sent later, or is it enough for someone to receive an alert?

The last question is almost always forgotten. It determines whether a Friday evening outage costs you a few enquiries or a whole weekend of lost orders.

Say so. It is better to write we need a payment solution that lets business clients pay by invoice, and would like recommendations than to choose a system you are unsure about. An experienced agency can suggest different systems based on your circumstances and needs.

If the website will include e-commerce, this section grows: payments, shipping, inventory and PIM all come into play, and e-commerce also falls under the Swedish Accessibility Act. Our guide Website procurement includes a separate checklist covering seven areas of e-commerce.

Specify that all integrations must be documented and the entire flow tested before launch, from the first click to the information reaching its destination. This costs little during the project, but its absence can cost a lot when someone else takes over the website.

Integrations and major features determine more than the price. They also determine which platform is right.

Different CMS platforms have different strengths. Some are built to help editors publish pages quickly; others are designed to retrieve and send data between multiple systems. They differ in how content is stored, how it can be reused across other channels and how easy it is to connect to CRM, ERP or inventory systems. A system that is excellent for an information website can become expensive and cumbersome when it needs to handle real-time product data, and vice versa.

That is why fixing the platform in the requirements specification before you have described what the website needs to do is risky. If it says "the website must be built in system X" the agency will price for system X, even if your needs point elsewhere. If that becomes clear halfway through the project, switching platforms is expensive. The platform is therefore one of the things that is costly to change, which is precisely why you should fix the needs that determine the choice, not the system itself.

Do this instead:

• Describe the needs, not the system. Which integrations you need, which major features you envisage, how many editors will use the system, how many languages you need and whether you want to build campaign pages yourselves.
• Ask the agency to recommend a CMS and justify its choice against your requirements specification. The reasoning then becomes part of the proposal, allowing you to compare how well different agencies have understood your needs, not just which systems they usually work with.
• Ask what the choice means for the future. Are there plenty of developers who work with the system? What will licensing and hosting cost over time? An uncommon CMS can leave you dependent on a single supplier.

If there is a reason to choose a system in advance, such as an existing licence, an IT policy or a system you already maintain, state it as a requirement and explain why. The agency will then know it is a constraint, not a preference.

If you want to understand the differences between platforms before speaking to agencies, our guide Choose the right CMS covers traditional and headless systems and six common platforms.

Three tips that make the biggest difference:

Give one person ownership of the document. Someone with the authority to say no, who will read the entire requirements specification in one sitting before it is sent out. Conflicting requirements produce quotes you cannot compare.

Challenge every requirement. Ask: who in our organisation needs this, and what happens if we do not have it? Remove any requirement nobody can justify. This is especially important if the document was written with AI, which knows what a website can include but not what you actually need.

Do not forget the old website. The requirements specification describes the new one, but what ranks and converts today needs to be preserved, migrated or redirected. Require an audit before design work begins.

For more on what tends to go wrong, read Ten mistakes we see in website procurement. If you are at an earlier stage and need a shorter outline for the agency, see Briefing your web agency.

Our guide Website procurement includes the full checklist for all ten areas, plus a separate checklist for e-commerce. Download the guide