Before a software project is commissioned, there is one question that determines the budget, schedule and nerves: What exactly should the end result be? The specification answers this question from the client's perspective, while the obligation specification answers it from the contractor's perspective. If you clearly separate the two documents, you can compare offers that are truly comparable later on and are less likely to argue about what was "actually clear".
This guide clarifies the terms, shows the structure of both documents and takes you step by step through the process of writing a specification. At the end, you will find a template to download.
A distinction beforehand: This is about software and digital projects (individualised software, online shops, apps, interfaces). In mechanical and plant engineering, the same terms apply, but sometimes different standard details. The definition used here follows DIN 69901-5, the standard for project management terms.
Specification vs. specifications: the difference in one sentence
The DIN 69901-5 defines the specifications as the "entirety of the requirements specified by the client for the deliveries and services of a contractor within a contract". Simplified: the what and the what for. The client writes it before inviting tenders.
The same standard describes the specifications as the "realisation specifications drawn up by the contractor based on the implementation of the specifications specified by the client". Simplified: the how and the with what. The contractor writes it as an answer and thus determines how he wants to solve the requirements technically.
The order is therefore fixed: first the specifications, then the requirements specification. One is the question, the other is the binding answer.
| Criterion | Specification | Functional specification |
|---|---|---|
| Answered | What? For what? | How? With what? |
| Created by | Client (you) | Contractor (agency/service provider) |
| Time | Before the tender | After order clarification, before implementation |
| Detail | Requirements, objectives, Framework | Concrete technical solution |
| Purpose | Make offers comparable | Determine binding implementation |
| Legal role | Basis of the tender | often becomes part of the contract |
A common mnemonic: The specifications are the burden that the client places on the contractor. The requirements specification is the obligation that the contractor derives from it and accepts.
Was gehört-ins-lastenheft?
A requirements specification does not have to be thick, but it does have to be complete. It describes requirements in an open-ended way, i.e. without anticipating the solution. "The system must automatically transfer orders to the accounting department" belongs in the specifications. "The system uses a REST interface to DATEV" is already a solution specification and therefore a question for the requirements specification. This limit is the most common stumbling block of all, and it runs through the rest of this text.
These components should be included in a robust requirements specification:
- Initial situation and goal. Why does the project exist? What problem does the software solve, what is the business objective behind it? One or two paragraphs, not a novel.
- Actual state. What systems, processes and data exist today? What will remain, what will be replaced?
- Target status and functional requirements. What must the solution be able to do? This is the centrepiece. Each requirement is given a unique number, a clear description and a priority (e.g. must, should, can).
- Non-functional requirements. Performance, availability, security, data protection, scalability, accessibility. In concrete terms, this means, for example: "The system supports 200 simultaneous users without a response taking longer than two seconds." These points are rarely on the initial wish list and end up being expensive upgrades.
- Interfaces. Which systems does the solution need to talk to? ERP, merchandise management, CRM, payment, shipping. Example: "Connection to the existing ERP system via nightly batch export." Name, do not specify, because the contractor is responsible for how.
- Framework conditions. Budget corridor, time frame, legal requirements (GDPR, industry-specific requirements), desired or excluded technologies.
- Acceptance criteria. What is used to measure whether the result is correct? For example: "A test customer completes the order, payment and invoicing process in the real system without errors." If you don't define "done", you will negotiate it later under time pressure and usually to your disadvantage.
The most important part is the functional requirements, and this is precisely where the most sloppy work is done. A good requirement is testable. "The search should be fast" is not testable. "Search results appear in under 500 milliseconds for up to 50,000 articles" is. Understanding the difference between these two sentences is half the way to a usable requirement specification.
What belongs in the requirement specification?
The requirement specification takes up every requirement in the requirement specification and answers it specifically. In it, the contractor shows that they have understood the specifications and specifies the technical realisation in a binding manner. The principle is simple: for every requirement in the specifications, there is exactly one answer in the functional specification.
Typical components:
- Solution concept for each requirement: How is requirement no. 12 implemented technically?
- System architecture: Technologies used, components, data model, infrastructure.
- Interface specification: concrete protocols, data formats, endpoints.
- Quantity structure and load assumptions: which data and user quantities are expected.
- Test and acceptance concept: how it is demonstrated that each requirement is fulfilled.
- Project plan: phases, milestones, delivery dates, responsibilities.
If a requirement in the specification sheet remains unanswered, this is a warning signal, not a detail. It either means that the provider has overlooked the requirement or has deliberately not included it. You want to know both before commissioning, not afterwards.
Important for contract design: The requirements specification is part of the contract in many projects. What it says is what is owed. In case of doubt, what is not included is not. It is therefore worth reading the service provider's specifications just as seriously as they read your specifications.
Writing specifications: step by step
As the client, you write the specifications yourself, because only you know your processes. A tried-and-tested process:
Step 1 - Define goals and framework Start with the why, not the functions. A project without a clear business objective produces a specification sheet that can later be expanded at will. This is exactly what drives up effort and costs.
Step 2 - Gather stakeholders. Talk to the people who will be working with the solution on a daily basis. The specialist department knows requirements that the management is not even aware of. This round will save you the most expensive changes later on.
Step 3 - Collect and structure requirements. First collect broadly, then organise. Group by topic, assign unique numbers and formulate each requirement as a verifiable sentence.
Step 4 - Prioritise. Not everything is equally important. A simple must/should/can prioritisation (or MoSCoW: Must, Should, Could, Won't) turns a wish list into a basis for decision-making. The test: if everything is a "must", nothing is a "must" any more - then the budget decides in the bottleneck instead of you doing it.
Step 5 - Add non-functional requirements Go through the list consciously: Privacy, security, performance, availability, accessibility, maintainability. These points are rarely on the first wish list, but are nevertheless decisive for the quality.
Step 6 - Have the specifications proofread. Give the specifications to someone who was not involved. If they understand what needs to be built, the suppliers will understand it too. If they don't understand it, they will receive incomparable offers.
A rough guide to the scope: Experience has shown that for a medium-sized customised software project, a usable specification comprises around 10 to 30 pages. This is not a standard value, but a rule of thumb. Significantly shorter usually means too vague, significantly longer often means that solutions have already been specified that belong in the requirements specification.
The mistakes that cost the most in practice
The same stumbling blocks are repeated when writing requirements specifications. They are all avoidable if you know them:
The most expensive mistake is to describe the solution instead of the requirement. If you specify the technology in the requirements specification, you give away the expertise of the provider and rule out better solutions before they are even proposed. Describe the goal, not the path.
Almost as common are untestable requirements. "User-friendly", "modern", "high-performance" are wishes, not requirements. What is not measurable is not removable, and you end up arguing about whether the result is "modern enough" without ever having a common yardstick.
A third classic: forgetting non-functional requirements. Discovering security and data protection only shortly before go-live means, in the worst case, that parts of the architecture have to be rebuilt. This is the most expensive time for a finding that should have been included in the specifications.
If you don't prioritise, you lose the basis for decision-making in a conflict. Without a must/target/can, the budget bottleneck will lead to cancellations based on gut feeling, and often the wrong things are cancelled.
And finally: leave acceptance criteria open. If "finished" is not defined, project completion is postponed until one side gives in. This rarely only costs money, but also the trust between the client and service provider.
Do I still need this at all in an agile project?
A legitimate question, as classic requirement and functional specifications originate from waterfall thinking: specify everything in advance, then build. Agile approaches (Scrum, Kanban) work with product backlogs, epics and user stories instead, which are refined over the course of the project.
The honest answer: It depends on the type of contract, specifically in two cases.
In the case of a works contract with a fixed scope of functions, you need a robust specification sheet. The provider owes a defined, defect-free result, so they must be able to calculate and you must be able to compare offers. Neither is possible without a clear set of requirements.
With an agile approach based on a service contract (dedicated team, billed on a time and material basis), the level of detail shifts. Instead of a complete requirements specification, a product vision plus a roughly prioritised backlog, which is fleshed out sprint by sprint, is often sufficient. But even then, a lean requirements specification is worthwhile: it clarifies the business objective, framework and non-functional requirements, which are also non-negotiable in an agile way. Data protection is not invented "in the next sprint".
A clarification that is often confused in practice: the remuneration model (fixed price or billing based on time and effort) does not necessarily determine the type of contract. A contract for work can also be remunerated on a time and material basis, and a fixed price can also be based on a service contract. The decisive factor is whether a success or an activity is owed, not the price.
In short: The document is called something different in an agile context and is leaner, but the mental work behind it, i.e. clarifying the goal, requirements and priorities, is not eliminated. If you skip it, you only shift it to later project phases, where corrections are much more time-consuming. If you want to create clarity about goals and processes at an early stage, you will benefit from a structured requirements and process analysis at the start of the project.
Template: requirements specification & functional specification
To make sure you don't start from scratch, we provide a template that contains the structure described above as a fillable framework: Target description, actual/target state, a prepared requirements table with numbering and prioritisation, a block for non-functional requirements and acceptance criteria. → Download template
How to use it best:
- Delete what doesn't fit your project. A template is a starting point, not a mandatory form.
- Fill in the objectives and framework first, then the requirements. The order keeps the focus.
- Keep each requirement testable. If you can't test them, reformulate them.
If you want to have your requirements specification checked against an experienced view before you put it out to tender, an external view often helps more than the tenth internal round. This is exactly what an initial consultation on software architecture is for, in which we go through requirements and individual software solutions together.
Conclusion
The requirements specification and functional specification are not a bureaucratic ritual, but the tool with which you make a software project manageable. The requirements specification clarifies what you need and makes offers comparable. The requirements specification sets out how the provider solves the problem and becomes the yardstick for acceptance. If they are clearly separated, this means comparable offers and significantly fewer disputes about what was "actually agreed". The upfront effort is always less than the cost of a project that was built on a misunderstanding.
Download the template, fill in the objectives and the most important requirements, and in just a few hours you will have a basis that you can use to obtain serious offers.
Frequently asked questions
Who writes the requirements specification, who writes the functional specification? The contractor writes the requirements specification as a binding response to this.
What is the difference between the requirements specification and the functional specification? The requirements specification describes the what and why (the requirements), the functional specification describes the how and with what (the specific technical implementation). First the requirements specification, then the functional specification.
Do I need both documents? In the case of a work contract with a defined scope of functions, yes. With an agile approach, a prioritised backlog often replaces the requirements specification, but a lean requirements specification (objectives, framework, non-functional requirements) still makes sense.
How long should a requirements specification be? As a rough guide, around 10 to 30 pages are realistic for a medium-sized customised software project. The decisive factors are completeness and verifiability, not the length.