Statement of requirements: definition and how to write one?

There are two main types of specifications, often complementary:

The functional specification (CdCF) describes the need and the expected outcome, without stating how to achieve it. It answers questions such as: what should the product/service be used for? What functions should it perform? For which users? With what constraints? It expresses the need in terms of functions and leaves the provider free to propose the best solution. This is the client’s document.

The technical specification (CdCT) describes the means and specifications to meet the need: technologies, architecture, standards, expected performance, integration constraints. It answers the "how". This is often written by the provider or the technical team in response to the functional specification.

For a simple project, a single combined document may suffice. For a complex project, both are used in sequence.

A well-structured specification generally follows this outline:

1. Context and introduction: the organisation, project origins, stakes. Why the project exists.
2. Objectives: what the project must achieve, ideally with measurable (quantifiable) goals.
3. Scope: what is included… and especially what is excluded. Defining out-of-scope items prevents misunderstandings.
4. Needs/functions description: the core of the document. Each need is described and prioritised (essential/important/desirable).
5. Constraints: budget, deadlines, technical, regulatory, ergonomic, compatibility.
6. Expected deliverables: what must be handed over (documents, product, training, documentation).
7. Schedule and milestones: major deadlines and validation steps.
8. Acceptance criteria (testing): how compliance will be verified. Without measurable criteria, disputes cannot be resolved.
9. Terms: budget, response conditions, contacts, governance.

The golden rule: the more precise and prioritised the needs, the less the project drifts. A vague specification opens the door to misunderstandings, change requests and overruns.

What makes a good specification:

• Clear prioritisation: distinguishing essentials from nice-to-haves prevents treating everything equally (MoSCoW method: Must/Should/Could/Won’t).
• Measurable criteria: "the page must load in under 2 seconds" rather than "the site must be fast".
• Defined scope: explicitly state what is out of scope.
• A single reference document, shared, versioned and validated by both parties.

Once the project is underway, the specification becomes the compass: it frames testing, arbitrates change requests and measures progress against planned deliverables. This is where a project management tool takes over, turning specification needs into tasks, milestones and tracking.

Orizen’s Project Management does exactly this: it breaks down a specification into a concrete action plan—task breakdown, assignment, deadlines and progress tracking—so the document doesn’t gather dust once the project starts.