How a specification for an IT project is written

A specification is not for the developer but for the client. A developer will write code without one — just not the code you wanted. The document fixes what exactly will be built and turns "but we agreed" into something checkable.

The short answer

A working specification covers seven blocks:

• the project goal and success metric;
• user roles;
• working scenarios;
• screens and structure;
• integrations and data;
• non-functional requirements;
• boundaries: what is not part of the project.

The last point saves the most money.

What each block covers

Goal and metric

Not "build a website" but "collect trial-session requests from the site so the administrator is not answering the same questions". Everything else grows from the goal: if a feature does not serve it, it can be dropped.

Roles

Who uses the system and what each of them can do. Customer, manager, director, administrator — each with their own screens and permissions. The number of roles affects the budget more than the number of screens.

Scenarios

The sequence of steps from start to result. For example: a visitor finds the service → sees the price → fills in the form → gets a confirmation → the manager sees the lead in the system.

Scenarios also describe exceptions: what happens if payment fails, if the item is out of stock, if the user closes the tab.

Screens and structure

The list of pages and what is on each. Not the design but the content: which blocks, which fields, which actions are available.

Integrations and data

What the system connects to: payment gateway, CRM, accounting software, email, telephony. For each: what is transferred, in which direction, and what happens when the service is unavailable.

Non-functional requirements

Load speed, language versions, supported devices and browsers, backup requirements, access separation.

Project boundaries

An explicit list of what is not included: catalogue content, photography, copy, promotion, a mobile app. This is the only way to avoid an argument at handover.

The most useful page in any specification is the list of what the project does not include. It is usually the page nobody writes.

Who writes the specification

The workable route: the client describes the business task and the processes, and the contractor turns that into scenarios, screens and requirements.

How to read a specification without a technical background

• **Find your task.** If the business goal is not in the opening paragraphs, the document was not written for you.
• **Walk the scenarios.** Go through them as a user: is everything logical, are any steps missing?
• **Read the boundaries section.** Make sure nothing you assumed was included sits there.
• **Ask about exceptions.** What happens on a payment error, on cancellation, with no internet.
• **Confirm who supplies content.** Copy and photography are the most common cause of missed deadlines.

What happens without a specification

• every new idea looks like a "small tweak" and the quote grows unnoticed;
• deadlines slip for no visible reason;
• at handover it turns out the two sides understood the task differently;
• changing contractor becomes impossible because nobody knows what was supposed to be built.

How that affects the budget — why projects overrun.

An example from Synergy practice

Client: a leasing company that had already made two unsuccessful attempts.

What had gone wrong before: work started with design, scope was never fixed anywhere, and every iteration returned to discussion.

What we did: mapped processes and roles, gathered the scenarios, fixed integrations and boundaries, and only then moved to design and development.

Result: the project reached launch, and no disputes arose at handover.

See the Top Leasing & Credit case →

Frequently asked questions

How long does writing a specification take?

For a website, 3–5 days. For a system or product, one to three weeks depending on the number of roles and integrations.

Is it paid work?

Usually yes, if we mean a full document with scenarios and integrations. It is analyst work, and it protects the development budget itself.

Can the specification change during the project?

It can and should, but through explicit change control: a change in scope means a change in timeline and cost. What matters is that it happens deliberately.

How detailed should it be?

Detailed enough that another developer could understand the task without you. That is a good test.

Conclusion

A specification is not bureaucracy but a budget management tool. It turns agreements into checkable items and lets both sides know what counts as completed work.

Synergy starts projects by mapping processes and writing the specification, fixing scope, timeline and cost before development begins. You can discuss a project during a free initial audit.