Lastenheft vs Pflichtenheft: The What and the How, Separated

September 2, 2026· 10 min read

German engineering has two words where much of the world has none: Lastenheft and Pflichtenheft. Together they define the cleanest contract boundary in systems engineering — one document states WHAT the customer needs, the other states HOW the supplier will deliver it.

If you have ever watched a project descend into "I only asked for X" versus "but X obviously implies Y", you have seen what happens when those two documents collapse into one. This post explains the split, why it exists, and how to use it.

Two documents, one boundary

A Lastenheft is the customer’s requirements specification: everything the customer wants the system to do, written from the customer’s point of view, without prescribing how to build it. It is the "what".

A Pflichtenheft is the supplier’s response: how the supplier intends to meet each of those requirements, elaborated into technical, testable detail. It is the "how".

The seam between the two is where accountability changes hands — and that is exactly why the split matters.

Lastenheft: the WHAT

Written by — or with — the customer. It contains:

Purpose and goals — why the system should exist and what problem it solves.
Functional requirements — what the system must do, in the customer’s language.
Quality requirements — performance, safety, availability, and reliability targets.
Constraints and interfaces — environment, standards, regulations, and adjacent systems.
Acceptance criteria — how the customer will judge whether the result is acceptable.
Exclusions — explicitly what is out of scope, so it cannot be assumed later.

Pflichtenheft: the HOW

Written by the supplier, in response to the Lastenheft. It contains:

System architecture and the components that realize it.
Technical design decisions — and the alternatives that were rejected, and why.
Detailed interface specifications — data, protocols, register maps, message schemas.
A verification and test plan mapped to each requirement.
Deliverables, milestones, and the acceptance procedure.

Why keep them separate

Scope disputes get a reference point: the signed Lastenheft is what was actually agreed.
The supplier owns the HOW, so it can choose the cheapest compliant design without re-negotiating every decision.
Traceability becomes mechanical: every Pflichtenheft item traces back to a Lastenheft item.
It forces the customer to say WHAT, not HOW — which prevents the customer from dictating implementation and then blaming the supplier for the result.

The standards behind the words

In Germany the split is codified: DIN 69901-5 defines the Lastenheft as the requirements specification produced by the client, and the Pflichtenheft as the implementation specification produced by the contractor. VDI 3694 uses the same pair for automation systems.

The English-speaking world has no exact equivalent. It approximates with "requirements specification" versus "design specification" — or an SRS that quietly mixes both, which is precisely the ambiguity the German split removes.

The terms travel well: suppliers in automotive, machinery, and automation now write Lastenheft/Pflichtenheft pairs even on English-language projects, because the boundary is that useful.

How they connect: traceability

Every requirement in the Pflichtenheft answers a requirement in the Lastenheft. Nothing in the Pflichtenheft exists that the Lastenheft did not ask for — if it does, it is scope creep, and it should be flagged, not slipped in.

That link is what turns two documents into a system:

Coverage — you can see at a glance whether every "what" has a "how".
Change impact — when a requirement changes, you know exactly which design decisions are affected.
Audit — a regulator or customer can follow any requirement from need to implementation to test.

A worked example

Lastenheft: "The customer shall be able to export the requirements list to PDF."

Pflichtenheft: "The system shall generate a PDF, paginate sections with their numbering, and include the traceability matrix as an appendix. Generation shall complete within 2 seconds for documents of up to 500 requirements."

One states the need; the other commits to a measurable realization. The first is the customer’s to own; the second is the supplier’s to defend.

The customer owns the WHAT, the supplier owns the HOW — and the contract is the seam between them. Write them as two documents and you remove the most expensive argument in engineering.