Checklist: writing a specification for a public IT tender
For: Contracting authorities and public-sector project leads
Updated: 2026-11
A specification for a public IT tender is created in seven steps: describe goals and starting point, formulate requirements with priority and acceptance criteria, keep technical specifications product-neutral, set suitability criteria, define award criteria with weighting and scoring method, create a comparable price sheet and review the documents before publication.
The quality of a tender is decided in the specification. Unclear requirements lead to incomparable bids, many questions and, in the worst case, appeals. Overly narrow requirements exclude good suppliers.
This checklist is for contracting authorities and project leads. Procurement law sets the framework; requirements engineering provides the method.
The checklist
- 01
Describe goals and starting point
Describe problem, goals, system environment and constraints so suppliers understand the task.
Done when: The starting point is described so an external supplier can place the task without asking.
- 02
Formulate requirements
Formulate functional and non-functional requirements unambiguously, prioritised and with acceptance criteria.
Done when: Every requirement is unambiguous, prioritised and verifiable.
- 03
Keep specifications product-neutral
Write technical specifications without brand names, or only with “or equivalent”.
Done when: The specification contains no requirements that needlessly prescribe a specific product.
- 04
Set suitability criteria
Choose criteria necessary for the contract with clear evidence.
Done when: Every suitability criterion relates to the contract and has defined evidence.
- 05
Define award criteria and scoring
Set criteria and weighting and describe the scoring method, including for price, transparently.
Done when: Criteria, weighting and scoring method are in the documents.
- 06
Make the price sheet comparable
Provide a price sheet asking for all relevant costs over the term.
Done when: The price sheet allows direct comparison of bids over the full term.
- 07
Review before publication
Check the documents for contradictions, completeness and clarity, ideally by someone not involved.
Done when: A review is documented and contradictions found are resolved.
Common mistakes
- —Copying requirements from a known supplier’s proposal.
- —Setting suitability criteria so high that hardly any SME can meet them.
- —Evaluating price without lifetime costs.
- —Engaging external consultants without clarifying prior involvement.
What this checklist does not cover
- —The checklist does not replace procurement law advice; choice of procedure and deadlines follow the PPA, IVöB and cantonal law.
- —Bid evaluation is not covered by this checklist.
- —Your organisation’s own requirements, for example on information security, apply in addition.
Parent service: Custom Software Engineering
Matching offers
Specifications for public IT tenders
We prepare the specification of an IT tender for contracting authorities: requirements elicitation following IREB with the business units, product-neutral requirements with acceptance criteria, proposals for suitability and award criteria with a scoring method, and a price sheet that makes bids comparable over the term. Responsibility for the procedure stays with the authority.
Requirements analysis (IREB)
We elicit, document and validate requirements following the IREB Certified Professional for Requirements Engineering method: identify stakeholders, elicit requirements in workshops, model processes in BPMN 2.0, write acceptance criteria and deliver a requirements catalogue the client can formally sign off. A basis for tenders, development or standard software.
FAQ
May brand names appear in the specification?
In principle only where a description is otherwise impossible, and then with “or equivalent”.
How detailed must requirements be?
Detailed enough to make bids comparable, but open enough for suppliers to bring in their solution.
Can a consultant write the specification and bid later?
Only if the competitive advantage from prior involvement can be offset. This should be clarified before the consulting engagement.
More checklists
Checklist: taking out cyber insurance without jeopardising cover
Cyber insurance is taken out properly in seven steps: clarify needs and risks, implement the baseline measures the insurer requires, answer the questionnaire honestly and checked by IT, compare cover and limits, understand exclusions, add emergency rules to the incident response plan and keep evidence current.
Checklist: securing MCP servers and AI agents
An MCP server is secured in seven steps: narrowly limit the use case, grant least privilege per tool, use dedicated credentials instead of shared accounts, tie consequential actions to human approval, treat content from external sources as data, log all calls and introduce new servers through an approval process.
Checklist: creating a first business continuity plan
A first business continuity plan is created in seven steps: identify critical processes, assess the impact of an outage, set recovery objectives, describe fallback procedures for each critical process, make contacts available offline, exercise the plan and update it regularly.