In German-speaking IT and software projects, specifications are traditionally split across two separate documents: the Lastenheft (the client's requirements specification) and the Pflichtenheft (the contractor's implementation specification). This pair matters whenever a project involves German companies or agencies. The English umbrella term "specification" blurs a distinction that German project practice treats as fundamental.
The authoritative definition comes from the German project management standard DIN 69901-5. It defines the Lastenheft as all requirements set out by the client for a contractor's deliverables and services. The Pflichtenheft, in turn, holds the implementation provisions the contractor draws up in response. Put simply: the Lastenheft answers "what is needed, and why?" — the Pflichtenheft answers "how will it be built, and with what?".
Lastenheft vs. Pflichtenheft at a glance
| Criterion | Lastenheft | Pflichtenheft |
|---|---|---|
| Answers | What? What for? | How? With what? |
| Written by | Client | Contractor (agency / vendor) |
| When | Before the tender | After award, before implementation |
| Level of detail | Requirements, goals, constraints — solution-neutral | Concrete technical solution |
| Purpose | Make proposals comparable | Make delivery binding and testable |
| Closest English equivalent | Requirements specification / Statement of Work | Functional specification / Technical design document |
What goes into the Lastenheft?
A solid Lastenheft stays solution-neutral: it describes what is needed, not which technology to use. It usually covers:
- the current situation and the business goal;
- functional requirements, each with a unique ID and a priority (must / should / could);
- non-functional requirements such as performance, security, availability and accessibility;
- the systems the solution must integrate with;
- constraints — budget corridor, deadlines, and legal obligations such as GDPR;
- acceptance criteria.
Solution-neutral means, for example, stating that orders must flow automatically into the ERP system — but not which middleware or protocol to use. That choice belongs to the contractor.
Every requirement should be testable. "The search must be fast" cannot be verified. "Search results for a catalogue of 50,000 items appear in under 500 milliseconds" can. Testability is what later turns the document into a reliable basis for acceptance.
What goes into the Pflichtenheft?
The Pflichtenheft is the contractor's binding answer. For each requirement in the Lastenheft, it documents the concrete implementation:
- system architecture and technologies;
- the data model and interface specifications;
- load assumptions;
- a test and acceptance concept;
- the delivery plan with milestones.
A professional Pflichtenheft keeps full traceability: every implementation provision points back to the requirement it fulfils. Both sides can then check objectively that everything promised was delivered. In many projects the Pflichtenheft becomes part of the contract — what is in it is owed; what is not is a change request.
A practical example
A mid-sized B2B wholesaler migrates its online shop from Shopware 5 to Shopware 6. In the Lastenheft, the client demands:
- migration of 45,000 products, including tiered and customer-specific prices;
- an ERP integration with at least hourly synchronisation;
- product page load times under 1.5 seconds;
- accessibility in line with the German BFSG.
The agency's Pflichtenheft answers each point concretely:
- a NestJS REST middleware for the ERP link, with 15-minute stock sync;
- a custom import script that maps the price lists onto Shopware's Rule Builder;
- Varnish caching plus WebP/CDN delivery for performance;
- WCAG 2.1 AA theme adjustments, verified by automated axe-core tests.
The client reviews and approves — and now has a measurable benchmark for acceptance.
Mapping to international practice
The document pair originates in German mechanical and plant engineering and later moved into software development. That is why it stays standard in German Mittelstand projects, while international teams tend to speak of a requirements specification, statement of work or functional specification.
Be careful with the bare English word "specification": depending on context, it can mean either document. In international projects, it helps to clarify explicitly who writes and approves which document. The German split is clear here — the requirements side belongs to the client, the solution side to the contractor.
Do agile projects still need them?
In agile setups (Scrum, Kanban), the classic monolithic documents are often replaced by a product vision, a prioritised backlog, user stories and acceptance criteria. The underlying discipline stays the same: the client must state goals, constraints and non-negotiable non-functional requirements before the team builds.
The contract type decides how much you need:
- Under a fixed-scope work contract (Werkvertrag), a robust Lastenheft stays essential — the contractor owes a defined result and must be able to price it.
- Under a time-and-materials engagement, a lean Lastenheft covering goals and constraints is usually enough.
Further background is available in the German Wikipedia entries on the Lastenheft and Pflichtenheft.
FAQ
Who writes which document?
The client writes the Lastenheft (requirements, solution-neutral); the contractor writes the Pflichtenheft (concrete implementation) in response.
Is either document legally required?
No. In practice, however, both are frequently made part of the contract, which turns them into the binding basis for delivery and acceptance.
How long should a Lastenheft be?
As long as necessary, as short as possible. For a mid-sized custom software project, 10–30 pages is a realistic range; completeness, consistency and testability matter more than volume.