The specification document: what it must contain

A specification document states what is expected of a project or a supplier: the need, the scope, the constraints and the criteria on which the result will be accepted. Its function is not to describe a solution — that is the answer’s job — but to define the problem precisely enough that two different suppliers would understand it the same way, and that acceptance can be pronounced without argument.

Start with the need, not the solution

The most common failure is a specification that already contains the solution: screens, technologies, a chosen architecture. It closes off better answers, it transfers the design risk back to you, and it makes acceptance impossible to argue — you cannot refuse a delivery that implements exactly what you drew. State the business need, the process it must serve and the outcome expected; leave the “how” to the response.

What has to be in it

The context and the objective pursued. The functional scope, and just as explicitly what is out of scope. The non-functional requirements — volume, performance, availability, security, accessibility, hosting and data-residency constraints. The interfaces with the existing landscape. The planning constraints and immovable dates. The acceptance criteria. And the governance: who decides, who accepts, at what rhythm.

Every requirement must be verifiable

“The application must be fast” cannot be accepted or refused. “A search returns in under two seconds for 95% of queries at 200 concurrent users” can. The test is simple: for each line, ask what you would measure to say it is met. Any requirement that survives without an answer belongs either in the context section or in the bin — keeping it guarantees a dispute at acceptance.

Scope out is worth more than scope in

What a specification excludes protects the project far more than what it includes. Naming what is deliberately left out — the second country, the migration of old data, the mobile app — kills the ambiguity that otherwise reappears as an unbudgeted expectation in month five. It is also the only way a change request can be recognised as one instead of being absorbed silently.

From specification to project in FoxPlan

In FoxPlan the requirements live as project objects, each linked to the tasks that implement it and to the deliverable that will be accepted, so coverage is a reading rather than a manual cross-check. What was excluded stays written next to what was agreed, and the project keeps a durable trace of what it committed to — the document that makes an acceptance conversation short.