How to write a website or app requirements document: complete guide and template outline

A website requirements document (also called a project brief or functional specification) describes what you want to achieve: your goals, your users, the expected features, technical constraints, budget and timeline. It lets you obtain comparable quotes, frames the agency’s work and, at delivery, lets you check that the result matches what you ordered.

Why a requirements document is essential

Without one, every supplier interprets your needs differently: quotes cannot be compared, omissions turn into change requests and project handover becomes a source of friction. A clear document, on the other hand, lets you:

• compare proposals on the same basis;
• control the budget by separating essentials from nice-to-haves;
• secure the relationship with a shared contractual reference;
• run acceptance testing by checking each delivered item point by point.

Functional requirements or technical specifications?

	Functional requirements	Technical specifications
Written by	The client, possibly with a project management consultant	The selected supplier
Content	Needs, users, features, constraints	Architecture, technologies, data models, APIs
When	Before the tender	After the supplier is chosen
Purpose	Express the need	Describe the solution

The 10-section template outline

1. Background: your company, its market and what already exists (current website, tools, analytics).
2. Objectives: what the project must deliver, with measurable indicators (quote requests, online sales, processing time).
3. Audience: user profiles, their needs, devices and languages.
4. Scope: what is included and, just as importantly, what is not.
5. Sitemap and content: list of pages or screens, and who supplies text, photos and videos.
6. Features: described as user journeys or user stories (“as a customer, I want to track my order”).
7. Design: brand guidelines, references you like, usability and accessibility requirements.
8. Technical constraints: hosting, integrations (ERP, CRM, online payments), security, performance, multilingual support, browser and mobile compatibility.
9. SEO, GEO and analytics: URL migration, markup, structured data, analytics tools and visibility goals.
10. Project organisation: timeline, budget, deliverables, acceptance process, warranty, maintenance, training and code ownership.

Prioritising with the MoSCoW method

Placing each feature in one of four categories stops you from wanting everything in version one:

Priority	Meaning	E-commerce example
Must have	Essential at launch	Catalogue, cart, online payment
Should have	Important but can be worked around	Real-time order tracking
Could have	Nice to have if the budget allows	Wish list
Won’t have (now)	Postponed to a later version	Loyalty programme

The 7 most common mistakes

1. Describing technical solutions instead of expressing needs.
2. Forgetting internal users: back office, access rights, exports.
3. Not specifying who produces the content, or by when.
4. Leaving out SEO and the redirection of old URLs during a redesign.
5. Ignoring maintenance, hosting and security after launch.
6. Setting no objective acceptance criteria.
7. Writing a document so long that nobody reads it: clarity matters more than length.

Public tenders and project management support

For public bodies and large companies, the requirements document is often part of a formal tender. It then needs to be especially precise: evaluation criteria, minimum technical requirements, deliverables and penalties. A project management consultant on the client side helps formalise the need, analyse proposals and steer delivery, as we did for Tunisair Handling.

FAQ

Who should write the requirements document?

The client, because they know their business and objectives best. When time or technical expertise is short, they can be supported by a consultant or by the agency itself during a paid scoping phase.

How long should a requirements document be?

There is no ideal length. Around ten pages are enough for a brochure website; a business platform may require many more. What matters is that every feature is understandable and testable.

Can the requirements change during the project?

Yes, especially with an agile approach. Changes should nevertheless be tracked and approved, along with their impact on budget and timeline, to avoid scope creep.

Should I include mock-ups?

It isn’t mandatory, but a few sketches, screenshots of reference websites or a drawn user journey make your needs much easier to understand.

Get support from Uteek

Uteek writes requirements documents, supports project owners as a consultant and builds custom websites and web platforms. Have a project to scope? Send us your brief and we will help you turn it into a clear, actionable requirements document.