EU Funding

How to write technical specifications that survive evaluation

The technical specifications in a dossier live two lives: first they convince the evaluator that you know what you are buying, then they become the terms of reference against which the solution is built and accepted.

Northdan Soft is a software supplier, not a funding consultancy, and is not affiliated with any managing authority or development agency. Programme information is indicative — always check the conditions in the programme's official applicant guide.

The most underestimated trap in technical specifications is their dual nature. At evaluation the text has to be precise: functionality named explicitly, measurable results, criteria by which anyone can establish that the solution exists. During implementation the same text becomes binding — acceptance and reimbursement are checked against it word by word. Specifications written merely to sound impressive produce two symmetrical failures: vague ones fail at evaluation because nobody understands what is being purchased, and inflated ones fail at acceptance, when somebody notices that the real application does not do what the dossier claims. The balance is achieved by writing requirements at the level of system behaviour — what it has to do, for whom, with what verifiable result — and leaving open the technology details that can change over two years of a project. Northdan drafts specifications on exactly that principle, as the developer who will also have to execute them: we do not put anything into a dossier that we could not build and hand over.

Let’s talk about your project

Message us on WhatsApp or send an email — you talk directly to a developer.

Message us on WhatsApp Send an email

office@northdan.com · +40 752 070 247

How we help

Requirements phrased so they can be verified

Every requirement is written so that at acceptance it can be answered with yes or no, without interpretation — exactly the way the committee will judge it.

A level of detail calibrated to evaluation

We go into as much detail as the call's grid demands and avoid getting lost in technical minutiae that block implementation at the first change of context.

Written by the people who will build them

The specifications come from the development team, not from a copywriter: we know what is feasible, how long it takes and how it is demonstrated at the end.

The right level of detail: behaviour, not technology

The healthy formulation describes what the system does: order management with configurable states and a full history of changes, rather than a modern, high-performance application. The first is verifiable at acceptance; the second means nothing and the evaluator scores it accordingly.

Symmetrically, avoid casting library versions, languages or specific commercial products into the dossier unless the guide expressly requires it. The project is implemented months or years after it is written, and a specification imposing a technology that has since been superseded forces you either to deliver something suboptimal or to notify changes to the financing authority.

The structure that works in practice

We start from the company processes the project digitalizes and derive modules from them, and from the modules individual numbered requirements — each with its intended user and its expected result. The numbering is not pedantry: at acceptance, the report can refer to specific requirements, and at evaluation the grid immediately finds what it is looking for.

We then add the relevant non-functional requirements — the number of simultaneous users, security and data protection requirements, the environments the solution runs on — and the acceptance criteria. The whole thing is reconciled with the offer and the budget: every requirement has a cost, every cost has a requirement.

This way of working also makes the specification usable in the procurement procedure, where the call requires several offers to be compared: numbered requirements mean offers comparable line by line.

How specifications are produced with us

You describe the workflows you want to digitalize — sales, production, stock, customer relations — and the call you are targeting; we turn that into a structured set of specifications, reconciled with the technical offer and the budget breakdown we prepare in the same package.

The roles stay as they are known: your consultant builds the funding application and the scoring strategy; we answer for the technical content and for the fact that it can be delivered exactly as written.

Frequently asked questions

How detailed do the technical specifications in a dossier have to be?

Detailed enough for an evaluator to understand exactly what is being purchased and for acceptance to happen on objective criteria — as a rule against numbered items of functionality rather than a general paragraph. Pure implementation details are left flexible, unless the guide requires otherwise.

Can I change the technology at implementation compared with the specifications?

If the specification describes the behaviour of the system, the choice of technology normally stays with the supplier and a change does not affect the dossier. If, however, the dossier fixed a technology or a product explicitly, the change has to be handled under the financing contract, sometimes with a notification or an addendum.

Who should write the specifications: the beneficiary, the consultant or the supplier?

The technical content should come from someone capable of executing it — otherwise the dossier promises things the implementation cannot honour. In practice it works as a trio: the beneficiary brings the real processes, the supplier turns them into feasible requirements, the consultant fits them into the logic of the call.

What happens at acceptance if the application does not cover a requirement in the specifications?

Acceptance is done by comparison with the specifications in the dossier, so an uncovered requirement blocks the signing of the acceptance report until it is remedied — with direct pressure on the project deadline. That is why we refuse to put decorative functionality into specifications purely for scoring.