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

A technical specification is the document that 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 stays open to competition instead of describing one brand. This guide explains how to write one step by step, for private purchases and for public tenders in Türkiye, and which mistakes to avoid.

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. 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".

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), take a look at our SmartPass page; in the specification itself, those functions are written as needs, not product names. The same discipline also sharpens price competition in private purchases, and a requirement tied to a function rather than a model stays valid when you later change products.

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.
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.
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.
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.
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.
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

A well-written specification also makes evaluation easier. Because requirements are numbered, you can build a simple compliance matrix: requirement IDs down the side, bidders across the top, and in each cell "meets", "partly meets" or "does not meet" with a page reference to the bid.

For private purchases we suggest adding three more things:

• A scripted demo. Rather than a general presentation, ask each bidder to demonstrate three or four critical requirements using your own sample data.
• Total cost. Compare not just the initial price but licences, maintenance, support, hardware refresh and likely additional development over a multi-year horizon. We break down the cost items in software development cost.
• An open-questions log. Send every ambiguity as a written question and attach the answers to the contract. Our criteria for choosing a software company help when assessing the bidders themselves.

In public tenders the evaluation method is set in the administrative specification, but the quality of the technical compliance check still depends on how measurable the technical specification is.

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.