In German-speaking IT and software projects, specifications are traditionally split across two distinct documents: the Lastenheft (the client's requirements specification) and the Pflichtenheft (the contractor's functional or implementation specification). Understanding this pair is essential when working with German companies or agencies, because 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 the entirety of requirements set out by the client for the deliverables and services of a contractor, and the Pflichtenheft as the implementation provisions drawn up by the contractor in response. In short: 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 describes the current situation and the business goal, lists functional requirements with unique IDs and priorities (must / should / could), covers non-functional requirements such as performance, security, availability and accessibility, names the systems the solution must integrate with, and defines constraints (budget corridor, deadlines, legal obligations such as GDPR) as well as acceptance criteria. Crucially, it stays solution-neutral: it states that orders must flow automatically into the ERP system, but not which middleware or protocol to use — that decision 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, technologies, data model, interface specifications, load assumptions, a test and acceptance concept, and the delivery plan with milestones. A professional Pflichtenheft maintains full traceability — every implementation provision references the requirement it fulfils, so at the end of the project both sides can objectively verify 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, and 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 mapping price lists onto Shopware's Rule Builder, Varnish caching plus WebP/CDN delivery for performance, and WCAG 2.1 AA theme adjustments verified by automated axe-core tests. The client reviews and approves — and now has a measurable yardstick for acceptance.
Mapping to international practice
The document pair originates in German mechanical and plant engineering and later migrated into software development, which is why it remains 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 refer to either document. In international projects it is worth clarifying explicitly who writes and approves which document — the German split assigns the requirements side unambiguously to the client and 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 remains, though: the client must articulate goals, constraints and non-negotiable non-functional requirements before the team builds. Under a fixed-scope work contract (Werkvertrag), a robust Lastenheft remains indispensable, because 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 sufficient. 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.