How to Write a Technical Specification for Software and Hardware Purchases: Step-by-Step Guide and Checklist

A technical specification defines, in measurable terms, what the software, hardware or service you are buying must do, the conditions it will operate in and what will be checked at handover. A good specification answers "what" rather than "how", ties every requirement to a testable acceptance criterion and does not describe one brand.

This guide explains how to write one step by step, for private purchases and for public tenders under Türkiye's Public Procurement Law No. 4734, how to strengthen weak clauses and which mistakes to avoid. The other steps before a purchase are collected in our complete Digital Transformation guide.

What actually happens when specifications are written

Specifications are usually written under time pressure. Procurement sets a deadline, and the technical team reaches for the nearest example: another organisation's specification, a supplier's brochure or last year's tender documents. A few clauses are edited and the document goes out.

The consequences are familiar:

• Unmeasurable wording. Clauses such as "the system must be user-friendly" or "must perform well" become arguments at handover, because nobody wrote down what "well" means.
• A hidden brand description. A feature list copied from one product's brochure unintentionally describes something only that product can deliver. In a public tender this invites complaints and cancellation; in the private sector it destroys your negotiating position.
• Missing scope. Data migration, training, integration, maintenance and source code are left out, only to return as "additional work" once the project is under way. We cover source code and IP clauses in software contracts and source code.
• No acceptance criteria. Nobody defined when the work counts as finished, so handover and payment drag on.

What a poor specification costs

Unclear scope is one of the main reasons projects overrun on budget and schedule:

Panorama Consulting's 2026 ERP Report found that more than a quarter of organisations went over budget and almost a quarter went over schedule; the most common cause of budget overruns was an unexpected need for additional technology. (Panorama Consulting, The 2026 ERP Report)

An "unexpected need" is, in large part, a need nobody wrote down at specification stage; the same pattern comes up again and again in our analysis of why ERP projects fail. On a broader scale, BCG's 2020 research found that 70% of digital transformations fall short of their objectives, and goals that were never clearly defined at the outset are a common thread.

Finding the right person to write the specification is not easy either. The TurkStat ICT Usage Survey in Enterprises, 2026 shows that only 15.2% of Turkish enterprises employ ICT specialists, and 31.7% of those trying to recruit them reported difficulties. Where in-house technical knowledge is limited, the structure of the specification has to be clear enough to compensate.

The rule that governs public tenders in Türkiye

For public bodies and municipalities, the technical specification sits inside a legal framework. Article 12 of Türkiye's Public Procurement Law No. 4734 requires technical criteria to preserve competition and equal opportunity. Specifications may not name a particular brand, model, patent, origin, source or product, nor include features aimed at one brand or model. Only where no standard exists, or where naming one is unavoidable to describe the requirement, may a brand or model be mentioned, and then only with the words "or equivalent". For a municipality the specification is usually one part of a wider municipal digital transformation plan; in smart city applications that involve sensors and city data, clauses on data ownership and open interfaces matter even more.

In practice, that means deriving the feature list from the need, not from a brochure. Instead of "brand X card reader", you write "a terminal that reads 13.56 MHz RFID cards, is rated IP65 and connects to central software over the network". To see which functions an access control purchase usually brings together (door control, staff attendance, visitor QR codes, canteen meal counting), see our card access control guide and our SmartPass page; in the specification itself, those functions are written as needs, not product names. The same discipline sharpens price competition in private purchases, and a requirement tied to a function rather than a model stays valid when you later change products.

A tender does not end with the specification. Clarification questions, addenda and bid files usually travel by email, which makes fake "last-minute change" messages an easy attack. We explain how to protect that correspondence in tender and bid email security.

How to write a technical specification in 8 steps

1. State the purpose and scope. On one page, describe the business problem the purchase solves, who will use it and what is explicitly out of scope. Out-of-scope items matter as much as in-scope ones. If you cannot decide which process to tackle first, start with our method for prioritising automation candidates.
2. Describe the current situation. Existing systems, number of users and sites, data volumes, network set-up and the software you need to integrate with (ERP, accounting, e-invoicing, identity management). Bidders cannot price accurately without this; for every system that needs a link, also note which way and how often the API integration should run.
3. Number the functional requirements. Each requirement should say one thing and carry a unique ID: "R-12: The system shall generate a single-use QR code for visitors." Numbering makes bid comparison and acceptance testing far easier.
4. Make non-functional requirements measurable. Performance, concurrent users, availability, backup frequency, security (authorisation, logging, encryption) and data protection requirements should be expressed in numbers. Where personal data is processed, write the retention period and disposal step as clauses too; our KVKK compliance steps give the framework.
5. Separate mandatory from desirable. Mark each requirement as mandatory or desirable. Desirable items earn points in evaluation but do not disqualify a bid.
6. List the deliverables. Software, hardware, installation, data migration, training, user and administrator documentation, source code or access to it, and maintenance and support terms. Each of these is a separate budget line; we show which ones are most often missed in digital transformation cost factors.
7. Write the acceptance criteria. For each requirement, define how it will be tested, in which environment and with what data. Link acceptance tests to payment milestones. How to run these tests through the project is covered in supervising software contractors. In regulated sectors such as pharmaceuticals these tests form part of system validation; we cover how to specify audit trail and access requirements in GMP data integrity and ALCOA+.
8. Get an independent review. Ask someone reading it for the first time, ideally an expert outside the purchase, to go through it. Put two questions to every clause: "How will I check this at handover?" and "Does this describe a single brand?"

Weak and strong clauses

The figures in the table are only examples; set your own values from your actual usage and business needs. We cover how to gather requirements in our software requirements analysis guide, and how to plan the bigger picture in our digital transformation roadmap.

How to compare the bids

Numbered requirements let you build a simple compliance matrix, with requirement IDs down the side and bidders across the top; in each cell write "meets", "partly" or "does not meet" plus the page reference in the bid. For private purchases, ask for a scripted demo in which three or four critical requirements are shown with your own sample data rather than a general presentation. Compare prices over a multi-year total cost, including licences, maintenance and extra development, not just the initial figure; we break down the items in software development cost, and our criteria for choosing a software company help with assessing the bidders themselves.

A specification never stands alone; it is revised together with the drawings, calculations and correspondence attached to it. How to keep that document set per project, versioned and permissioned, is covered in our architecture firm file management guide. How the same revisions tie into the schedule and site reports on a building project is covered in construction project management software.

How we approach this at Digital Bridge

Because we build software and hardware in the same team, we see from both sides where a specification turns into a dispute on site. We put that experience to work helping organisations write the right document:

• Needs analysis and a draft specification. Through our consultancy services we review your processes and existing systems and prepare a numbered, measurable, brand-neutral draft.
• For public bodies. In our public sector and municipal work we work on documents that stay open to competition, follow the "or equivalent" principle and define acceptance tests clearly.
• Technical validation. We check that requirements are technically realistic; for projects involving hardware, the technical feasibility assessment is free of charge.
• Integration and security clauses. We write links to your existing software drawing on our system integrations work, and data protection requirements drawing on our data protection compliance experience.

We apply the same discipline to our own projects. We do not sell ready-made packages: every engagement starts with a needs analysis and continues with a written proposal that sets out scope, stages and cost. In our custom SCADA projects the source code belongs to the client with no additional licence fee; putting clauses like this in the specification from the start keeps them off the negotiating table later.

Your next step

Open your most recent specification and ask one question of every clause: "How will I measure this on handover day?" Clauses with no answer are the ones to fix. Then get in touch; we can review your draft with you or build the specification together, starting from a needs analysis.