01 / Define the commission
A reliable website brief needs requirements you can test
Agree the outcome before the first layout
When you create a website brief, start by describing the tasks that visitors and employees must be able to complete reliably. For each important task, record its scope, the necessary content, who is responsible and an observable result to check. This becomes a requirements specification that helps you plan a website offering several services and verify its operation later. A collection of favourite websites is no substitute for this, nor is a request for a modern design.
This guide takes you through a Website Requirements Register with acceptance scenarios. You can copy the tables and fill them with your services, locations, languages and data flows. The focus is on connecting a business rule to the website's specific behaviour. The examples concern a website with several service pages, an enquiry form, editorial content and, where required, a handover to a sales system.
Start with information your business already has: descriptions of its services, recurring customer questions, the intended enquiry process and limitations on handling requests. Assign an owner and a decision date to missing facts. An undecided service area, for example, should not be replaced by a map allowing unrestricted selection anywhere in Germany. Until that decision is made, the associated requirement remains open.
Sources checked: 3 October 2026. The register, priorities and approval steps are an editorial working method. The operational checks described here do not determine contractual acceptance or its legal consequences; those arrangements must fit the particular commission.
02 / Organise the documents
Connect the brief, requirements and proposed implementation
Use one shared foundation rather than competing files
Agree what the terms mean within your project. The brief describes the starting point, objective and constraints. The requirements specification, often called a Lastenheft in Germany, defines what the website must do and under which conditions. The supplier's implementation proposal or Pflichtenheft explains how it will meet those requirements. This practical distinction does not prescribe a document length. For a manageable project, three clearly labelled parts of one shared file may be sufficient.
Consider this example: “Enquiries must be assigned according to service and location” is a requirement. Whether this is achieved with a particular form tool, an integration or an initially manual process is a solution decision. A platform becomes a binding constraint when there is a reason for it, such as an existing system or an integration you actually need. Otherwise, specifying it too early can unnecessarily limit the available solutions.
The general guide to website development: formats, costs and process helps with the earlier decision about the type and scale of your project. Here, you turn that decision into a scope that can be checked. Record an approved baseline version. Each subsequent addition should refer to that version and the affected requirement numbers; a new presentation should not silently override decisions already made.
Also appoint someone who can resolve conflicting requests on the client side. If sales wants an immediate appointment confirmation but operations must first check availability, a designer cannot settle that conflict alone. The document must specify either a confirmed booking with its prerequisites or a non-binding enquiry. This decision affects the wording, form states, notifications and later measurement of results at the same time.
03 / Record the requirements
Set up the Website Requirements Register
Every row leads to an observable outcome
Give each requirement a permanent identifier. Describe the situation, required behaviour, priority, evidence and business owner. The GOV.UK guidance on writing user stories connects the user, task and purpose with outcomes that can be checked. For your business, this is a methodological reference, not a UK administrative requirement. Always add the specific business rule that the supplier cannot be expected to guess.
The following rows form a completed teaching example. “Must” means that the affected scope cannot be approved until the requirement is met. “Later” means it is outside the current commission. “Open” describes progress and is not a lower priority. In addition to this compact view, record the version, dependencies, status and a reference to the test evidence for each identifier.
| ID | Situation | Required behaviour | Priority | Test evidence | Business owner |
|---|---|---|---|---|---|
| R01 | Several services | Selection remains when moving to the enquiry | Must | Compare the selection with received data | Sales |
| R02 | Limited service area | Clearly show the approved area status | Must | Test locations inside and outside the area | Operations |
| R03 | Handle an enquiry | Confirmed enquiry is present at the agreed destination | Must | Find the test reference at the destination | Sales manager |
| R04 | Two launch languages | Corresponding content and form messages are translated | Must | Language matrix and complete walkthrough | Editorial team |
| R05 | Ongoing updates | Authorised editors can change service information | Must | Demonstrate editing, preview and publication | Website owner |
Evidence records the environment, version, steps, expected result and actual result. A screenshot alone does not prove the data transfer required by R03. Conversely, a technical log alone does not show whether R02 is understandable to the visitor. Choose evidence that actually tests the claim made by each row, and keep unmet conditions visible throughout the project.
04 / Service boundaries
Separate services, areas and responsibilities clearly
Turn the service catalogue into a rules matrix
Where a business offers several services, a shared enquiry form can conceal different information needs. Clearing a property requires different details from assembling a piece of furniture that has already been delivered. Separate the service, prerequisites, location, required inputs and responsibility. Also decide what happens when services are combined: a shared review, separate work items or a follow-up question. A broad label such as “complete service” does not answer those questions.
As a public example, the HandMen guide to clearance, moving and furniture assembly separates work stages and explains the role of independent partners. Do not adopt its promises as your own. Use the example to identify which responsibilities and information visitors to your website need to understand.
| Area | Included scope | Required information | Location rule | Responsibility | Boundary |
|---|---|---|---|---|---|
| Clearance | Specified rooms and items | Volume, floor and access | Confirmed service area | Named service provider | Review special cases separately |
| Transport | Agreed transport leg | Start, destination and items | Check both locations | Transport provider | Assembly is not automatic |
| Assembly | Named furniture and tasks | Model, quantity and delivery status | Check the work location | Assembly provider | Clarify connections separately |
| Matching | Search for a suitable partner | Task and contact request | Matching service area | Matching service | Do not claim to perform the work |
| Combination | Approved component tasks | Details for each component | Check overlapping conditions | Owner of each component | No blanket overall commitment |
This table is a working example, not the actual service catalogue of HandMen or Salestudia. Replace every row with your own confirmed conditions. In particular, make a deliberate decision about enquiries outside your service area: provide an honest response or a defined review route. Successful form submission must not turn an unconfirmed request into a promise of availability.
05 / Pages and journeys
Agree the page scope and navigation before design
Templates, content and URLs are different units
Create a page inventory that records purpose, template, language, content source and intended next step. Three service pages can use the same template while still requiring three distinct pieces of editorial content. Count templates and pages to populate separately. Include form states, confirmations, error messages and necessary system pages. These are easily missed if the estimate counts only visible menu items.
Test navigation against actual tasks. A prospect should be able to find a suitable service, understand its boundaries and submit their information. An existing customer may instead need direct contact or service information. Ask someone to demonstrate these journeys using a simple structure sketch. Where a decision is impossible without extra knowledge from a sales conversation, content or an understandable label is usually missing.
For address planning, Google recommends a readable, descriptive URL structure. Agree naming conventions and ownership early. This does not guarantee rankings. Also record which pages genuinely need to exist independently. Adding another town name to the menu does not automatically justify a new page with otherwise identical content and an unconfirmed local presence.
Agree a structure approval before the layout: the page list is complete, the main journeys make sense, service boundaries are assigned and missing content is identified. Changes remain possible, but they are treated as changes. This makes it possible to distinguish an incomplete implementation of the approved scope from an additional section requested after that scope was agreed.
06 / Content and languages
Plan a complete delivery process for every language
Translation includes the small system messages
Define a language matrix for every page and function. “DE and EN at launch” must make clear whether both versions have the same scope. This includes navigation, forms, service-area notices, errors, confirmation messages and editorial metadata. Name the people who supply the facts, write the copy, translate it and approve it for accuracy. An available draft translation is not yet approved content.
Google's guidance on localised page versions includes reciprocal references between genuine language alternatives. Put the intended relationships into your requirements and ask the supplier to propose their technical implementation. A language switch should lead to the corresponding available page; a version that has not been created should not be represented by an unrelated page presented as its translation.
The guide to multilingual websites for Germany explores the relationship between search, user experience and localisation in more detail. For the specification, begin with a binding allocation: which content will launch, who supplies it and which walkthrough confirms its completeness. Also plan a process for later changes. If a service restriction changes in German, it must be clear which translations need to be checked again.
Collect images and supporting material with their source, intended use and approval status. Editors do not need private customer documents to test a template. Use examples prepared specifically for that purpose. Where images or specialist copy remain outstanding, state the delivery date and affected pages. “Content will follow” is not a sufficiently precise dependency for a reliable launch plan.
07 / Form behaviour
Derive form fields from the handling process
Each input has a purpose and an error case
Work through each field: which decision does this information enable, and is it needed at the first contact? Record whether it is required, its format, explanation and use. An assembly project might need a furniture-type selection; a full billing address may not yet be necessary for an initial non-binding discussion. The person who actually handles enquiries should confirm the specific rules.
The W3C guidance on labelling form controls explains how to associate understandable labels with inputs. Turn this into a testable requirement: visitors can identify the field's purpose, required information and permitted input without relying on a placeholder that disappears. Also describe whether earlier inputs remain valid when the service changes or need to be removed. Hidden, contradictory old values must not be submitted unnoticed.
Specify clear feedback and a way to correct invalid inputs. The W3C input-validation tutorial notes that browser checks do not replace validation on the server. Require a negative test with a missing mandatory field and a successful run using permitted information. The technical supplier should document where the rules are enforced.
Then test a change of scenario. If someone first selects transport and then changes to assembly only, the summary and transmitted data must reflect the current request. This is a more meaningful test than simply counting the form fields. For each change of this kind, record what information remains, what is removed and which additional question appears.
08 / Confirm receipt
Follow the enquiry through to the responsible employee
Check visible success and operational receipt separately
Describe the entire data flow: form, receiving service, agreed destination and responsible person. Define which confirmed state triggers the success message. With an asynchronous handover, it must be clear whether the website confirms secure receipt or a later processing stage. The message should describe only the state actually reached. Promising a personal response also requires an operational rule.
For status messages, W3C explains how assistive technology can identify them without a focus change. Your acceptance scenario should therefore also check how the user becomes aware of a confirmation or error. However, the test is not complete until the prepared test reference can be found at the agreed destination. Compare the received service selection, language, location and required contact details with the original input.
If the handover fails, specify how the failure is detected, who owns it and how it is retried. Resubmission must not create uncontrolled duplicate work items. Explain how an existing request is recognised and how uncertain cases are reviewed manually. The article on forms and conversion rate optimisation provides further guidance on designing and checking enquiry journeys.
STOP for R03: A green form message with no received enquiry is not a passed test. Record the state actually reached, correct the handover and repeat the same scenario. An analytics event is not a substitute for operational evidence either.
09 / Data and security
Specify privacy and uploads as concrete work packages
Responsible decisions are more useful than vague assurances
The requirement “GDPR compliant” alone identifies neither the data nor its processing. Record categories, purpose, recipients, systems, access roles and the decision on retention or deletion. The European Data Protection Board explains the basic principles, including necessary data, transparent processing and an appropriate legal basis. The implementation and notices your project needs must be assessed against its actual data flow, with specialist legal review where required.
Name the owner of that review in the brief and identify which decisions implementation depends on. Separate an enquiry from additional marketing consent; have the legal basis and wording determined for the specific purpose. A generic checkbox cannot replace missing decisions about recipients or retention. Sensitive original data and passwords do not belong in a widely distributed project attachment.
Photographs and documents create a separate functional scope. The OWASP File Upload Cheat Sheet recommends multiple protective measures; a claimed file type alone is insufficient. Agree permitted formats, size limits, validation, protected storage and authorised access. Ask the supplier to describe the security measures and the behaviour when a file is rejected, rather than merely ordering an upload button.
Also establish whether uploads are necessary for the initial launch. If the business needs documents only after reviewing an enquiry, a separate agreed transfer route may make more sense. That decision changes the process and must be documented. Adding uploads later is a new requirement with its own data flow and tests, not a small feature that is automatically included.
10 / Define measurement
Tie measurement to confirmed states
Technical success is not yet a qualified enquiry
Before implementation, decide which questions measurement should answer. Starting a form, confirmed submission, operational receipt and a qualified contact are different states. Specify the trigger, permitted parameters, destination system and owner. The supplier should be able to demonstrate when an event occurs and when it does not. A click on “Send” alone is not suitable evidence of a successful submission.
Google lists generate_lead as a recommended GA4 event for a lead that has been generated. Whether you use it, and at which confirmed stage, belongs in the measurement plan. An event name proves neither that the contact can be reached nor that it is suitable. That assessment needs its own criteria and may require later feedback from the system used to handle enquiries. Do not invent values or success rates for it in the specification.
Define tests for the agreed consent states, validation failures and repeated interactions. State what measurement is expected in each case and have the configuration reviewed by the appropriate specialist. An absent analytics event may be expected under certain conditions while the enquiry must still be handled reliably. The two checks therefore need separate evidence and separate owners.
Sensitive inputs do not belong in broadly accessible event parameters or page addresses. Instead, describe the necessary non-sensitive attributes, such as an agreed service category, and have their use checked. Later reporting should be able to distinguish test enquiries. The register records how that distinction is made without filling a public report with supposed real business results.
11 / Quality of use
Agree measurable performance and accessibility requirements
The test environment and scope are part of the target
“Fast on a phone” needs a defined test. Agree representative page types, device conditions, content and measurement methods. An empty template and a populated service page with images are different test subjects. Core Web Vitals assess real loading performance, responsiveness and visual stability. Laboratory measurements taken before launch therefore do not establish that field data from subsequent real use already exists.
Separate two tasks: reproducible technical checks before approval and observation under real conditions after launch. Assign an owner and agreed targets to each. If a new website does not yet have reliable usage data, document that gap. Do not mark it as passed or conceal it with an arbitrary individual measurement. A good performance result does not guarantee sales either.
For accessibility, you can choose WCAG 2.2 at an explicitly agreed conformance level as a technical reference. Assessment must cover complete pages and processes within the agreed scope; an automated scan alone is insufficient. The applicable legal obligations need to be established separately. A technical target does not automatically answer that legal question.
Write practical scenarios: use the main navigation with a keyboard, identify focus, understand form errors and read content on a narrow screen without clipped controls. Also check enlarged text and the agreed assistive technologies. Such scenarios make requirements easier to discuss, but do not replace a full assessment against the agreed standard. Assign identified barriers to a requirement and a subsequent retest.
12 / Replace an existing website
Commission a relaunch with an inventory and clear handovers
Existing URLs and data flows should not be silently replaced
For an existing website, add important URLs, forms, downloads, language versions and connected systems to the brief. Record what should be retained, changed or intentionally retired. Every change needs a decision and an owner. An old form may, for example, still be linked from an active advertising campaign even though it barely features in the main navigation.
For site moves involving changed URLs, Google recommends mapping old addresses to new ones, implementing suitable redirects and monitoring the move. Have these tasks explicitly included. The existence of some redirect is not an adequate test: an old service page must lead to the agreed relevant destination. Planning can reduce risk, but cannot guarantee unchanged search positions.
Describe the publication process and name owners for the domain, hosting, content, forms and measurement. Agree which tests must be repeated immediately after the switch. A preview test does not automatically prove that an enquiry reaches its destination in production. Also document the response to a serious fault and which data must be preserved if the previous version is restored.
Transfer access through an appropriate secure channel and limit it to the necessary roles. The specification records the system, required permissions, owner and delivery date, not passwords. Include the later removal of unnecessary access and the contact responsible for incidents. This prevents the technical handover from amounting to little more than a message containing a login.
13 / Decisions and changes
Keep budgets, dates and change requests traceable
Give unknowns a decision point instead of a silent assumption
Divide the scope into mandatory requirements, explicitly optional items and later phases. Ask suppliers to identify unanswered questions, assumptions and exclusions. An integration without a price is not free. If its feasibility still needs investigation, first agree what that investigation must deliver and the decision that follows. This makes clear which part of the project can already be commissioned on a reliable basis.
Dates must depend on available content and decisions. Record, for example, when service facts will be approved, translations delivered and test access established. If a prerequisite is delayed, make its effect on dependent work visible. A blanket statement such as “finished in four weeks” is of little use when the first content approval is scheduled for the final day.
Keep a simple change log: identifier, request, reason, affected requirements, effort, schedule impact and decision. In the teaching example, CR01 adds appointment reservations. It affects availability, confirmations, error scenarios and data storage. Only after assessment is a decision made about including it in the current version or postponing it. A casual “could we also” becomes a choice that everyone can trace.
Finally, identify who can approve the business requirements and who can commercially authorise changes. In a small company these roles may belong to the same person, but they should still be explicit. Collect feedback in one shared channel and resolve contradictions before passing it on. The number of comments says little about their authority; a consolidated decision and a clear document version are what matter.
14 / Secure the deliverables
Assemble a briefing package that can be handed over
Five attachments make the scope tangible
Bring the decisions together in a short main document. It states the objective, audience, service scope, launch languages, owners and unresolved points. Attachments hold the details that can be checked. You can use one workbook for this; what matters is clear naming, versioning and references. The following model shows what each part delivers and how its completeness is assessed.
| Attachment | Contents | Business input | Supplier contribution | Approved by | Completeness check |
|---|---|---|---|---|---|
| A: Service rules | Services, areas and boundaries | Confirmed conditions | Questions and presentation | Operations | Every launch service is covered |
| B: Pages and languages | Pages, templates and language scope | Content and priorities | Structure and components | Editorial team | Every page has a source and status |
| C: Requirements | Identifiers and test cases | Expected behaviour | Solution and effort | Project lead | Every mandatory item is testable |
| D: Data flows | Form, receipt and measurement | Recipients and ownership | Handover and error handling | Owner of each data flow | Success and failure cases exist |
| E: Handover and operation | Access, editing and maintenance | Operator and permission needs | Documentation and training | Website owner | Operator can take over the tasks |
A header you can copy for the main document is: “Project; version; decision date; responsible person; objective; initial scope; excluded scope; open decisions; next approval.” Give each field a concrete status. “Unresolved: operations to decide before structure approval” is better than an empty field that might later be interpreted as agreement.
Give every supplier the same approved version when requesting proposals. Ask them to map their responses to the requirement identifiers: included, alternative proposed, optional or still to be clarified. Different solutions become comparable without forcing identical technology. Keep the response with the attachments it relies on; a total price without that reference does not adequately describe the commission.
15 / Walk through the example
Write a complete acceptance scenario while preparing the brief
A teaching example for a request involving several services
The following scenario is fictional and does not describe a measured client case. A service business is planning a website for clearance, transport and assembly. DE and EN are included at launch. The enquiry should enable a professional assessment; binding bookings and online payments are excluded. The visitor's selection must remain available while location and feasibility are evaluated against the confirmed operating rules.
Test T01 connects R01 to R04: open the English assembly page, select assembly, enter an approved service location and permitted example data, then submit the enquiry. Expect an appropriate English message and exactly one work item containing the current service selection and language at the agreed destination. The internal test reference, time and document version connect input to evidence. The wording must not turn the enquiry into an order or a firm commitment.
Repeat the journey with a location outside the confirmed area. In this teaching example, the rule agreed in advance is to allow the enquiry for manual area review and display that limitation clearly. Expect the status “Check service area” at the destination. Another business could choose to reject these enquiries; that would be a different requirement, tested with an appropriate response. The website does not decide business policy itself.
Then test a handover failure in a controlled test environment. Record whether receipt had already been secured, which message appears and who resumes the process. The case passes only when the agreed retry does not create an additional unintended work item. Observing that “the form looks right” is insufficient. A further test of R05 then demonstrates that an authorised editor can change and check a service restriction.
16 / Prepare approvals
Set clear decision points before design, development and launch
Unmet mandatory requirements block their affected scope
Use a small number of understandable approvals. Each answers a different question: is the business task clear? Is the structure complete? Can the solution be tested? Does the agreed journey work? Can the company operate the website? Approval of its appearance does not automatically answer the other questions. Record exactly what has been approved and which conditions remain open.
| Decision | Required state | Evidence | Decision-maker | If evidence is missing |
|---|---|---|---|---|
| Approve scope | Services and boundaries are clear | Attachment A and open points | Client | Defer the affected scope |
| Approve structure | Pages and languages are assigned | Attachment B and user journeys | Editorial team and project lead | Assign the missing content |
| Approve implementation | Mandatory requirements are answered | Attachment C and solution proposal | Project lead | Decide on deviations |
| Verify operation | Agreed scenarios have been run | Results from attachment D | Relevant business owners | Correct faults and retest |
| Take over operation | Permissions and editing are handed over | Attachment E and training | Operator | Complete the handover |
A small outstanding issue must not silently become a passed test. Describe its effect, owner, agreed handling and the decision about the affected part. A missing enquiry, for example, needs different treatment from an editorial request for a later phase. This classification should follow the agreed purpose, not the convenience of the publication date.
Archive the approved version with results and any limitations that still apply. After a change, repeat the directly affected scenarios; when a form changes, include its handover and messages. The requirements specification remains useful after launch because it shows what was agreed and which new decision justifies the next stage of development.
17 / Common questions
Eight questions about website briefs
How long should the specification for a small website be?
Long enough to make the scope, responsibilities and important scenarios unambiguous. A fixed page count is not useful. Instead, check whether another supplier could infer the same expected behaviour from the documents. Short tables with complete information are more helpful than many pages of general design preferences.
Do I have to specify the technical platform?
Only where a justified constraint requires it. Otherwise, describe editing, content, integrations and necessary permissions. Ask the supplier to propose a suitable solution with its limitations and ongoing effort. A familiar product name alone does not establish whether it reliably supports your enquiry process.
Can design begin while content is still missing?
A draft using clearly labelled examples is possible. However, reliable approval requires the actual service rules, approximate volumes of key text and requirements to be known. Otherwise, the design is built around assumptions that may be expensive to correct. Explicitly identify missing content and its consequences.
Should the number of pages be in the brief?
Yes, as an understandable inventory showing purpose, template and language scope. A single number remains ambiguous. Count editorial content, technical templates and system states separately. Also agree who creates and enters additional content if the approved scope expands later.
Is one successful test enquiry enough for approval?
It proves only the scenario that was performed. Add the agreed languages, failure states and important variations, such as changing the selected service or choosing an unsupported area. Check operational receipt. The scenarios you select should reflect the actual rules of your project.
Who writes the legal notices?
Before implementation, identify a qualified owner and the information they need about the business model and data flow. The technical supplier can integrate the notices and implement functions. That does not automatically mean an individual legal assessment is included in the development commission.
How should I handle new ideas during development?
Record them in the change log with affected requirements, effort and schedule impact. Then make an explicit decision about including them now or later. Good ideas remain possible without the client and supplier unknowingly working from different understandings of the scope.
Is the register still useful after launch?
Yes. It connects pages, rules, owners and tests when subsequent changes are made. Preserve the approved baseline and retest affected journeys. An untouched archived document is of little help if services, recipients or language scope have since changed.
18 / Next step
Start with a clearly bounded initial scope
Turn open questions into decisions that can be made
Begin with one representative service and follow its journey through to the actual handling of an enquiry. Complete the attachments, write a success scenario and a relevant failure scenario, and check ownership. Then apply the method to the other services. Shared rules can remain central; differences are added explicitly. This produces a complete brief without unnecessary repetition.
Before speaking to a supplier, the objective, launch scope, known limitations and open decisions should fit together. You do not need to pre-empt every technical solution. You should be able to explain the outcome your business needs and how you will recognise it. That foundation makes both a clear proposal and a practical assessment of the finished implementation easier.
If you want to prepare requirements, page structure and implementation together, Salestudia's website development services provide a starting point. Bring your current website, service and language overview, and unresolved decisions. The specific scope can then be agreed on that basis.