In short
The functional specification (in German Pflichtenheft) is the central implementation document in IT and software projects. It describes the implementation requirements worked out by the contractor on the basis of the requirements specification (Lastenheft).
While the requirements specification answers the questions "What?" and "What for?", the functional specification clarifies the decisive follow-up questions: "How will it be implemented?" and "With what?", i.e. with which technologies, architectures and methods the service provider intends to meet the client's requirements in concrete terms.
The authoritative definition is provided by the standard DIN 69901-5 (project management – terms). According to it, the functional specification comprises the "implementation requirements worked out by the contractor on the basis of implementing the requirements specification provided by the client". This definition clearly assigns the functional specification to the contractor's side, and thus clearly distinguishes it from the requirements specification, which the client draws up. In custom software development, the functional specification is the contractor's answer to the requirements specification: it describes how the requirements will be implemented technically.
Functional specification vs requirements specification: the division of roles
Probably the most common terminological mistake in projects is confusing the functional specification with the requirements specification. The two documents build on each other but have different authors and different functions. Anyone who does not master the separation risks misunderstandings about responsibilities and the scope of services.
- Requirements specification (client): describes the what and what for: the business requirements, solution-neutral.
- Functional specification (contractor): describes the how and with what: the concrete technical answer to each individual requirement in the requirements specification.
You can think of the relationship as question and answer: in the requirements specification, the client states its requirements ("The shop must be connected to our ERP"), and in the functional specification the contractor answers with the concrete solution ("The ERP connection is made via a REST API with synchronisation every 15 minutes via a middleware component"). It is precisely this one-to-one relationship (every requirement receives a documented implementation answer) that makes the functional specification a binding part of the contract.
What belongs in a functional specification? Structure and typical content
A good functional specification is precise, technically concrete and completely traceable back to the requirements specification. Ideally, every requirement in the requirements specification can be found again in the functional specification, including the statement of how it will be implemented or why it is dropped (by agreement). The following rough structure has proven itself:
Typical outline of a functional specification
| Section | Content |
|---|---|
| 1. Objectives | Reference to the requirements specification, project goals from an implementation perspective |
| 2. Product use & environment | Target systems, platforms, operating environment |
| 3. Functional specification | Concrete implementation of each functional requirement |
| 4. Non-functional specification | How performance, security and availability are achieved |
| 5. Technical architecture | System structure, components, interfaces, data model |
| 6. Test & acceptance concept | How and against what testing and acceptance take place |
| 7. Delivery & project plan | Milestones, phases, responsibilities |
The decisive difference from the requirements specification lies in the level of detail: where the requirements specification deliberately remains solution-neutral, the functional specification becomes as concrete as possible. It names frameworks, databases, interface protocols, security measures and architectural decisions, i.e. precisely those technical definitions that the client has deliberately left to the service provider.
Traceability: the heart of the functional specification
A professional functional specification ensures traceability: every implementation requirement can be traced back completely to the associated requirement in the requirements specification. In practice, a reference numbering is often used for this: requirement "L-4.2" in the requirements specification corresponds to specification "P-4.2" in the functional specification. This makes it possible to check objectively at the end of the project whether every promised requirement has actually been implemented, the basis of a clean acceptance and an effective protection against disputes about the scope of services.
Real-world example: a functional specification for a Shopware migration
Let us take up the requirements specification example of the B2B wholesaler having its online shop migrated from Shopware 5 to Shopware 6. As the contractor, the commissioned digital agency draws up the functional specification and answers every requirement in it with a concrete technical definition:
- On "ERP connection": implementation via a REST API middleware (NestJS), synchronisation of stock levels every 15 minutes, master data in a nightly batch.
- On "45,000 items incl. tiered prices": migration via a specially developed import script, mapping of the price lists to the Shopware 6 Rule Builder logic.
- On "loading time under 1.5 s": use of the Shopware HTTP cache, Varnish as a reverse proxy, image optimisation via WebP and CDN delivery.
- On "accessibility under the BFSG": theme adaptation according to WCAG 2.1 AA, automated tests with axe-core in the CI pipeline.
- On "self-service portal": use of the Shopware B2B Suite with customer-specific roles and approval workflows.
Each of these points is a concrete answer to a demand from the requirements specification. The client can check and approve the functional specification, and thus has a binding document against which the performance is measured at the end of the project. This is precisely where the protection for both sides lies.
Why the functional specification protects client and contractor
The functional specification is far more than a technical chore. It is the document that turns a vague wish for requirements into a robust, calculable and enforceable promise of performance. Its most important functions:
- Binding definition of services: the functional specification defines what the contractor actually delivers, the basis for a fixed price and acceptance.
- Protection against scope creep: what is not in the functional specification has not been commissioned and is handled separately as a change request.
- Risk minimisation: technical decisions are thought through and approved before implementation begins, not only during the ongoing project.
- Basis for acceptance: the test and acceptance concept in the functional specification makes project success objectively measurable.
In agile projects, the classic functional specification is often replaced by technical specifications, a definition of done and elaborated user stories with acceptance criteria. The basic idea, however, remains identical: the contractor must document how it meets the requirements technically, before and while implementing them. The German Wikipedia entry on the Pflichtenheft offers further information on the normative background.
Normative background: DIN 69901 and VDI 2519
Like the requirements specification, the functional specification is anchored in standards in German-speaking countries. DIN 69901-5 provides the definition in common use today, which identifies the functional specification as the contractor's implementation answer. For years, the guideline VDI/VDE 2519 Part 1 described the structure of both documents and thus established a practical template for industrial and software projects. Both sources emphasise the order: first the client's requirements specification is created, then the contractor's functional specification responding to it.
Historically, the pair of terms comes from German mechanical and plant engineering and migrated from there into software development. In an international context, the Pflichtenheft corresponds most closely to the functional specification or the technical design document. Caution is advised with the English umbrella term specification: depending on the project, it can mean either the requirements specification or the functional specification. In international collaboration, it should therefore be explicitly clarified which document is drawn up and approved by whom.
How the requirements specification becomes a functional specification
The functional specification is created in a clearly defined step in the project chain. The typical process shows where it fits in:
- Review the requirements specification: the contractor analyses the requirements and clarifies open questions with the client.
- Develop a solution concept: a technical implementation is designed for each requirement.
- Write the functional specification: the implementation requirements are documented, each referenced to the requirement in the requirements specification.
- Effort & quote: on the basis of the functional specification, the contractor calculates effort, price and schedule.
- Approval: the client checks and approves the functional specification, which becomes a binding part of the contract.
- Implementation & acceptance: implementation against the functional specification, acceptance against the test concept defined in it.
It is important that the functional specification is not drawn up behind closed doors. The best functional specifications are the result of questions, workshops and coordination with the client, because only in this way can the gaps and ambiguities that are unavoidable in the requirements specification be resolved cleanly before they become expensive during implementation.
Common mistakes in the functional specification
The functional specification also has recurring pitfalls that undermine its value:
- Simply copying the requirements specification: a functional specification that merely repeats the requirements without describing the concrete implementation is worthless.
- Missing traceability: without clear references to the requirements specification, it cannot be checked later whether all requirements have been covered.
- Too vague: woolly wording such as "performant" or "user-friendly" without measurable values leads to disputes at acceptance.
- No approval by the client: a functional specification that has not been accepted has no contractual protective effect.
The functional specification in practice: what mid-sized companies should look out for
Even though the functional specification is the contractor's job, the client should by no means just nod it through. It is the document against which the client measures the success of the project, and checking it carefully is one of the most important tasks in the initial phase. Practical tips for mid-sized companies:
- Check completeness: can every requirement from the requirements specification be found again in the functional specification? Uncover gaps now, not at acceptance.
- Demand measurability: insist on concrete values instead of empty phrases: "loading time under 1.5 seconds" instead of "fast".
- Question assumptions: wherever the contractor has interpreted requirements, this should be documented and confirmed.
- Understand the acceptance concept: clarify early on how and against what testing and acceptance will take place at the end.
- Define the change process: agree how later change requests will be handled and priced.
A carefully drawn up and jointly approved functional specification is the best insurance against what most frequently causes projects to fail: differing ideas of what was actually supposed to be delivered. It takes time at the start of the project, and saves it many times over across the entire duration.
FAQ on the functional specification
Who writes the functional specification?
The functional specification is drawn up by the contractor, i.e. the service provider or agency that provides the service. It is its technical answer to the client's requirements specification.
What is the difference between the functional specification and the requirements specification?
The requirements specification describes the what and what for from the client's point of view (solution-neutral). The functional specification describes the how and with what from the contractor's point of view (concrete implementation).
Does the client have to approve the functional specification?
Yes, that is strongly recommended. Only with approval does the functional specification become the binding basis for implementation and acceptance. Formal acceptance protects both sides.
Do agile projects still need a functional specification?
In an agile environment, technical specifications, a definition of done and acceptance criteria often take the place of the classic functional specification. The core idea (the contractor documents the implementation) is retained.
What happens if the requirements and functional specifications contradict each other?
Ideally, the contractor clarifies ambiguities before drawing up the functional specification. Any remaining deviations must be explicitly documented and approved by the client, so that no disputes about the scope of services arise later.
Practical guide: our guide to writing requirements and functional specifications explains step by step how the requirements specification becomes a functional specification, with an example table and a fillable template.
Don't want to formulate requirements and implementation on your own? We moderate the requirements workshop and deliver a specification ready for acceptance with verifiable criteria: have your requirements specification drawn up.