Functional vs content requirements in a brief

A functional requirement describes what the site must do — accept a booking, process a payment, filter a product list. A content requirement describes what the site must say — the words, images and information that fill it. Conflating the two in a brief is one of the more common causes of an inaccurate quote, because a supplier reading “we need an online store” cannot tell whether that means “build the payment and inventory system” or “write the product descriptions”, and most builds need both done by different people under different pricing logic.

Why functional requirements and content requirements get priced differently

Functional work is engineering: it is priced against complexity and risk, because a payment integration that mostly works is not a smaller version of the job, it is a liability. Content work is priced against volume and research: a copywriter’s estimate depends on how many pages need original words and how much information-gathering sits behind each one. A brief that bundles both into one line — “build us an online store” — invites a supplier to quote whichever half they do well and assume the other half is either included or someone else’s problem, and those two assumptions produce very different numbers for what sounds like the same request.

Worked examples of functional requirements and content requirements for the same feature

Feature as usually described	Functional requirement	Content requirement
“An online store”	Product listing, cart, payment gateway, order confirmation emails	Product names, descriptions, prices, photographs
“A booking system”	Calendar availability, confirmation emails, cancellation handling	Service descriptions, cancellation policy wording, staff bios if relevant
“A blog”	Publishing workflow, categories, search on the blog itself	The articles themselves — who researches and writes them, and how often
“A quote request form”	Field validation, routing the submission to the right inbox	The wording of the form, what it asks for and why

Every row shows the same pattern: the functional half is something a developer builds once and it either works or does not; the content half is ongoing, or at minimum extensive at launch, and it needs an owner named separately from the person doing the functional build.

Why a requirement stated only functionally can still be under-scoped

Even once a feature is correctly labelled functional, the functional requirement itself can be under-specified in a way that produces the same problem one level down. “A booking system” is functional, but it still leaves open whether cancellations are handled automatically, whether payment is taken at the time of booking, and whether the calendar needs to sync with software the business already uses. Naming the feature as functional is the first step; describing what it actually has to do when a customer cancels, pays late, or double-books is the second, and skipping the second step reproduces the ambiguity this page is otherwise arguing against, just inside a single line item instead of across the whole brief. A wireframe or a low-fidelity prototype attached to the line item does more work here than another paragraph of description — a supplier can see the states a booking screen needs to handle rather than inferring them from prose, and a rough prototype surfaces the cancellation and double-booking cases a written requirement tends to skip.

Non-functional requirements: the constraints that sit next to both categories

A brief that has correctly separated functional from content requirements still leaves out a third category that is easy to fold into the functional list by mistake: non-functional requirements. These are constraints on how the system behaves rather than what it does — a page must load within a stated time, a form must remain usable at the traffic the business expects at launch, a booking system must stay available during business hours. A functional requirements document (sometimes shortened to an FRD) that never names these constraints leaves a supplier to guess an acceptable standard, and a guess is not a requirement stakeholders on either side can be held to.

Where this distinction gets lost, and why

It gets lost most often around “who supplies the content” — the single item what a brief must contain lists as one of the nine essentials. A business that has never separated the two categories often assumes a supplier who builds the functional side will also produce the words, because both arrive as one deliverable — a finished website — and it feels like one job from the outside. Many suppliers build only the functional side and expect finished copy to be supplied, some include a content pass as a paid add-on, and a small number quote content as included by default. None of those is the wrong model; the problem is a brief that does not say which model it expects, because that is exactly the gap that turns into either an unplanned copywriting invoice or a launch delay while nobody writes the pages.

Content requirements are also where user needs surface most directly: user research into what a visitor is actually trying to find on a page belongs in the brief as a content requirement, not left implicit, because a designer building against user needs that were never written down is working from assumption rather than a stated requirement.

A rule of thumb for listing requirements accurately in the project’s requirements document

For every requirement in a draft brief — or in a longer requirements document for a larger project — ask whether it would still exist if every word on the site were replaced with placeholder text. If the requirement survives that test — a booking calendar still has to work, a payment gateway still has to process a transaction — it is functional. If the requirement disappears along with the words — a page explaining a service, a bio, a set of FAQs — it is content. List the two separately, even where the same supplier is expected to handle both, because the separation is what lets the supplier price and staff each half correctly rather than folding one into a rough estimate for the other.

Where each half is usually sourced

Website copywriting covers what is involved in having the words written professionally, which is the natural next read once a brief has flagged that content is a separate line item rather than an assumption. Web development services covers the functional side — what building and integrating features actually involves — for a business trying to work out how much of the functional list can realistically sit inside a standard design engagement versus needing dedicated development work.

What to do next

Go through the draft requirements list and mark each line F or C using the placeholder-text test above. Anywhere a single line mixes both — “an online store with great product copy” — split it into two lines, because a supplier can quote each half accurately only once they are separated, and a brief that keeps them merged is asking for one number covering two different kinds of work.