System specification is the stage in which you decide what to build before you start building it. When it is skipped, the decisions do not disappear: they get made during development, under pressure and at a higher cost.
This guide explains what a specification document is, what it must contain, how to write one in an orderly way, and how it affects price, schedule and vendor comparison. At the end you will find a checklist you can copy.
What is a system specification, and why does it save money?
A system specification is a written document that describes what the system must do, for whom, under what conditions, and how its success and correctness will be measured. It is the bridge between the business need and the code, written in language that both the client and the developers understand.
The savings come from the fact that a change on paper is far cheaper than a change in code. A mistake caught on a drawn screen costs minutes, while the same mistake discovered after launch may require rebuilding the data structure. That is why specification comes before development in our process.
A specification also serves a less obvious purpose: it forces the parties to agree on what words mean. A "report" is a printed page to the client and a screen to the developer. Until it is written down, both are convinced they are talking about the same thing.
A specification is not a contract in itself, nor a one-off document that gets shelved. It is a living document that is updated when decisions change, and it applies to every kind of project, from a brochure site or store to a full management system.
What does a good specification document contain?
A good specification document answers one question in each chapter, and is easy to review with non-technical people. It is not a thick book: a small project can make do with a few pages, as long as every needed chapter exists.
As an example, the logistics ERP we built, described in the case study a logistics ERP for Fredi furniture industries, required defining up front two different experiences: office and field teams. That is exactly the kind of decision that belongs in the specification, not in development.
An acceptance criterion is a testable condition that decides whether a feature is complete. For instance, "a user with the driver permission sees only their own work schedule". Phrasing like this allows testing without argument, rather than relying on a feeling that the screen "looks fine".
Non-functional requirements also need testable wording: what loading time counts as acceptable, which languages the system runs in, which accessibility standard applies, and where it is hosted and who backs it up. Hosting and security questions are worth settling early with hosting, security and maintenance services.
- Goals and success metrics: what the business problem is and how we will know it is solved.
- Users and permissions: who uses the system and what each role sees and can do.
- Flows and user stories, plus screens and wireframes of the interface.
- The data model and business rules: which entities exist and which rules apply to them.
- Integrations with other systems: payment, invoicing, email, messaging.
- Non-functional requirements: performance, security, accessibility, languages and hosting.
- Acceptance criteria, an out-of-scope list and development phases, including a first version (MVP).
Who writes a specification, and how long does it take?
The specification is written by someone who understands both the business and the technology, usually an analyst or senior developer working with the stakeholder on the client side. The client cannot be only a reader: the business decisions are theirs, and the specification records them.
The time needed depends on scope, number of roles, number of integrations and the availability of people for interviews. We avoid promising a universal figure, because specifying a brochure site is very different from specifying a multi-user management system. What matters is that the time is defined in advance and there is a clear deliverable at the end.
The client can make the process much easier by preparing in advance. Bring examples of the forms, spreadsheets and reports used today, screenshots of existing systems, a list of systems that must be connected, and the names of people who will use the system day to day. Real material reveals far more than a general description.
At the end of the process you receive three deliverables: a written document, screen wireframes or a prototype, and a list of open questions, each with an owner and a due date. A document that honestly marks what is still undecided is better than one that pretends everything is known and later turns out otherwise. Open questions are a legitimate part of any first specification.
How do you write a specification in a single working week?
A single focused week suits a bounded project, not a large enterprise system, which will split into several rounds of specification. The idea is to limit sprawl while writing: set a fixed order and keep to it.
Sorting into must, should and could is the most important tool of the week. "Must" is what the system is unusable without, "should" improves the work but can wait, and "could" is postponed to a later phase. This sorting defines the first version (MVP) and stops a wish list from turning into an impossible budget.
For the mapping stage, use the process we described in our piece on business automation, where you document the work as it is done today. If you want to see how system structure affects the specification, read about software architecture.
- Day one: interviews with stakeholders and end users, and mapping of the current process.
- Day two: goals, roles, permissions and the main work flows.
- Day three: sorting requirements into must, should and could.
- Day four: screens and wireframes, followed by a clickable prototype that is easy to demonstrate.
- Day five: data model, integrations, acceptance criteria and a walkthrough for approval.
Which common mistakes damage a system specification?
The most common mistake is describing a solution instead of a problem. "A green button in the corner" is not a specification but a design idea. A specification that starts from the problem leaves the developer room to propose a better solution than the one you imagined.
Many specifications also skip edge cases, such as what happens when a payment fails or when a user deletes a linked record. Requirements such as security, accessibility and languages are often forgotten until testing, and then the correction is expensive.
A third mistake is writing the specification alone, without talking to the people who will use the system. A manager knows what they want to see in a report, but only the person entering data in the field knows which fields are missing and which will never be filled in. A short interview with a real user saves an entire round of corrections.
- No acceptance criteria, so nobody knows when a screen or feature is "done".
- No out-of-scope list, so scope expands quietly.
- No change process, so every request turns into a negotiation.
- Non-functional requirements are missing or phrased vaguely, as "fast" or "secure".
How does a specification let you compare quotes and fix a price?
When every vendor receives the same document, the quotes refer to the same scope and can be compared line by line. Without a specification, each vendor makes different assumptions, and the cheapest quote is sometimes the one that assumed the costly part was not included. The way to choose a vendor is covered in how to choose a software development company.
A specification also makes a fixed price possible: when scope is known, it can be committed to, and a change is defined as a change. To understand what drives price before you have a document, read how much it costs to build a website, and use the website and systems calculator for an initial estimate.
It also helps you choose between an existing product and a custom build, a question covered in custom systems versus off-the-shelf products. Once the list of requirements is clear, it is easy to see how many of them an off-the-shelf product really covers.
When reviewing quotes, ask each vendor to map the lines of the quote to the chapters of the specification and to state what is excluded. A quote whose items cannot be tied to the document is a quote hiding assumptions. The exercise takes an hour and prevents surprises in the final bill.
What do you do about changes that surface after the specification?
Changes are a natural part of any project, and a specification does not exist to forbid them but to manage them. Each change is logged as a change request: what is asked, why, and what the effect on time and cost is. Only after written approval does it enter the work.
This procedure protects both sides. The client sees what each decision costs before approving it, and the vendor does not have to absorb additions without compensation. Set the procedure in the specification itself, before the first disagreement arises.
It is also useful to distinguish a change from a clarification. A clarification elaborates what was already agreed and does not alter scope, while a change adds or alters behaviour. The distinction is made against the approved text, so the more detailed the specification, the fewer disputes there are about what was included.
A system specification checklist, and how we work at Logicode
You can copy the list below into your own document and tick it off. If any item is missing, complete it before you ask for quotes.
At Logicode we begin with a short specification call, and a written specification is delivered for approval before any code is written. Our full process, from planning and specification through development and testing to maintenance, is described on the advanced systems development page. To begin, contact us.
- I have written the business problem and at least one success metric.
- Every user role and its permissions are mapped.
- Every requirement is classified as must, should or could.
- Each major feature has a testable acceptance criterion.
- Integrations, security, accessibility, languages and hosting are documented.
- There is an out-of-scope list and a change-request procedure.
More articles worth reading
- How Much Does a Website Cost in 2026?
- How to Choose a Software Development Company in Israel
- Software Architecture for Systems That Grow