Website requirements: content, responsibilities and approval

Describe who the website is for, what those customers need to understand and which action they should be able to complete. A contact form may be a feature, but it needs to be clear which types of enquiry the form should collect and who will handle them.

State what the project should change from the current situation. Distinguish a documented problem from a wish so that you can prioritise when budget or time is limited.

Mark what is required for launch and what can come later. Specify the budget, desired timing and dependencies, such as when copy, translations or an external booking system will be available. This makes it possible to assess what must be ready before the next part can be approved.

Illustrative example: a service business wants enquiries about the right engagements. An essential requirement could be that visitors can understand the services and send an enquiry to the correct recipient. An advanced quotation calculator could be a later improvement if a normal enquiry meets the launch task. Base the priority on the business need, not on which feature looks most impressive.

Also state what supports the problem description. Customer questions may show that service boundaries are unclear. A form check may show that messages do not reach the recipient. Do not state that a new feature will increase conversions if that is only a hypothesis; describe the behaviour you want to improve and how it could be followed up.

List the agreed pages and the question each page should answer. State who supplies the factual information, who writes and who approves. Images, customer quotations and results need permission and verifiable sources where relevant.

A topical map assigns questions to pages and sections. It makes overlaps visible: two questions can sometimes be answered on the same page.

Distinguish a requirement from a solution fixed too early. The requirement might be that a customer can send the right type of enquiry and receive confirmation. The exact field placement and choice of components can be explored during design, as long as the function and the check are clear.

What must be ready before the content can be approved?

Each content item needs supporting material, an owner and a clear record of what has been approved. Record which copy, images and translations are missing, when they are needed and who decides whether they are complete. An empty content box is not approval of future wording.

If the website will be multilingual, specify which pages should exist in each language at launch. Decide who translates, checks factual details and approves the language. A technically complete language switcher does not mean every page is translated or that enquiry journeys work in every language.

Also record which existing material will be retained, rewritten or removed. If one supplier both writes and builds, the scope still needs to identify who supplies the business facts. Page count alone does not describe the workload: new copy, a reviewed translation and an imported article archive are different deliverables.

Write requirements so that someone can check whether they have been met. Separate the desired behaviour from how the result will be tested and who has authority to approve it.

How do you write a testable requirement?

A testable requirement states what should work, under which conditions and what outcome counts as acceptance. “The form should work well” leaves the check undefined. A more useful requirement is that a test enquiry from the agreed mobile environment reaches the correct recipient and gives the visitor confirmation. Use the table as a basis for your own requirements:

The table is a working example, not a description of features automatically included in a SOVRA Digital package. Each requirement needs a named owner and an agreed check.

Who performs the check, and who approves?

Assign each requirement to an implementer and a reviewer, and define an observable outcome. Illustrative contact form example: the client confirms the recipient address and the types of enquiry to accept, the implementer builds the feature, and an appointed reviewer sends a test enquiry. The requirement is met only when the correct recipient receives the correct information and the visitor receives the correct message.

Document the roles in the requirements specification, not just in meeting notes. If one person holds several roles, it still needs to be clear who can approve the delivery. Otherwise, a test may pass technically without anyone checking whether the result meets the business’s needs.

Which failures should the test be able to detect?

Test both successful completion and relevant failures that need to be handled. A form that works with perfect test data may still leave visitors without help when a required field is missing or a message cannot be sent.

For the same illustrative contact form, you could agree on a test with valid details, a test with a required field left empty and a test of the agreed handling of a delivery failure. Visitors should understand what needs correction and should not receive a success message when delivery has failed. The technical solution and test environment need to be defined in the project.

W3C’s guidance on form validation explains how required information and errors should be made understandable. It also emphasises that browser-side validation alone does not ensure security. The requirements need to identify which checks the implementer is responsible for; a successful visual test does not replace technical checking.

Separate the project cost from domain, hosting, licences, editing and technical maintenance costs. Specify which accounts and permissions need to be managed, which instructions must be provided and who is responsible for future changes.

Describe how often the content will change and who will make those changes. This informs the choice of editing system.

What should the handover include?

The handover needs to let the responsible person manage the website and know who handles a problem. Decide which of the following items apply to the project and assign an owner to each:

• Accounts and permissions: who owns and administers the domain, hosting, publishing system and connected services?
• Editing: which content types may the client change, and which instructions or walkthrough should be included?
• Operations and recovery: who follows up faults, manages backups and checks that an agreed restoration can be performed?
• Costs and agreements: which costs are one-off, which recur and which party pays for each service?
• Future changes: how are defects reported, and how is content or functionality outside the approved scope commissioned?

This list supports responsibility planning; it does not mean operations, training or ongoing maintenance are always included in a website project. If work ends at approved delivery, responsibility after that point still needs to be clear.

State when the structure, content and design will be approved and how changes outside the scope will be handled. Before launch, agreed requirements should be traceable to a check, an outcome and a responsible person.

For each agreed check, you can record the requirement ID, test environment, steps performed, expected result, actual result and approver. Note the date and version tested. If a later change affects the same feature, the relevant check needs repeating; an earlier successful test describes the earlier version.

Content approval, technical acceptance and permission to publish need to remain distinct when they happen at different times. A correct preview does not automatically mean the responsible client has approved making the page public. Record remaining defects, who handles them and which decision is required before launch.

How do you distinguish defects from new requests?

A defect is a deviation from an agreed requirement; a new need is treated as a change in scope. The record needs to state which requirement is affected, what was observed and what must be done before approval. When a request is not part of the specification, its impact on scope, timing and cost should be assessed before it is added.

Illustrative example: if an agreed form does not send to the specified recipient, investigate the deviation against the requirement. If the client instead wants the form to create a record in a new CRM system as well, that is an additional function to assess. Use the agreement and observed behaviour as the basis; do not decide solely by how small the change appears.

What needs to be checked when replacing a website?

When a website replacement changes existing URLs, map the old addresses to their intended new destinations and check them after the move. State who prepares the address list, who implements the changes and who tests the result. Include important contact journeys and pages that must remain available. SOVRA Digital’s page on web development describes the process and base scope; the final delivery is defined in the quotation.

When URLs change, Google recommends mapping old and new addresses, implementing redirects and monitoring the move. Google’s site migration guidance supports the technical plan. A new visual design does not in itself require changing working addresses.

The requirement can therefore state that each agreed old address reaches its intended destination and that important internal links point correctly. Also check that pages intended to be public do not retain a restriction from the test environment. These are delivery checks, not a promise of unchanged search rankings.

If the requirements concern content on small screens, the mobile-friendly website guide provides examples of tasks and outcomes that can be checked. Use the examples to formulate your own requirements, not as an automatic list of what every website project includes.