A technical specification for an IT project is the document that describes what the future system has to do, under what constraints it works and by which signs the work will be accepted. A good specification is not a wish list but a set of verifiable requirements: different contractors quote for the same scope, and acceptance follows criteria agreed in advance.
Key takeaways
A technical specification is the main project document: it links the business task to the requirements for the system and to the rules of acceptance. It is often confused with neighbouring documents, although different people write them at different moments.
| Document | Who usually writes it | What is inside | When it is needed |
|---|---|---|---|
| Brief | The client | The task in business terms: what gets in the way, what you want to achieve, the budget range | At the very start, before talking to contractors |
| Technical specification | An analyst together with the client | Goals, scope, processes, functional and non-functional requirements, integrations, acceptance criteria | Before the cost estimate and the contract |
| Software requirements specification (SRS) | An analyst on the supplier side | Detailed product requirements: scenarios, screen states, error handling, calculation rules | Inside development, expanding the technical specification |
| Statement of work (SOW) | The project manager and a lawyer | Scope of work, stages, deliverables per stage, responsibilities and payment terms | As an annex to the contract |
The names and boundaries of these documents differ between companies, so a contract should name the list of sections and what counts as the agreed version rather than simply say «the specification». The general frame is described in the international standard ISO/IEC/IEEE 29148:2018: it defines the requirements processes and the characteristics that make a requirement fit for use.
The set of sections barely depends on whether you are building a CRM, a portal or a mobile application: the contents change, the structure does not. The table below is a working table of contents for assembling the document and checking that nothing is missing.
| Section | What to write | Example |
|---|---|---|
| Project goal | Which business task the system solves and how you will see that it has been solved | Cut the time to build the monthly report: data is now merged by hand from three systems |
| Scope | What is in the project and what is out — the second matters more than the first | Warehouse and purchasing are in, payroll stays in the accounting software |
| Current processes | How the work runs today: who does what, where data comes from, where it is typed by hand | A diagram of order intake from first contact to shipment with every participant |
| Roles and permissions | Who uses the system and what each role can see and do | The storekeeper sees stock levels but not cost prices or purchase terms |
| Functional requirements | What the system does, one verifiable requirement per item | The system assigns an owner to an enquiry by the routing rule and notifies that person |
| Non-functional requirements | Load, speed, availability, security, interface languages, devices | Up to 50 concurrent users, interface in Russian and Uzbek |
| Integrations | What data is exchanged, in which direction, how often and which side is the source of truth | Stock levels arrive from the accounting system hourly; the warehouse is the source of truth |
| Data and where it lives | What is stored, for how long, where the database and the backups physically sit | Customer personal data: what is collected, the retention period, the hosting location |
| Data migration | What is moved from the old systems, in what form and as of which date | Reference data and stock as of the launch date, order history for the two previous years |
| Acceptance criteria | Which checks confirm that the work is done | Twenty orders travel from enquiry to shipment with no manual edits in the database |
| What stays with the client | Source code, documentation, access, rights to the result | Code in the company's repository, user instructions, access to the servers |
The section on current processes is easier to draw than to describe: a diagram in a common notation such as BPMN 2.0 by OMG is readable both by a manager and by a developer. Data location is worth fixing early as well: mandatory storage inside Uzbekistan applies to biometric and genetic data and to data of telecom subscribers under article 27-1 of the personal data law, while other data may be stored abroad if the conditions of the same article are met.
A requirement is fit for use when it cannot be read two ways and can be verified. Among the characteristics of a good requirement, ISO/IEC/IEEE 29148 lists necessity, unambiguity, singularity, feasibility and verifiability — one requirement describes one thing and comes with a clear way to check it.
| Bad | Why it fails | Good |
|---|---|---|
| A convenient interface | Cannot be verified and cannot be estimated in hours | Placing an order takes no more than four screens and needs no switching between windows |
| The system must be fast | No number and no conditions under which it is measured | A list of 10 000 orders opens in 2 seconds with 50 concurrent users |
| Integration with the accounting system | Does not say what moves, in which direction and how often | Stock levels are sent from the accounting system hourly; on an exchange error the owner is notified |
| Sales reports | Nobody knows which ones and who needs them | A «revenue by sales manager for a period» report with a channel filter and export to a spreadsheet |
| The system must support growth | No boundary up to which growth is considered covered | The system is designed for 200 users and a threefold increase in orders without changing the architecture |
Number every requirement: the numbers are later used in the estimate, in the work plan and in the acceptance certificate. A requirement containing «and», «or» or «if necessary» usually breaks into two or three — it is better to split it straight away.
An acceptance criterion describes a check whose outcome does not depend on the mood of either side. Without one, an argument about whether the project is finished is settled by persuasion rather than by the document.
Example The phrase «we need a CRM» works neither for an estimate nor for acceptance. A workable version reads: «Every enquiry from Telegram, the website and the phone lands in one system with its source recorded; the manager can see the pipeline for any day; acceptance checks 20 enquiries across all three channels».
The mistakes repeat from project to project, and nearly all of them come from writing the document without understanding how the company works.
There are three options, each with its own price and its own risk. The choice depends on whether there is someone inside who can write requirements and on how expensive a mistake in the project would be.
Important Syntra Systems is a development company, so we state our interest up front: any solution we propose has a side on which we earn. In the specification we mark separately everything that can be closed by configuring systems you already own and by changing the rules, with no development at all, and we hand the document over in editable form — you can take it to any contractor.
Preparation starts not with the document but with a review of how the company works: otherwise the requirements describe an idea of the process rather than the process. The order of the steps barely changes, only the depth of each one.
How long preparation takes depends on the number of processes, systems and participants, so the scope is estimated after the review. Reviewing processes and finding where money leaks is separate work, described in the articles on the IT infrastructure audit and on how IT consulting works.
Before you send the document out for quotes, walk through the list. Every item left undone is a future change request.
Check separately that every contractor received the same version of the document. Otherwise the quotes are not comparable, and the choice comes down to comparing totals that cover different amounts of work.
A detailed specification works well where the subject area is understood and stable: accounting, document flow, integrations, moving an existing process into a system. It works worse in products where value is tested on users and requirements change along the way.
Agile approaches start from the assumption that requirements will change: the Agile principles propose welcoming changing requirements even late in development and treating working software as the primary measure of progress. Hence a different toolkit — a backlog, user stories, acceptance by sprint.
In practice the two are combined. A framework specification fixes the goals, the scope, the non-functional requirements, the integrations and the rules of acceptance — the parts that rarely change. Detailed functionality lives in the backlog and is refined as you go, while changes of scope pass through an agreed procedure: estimate, client decision, updated plan.
We do not list a priced «technical specification» service on our site: the review and the specification are the first stage of development, and their scope is estimated once the boundaries of the project are set. On ERP projects this stage is named in the scope of work: we describe the processes, the document flow and the decision points, design the data model, prepare the specification and agree the stages — the scope and prices are on the ERP page.
We do not call comparing contractors' quotes a service of ours: we are a development company and an interested party in such a comparison. There is a separate tool for that task — a directory of suppliers, which we described in the article on how IT Caravan came about.
In our work we start with the review and finish with a document you can both quote against and accept by: goals, scope, processes, numbered requirements, integrations, acceptance criteria and a plan of stages. The specification stays with the client in editable form together with the process diagrams.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
For a small change, yes: a description of the task and a definition of done are enough. For a project worth real money you can neither compare contractors' quotes nor close the work without one: acceptance runs into two different readings of what was ordered.
There is no norm: the length follows the number of processes, roles and integrations. The sign of a poor document is not its size but sections nobody will check at acceptance. A requirement that cannot be verified adds no value however many pages it fills.
That is a matter of contract. The transfer of rights to the result, to the source code, documentation and access is written down before the work starts, along with the moment when they pass to the client. If the contract is silent, the dispute is settled by general rules rather than by your expectations.
Its framework part is needed: goals, project scope, requirements for speed, load and security, integrations and acceptance rules — these rarely change. The feature list is kept separately and refined along the way, and every change in scope follows the same order: estimate, the client's decision, then an update to the plan.
The client does — either separately or as the first stage of development. With us, discovery and the specification form the project's first stage; we price it once the scope is defined, and hand over the document in editable form, so you can take it to any contractor.
Take any requirement and ask how you would verify it and who would do that. If every item has an answer, and the document describes the scope boundaries and the acceptance procedure, it works. If the answers are missing, an argument at handover is guaranteed.
