How to Write a Technical Specification: 8 Steps for Software and Hardware Purchases, Examples and a Checklist

A technical specification is a document defining, in measurable terms, what a purchased system or service must do, where it operates and what is checked at handover. A good one answers "what" rather than "how", ties each requirement to a testable acceptance criterion and names no brand. Its core sections are scope, current situation, numbered requirements, deliverables and acceptance criteria.

Key takeaways

• A technical specification defines what the purchase must do through measurable requirements, and leaves how to the supplier.
• In Turkish public tenders, Article 12 of Law No. 4734 bans wording aimed at a brand or model; where unavoidable, only with "or equivalent".
• Panorama Consulting's 2026 ERP Report found more than a quarter of organisations went over budget, most often from an unexpected need for additional technology.
• In a good specification each requirement says one thing, carries a unique ID and is marked mandatory or desirable.
• Acceptance tests are tied to payment milestones; bids are compared in a compliance matrix built from numbered requirements and on multi-year total cost.

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.

Why do technical specifications fall short? The 4 most common mistakes

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 does a poor technical specification cost?

Unclear scope in the technical specification 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 study "Flipping the Odds of Digital Transformation Success" 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 technical 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.

Technical specifications in Turkish public tenders: what does Law No. 4734 say?

For public bodies and municipalities, the technical specification sits inside a legal framework. As of 2026, 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, brand-neutral writing 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 management, 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 public tender does not end with the technical 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 (enterprise resource planning, or 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 require the visitor's full name, the person being visited and the time of entry as mandatory fields when registering a visitor." 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 under Türkiye's Personal Data Protection Law (KVKK) 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 weak and strong clauses 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.

Technical specification checklist before publishing

• Are the purpose, scope and out-of-scope work written down on one page?
• Are existing systems, user numbers and integrations described?
• Is every requirement numbered, saying one thing and marked mandatory or desirable?
• Are performance, security and personal data clauses measurable in numbers?
• Does no clause describe a single brand or model?
• Are data migration, training, documentation, source code and maintenance on the deliverables list?
• Does every requirement have a written acceptance test tied to a payment milestone?

How do you compare bids against a technical specification?

The numbered requirements in a technical specification 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.

How do you manage specification revisions and versions?

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

Instead of carrying revisions in file names such as "final" and "final_v2", you can use SmartFiles business file management, developed by Digital Bridge: a specification uploaded to the same folder under the same name becomes a new version, the list shows who uploaded it and when, earlier versions can be downloaded, and two versions can be compared line by line. That way you can later show which version of the specification each bid was based on. To buy SmartFiles, use the Smart360 purchase page.

How does Digital Bridge help with writing technical specifications?

Digital Bridge builds software and hardware in the same team, so 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 (supervisory control and data acquisition) 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: test your current specification with one question

Open your most recent technical 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.