Published: Last updated:

Requirements and Functional Specifications

Lastenheft and Pflichtenheft: clear requirements before anything is built

The Lastenheft records what the client wants and why; the Pflichtenheft describes how and with what the contractor will solve it. Two separate documents, one logic: clarify before anything is built.

Most failed projects do not fail on code, they fail on assumption. The client meant something other than what the contractor understood, and both notice only at acceptance. The German-language engineering tradition draws a clean line exactly here: first the Lastenheft, which records the requirements from the buyer's point of view, then the Pflichtenheft, which describes the solution from the supplier's point of view. English has no single equivalent pair; the Lastenheft maps to a requirements specification, the Pflichtenheft to a functional or system specification. This page explains the distinction, why the order matters and where the discipline breaks in practice.

Lastenheft: what and why

The Lastenheft is the client's document. Under DIN 69901-5 it is the complete set of requirements, set by the client, for a contractor's deliverables and services. It answers two questions, what should be built and why, and it deliberately leaves the how open. A good Lastenheft describes the problem and the goals, not the implementation. It is the basis of the tender: several suppliers should be able to cost a proposal on the same footing, without a specific technology being predetermined. That openness is what makes the Lastenheft the natural starting point of a make-or-buy decision: only once the requirement stands can the make-or-buy question be answered.

Pflichtenheft: how and with what

The Pflichtenheft is the contractor's answer. DIN 69901-5 frames it as the implementation specifications the contractor develops on the basis of the client's Lastenheft. Where the Lastenheft names the goal, the Pflichtenheft describes the path to it: the concrete solution, the architecture, the interfaces, the assumptions and the boundaries. Every requirement in the Lastenheft finds its counterpart here, ideally traceably linked, so that in the end it is traceable that nothing was lost. The Pflichtenheft therefore often becomes a contract component or annex and the yardstick for acceptance: work is accepted against the Pflichtenheft, not against the memory of a conversation.

The handover point

The decisive moment sits between the two documents. The Lastenheft travels from client to contractor, who reads it, raises questions and answers with the Pflichtenheft. Only the agreed acceptance of the Pflichtenheft turns two viewpoints into one shared plan.

flowchart TD
    A["Client<br/>need and goals"] --> B["Lastenheft<br/>what and why"]
    B --> C["Contractor<br/>reads and reviews"]
    C --> D["Pflichtenheft<br/>how and with what"]
    D --> E["Alignment<br/>questions, assumptions"]
    E --> F["Sign-off<br/>contract and acceptance yardstick"]
    F --> G["Build and accept<br/>against the Pflichtenheft"]

The most common confusion concerns exactly this direction. The Lastenheft belongs to whoever orders; the Pflichtenheft to whoever delivers. A client who already writes a Pflichtenheft pre-empts the solution and throws away the supplier's expertise; a contractor who starts without a Lastenheft builds on guesses.

Where the discipline breaks

  • Conflation. Lastenheft and Pflichtenheft are pressed into one document that no longer separates requirement from solution. The result is that wish and commitment can no longer be told apart.
  • Solution instead of need. The Lastenheft already prescribes a product or a technology. The tender becomes a sham tender, and better solutions drop out.
  • No traceability. Requirements and implementation specifications are not linked. At acceptance the dispute is over whether a feature was ever requested.
  • Frozen instead of maintained. Both documents are written once and never updated. In iterative work the Pflichtenheft ages faster than it is read.

Classic specification and agile practice

The strict separation comes from plant engineering and contract manufacturing, where a fixed deliverable is agreed for a fixed price. In iteratively developed software the form shifts, but the logic does not. The Lastenheft then lives on as epics, goals and acceptance criteria, the Pflichtenheft as architectural decisions documented for instance through RFCs and ADRs. Where the domain complexity is high, a shared domain language of the kind Domain-Driven Design establishes helps bind requirement and implementation to the same vocabulary. The underlying principle holds either way: keep need and solution separate, and link the two traceably. Whether the choice is classic or agile is settled beforehand by the method selection in the methods overview.

The specification as contractual basis

A verifiable description of the owed result is the basis of every acceptance. In practice the Pflichtenheft becomes an annex to the contract and thus the agreed target against which acceptance checks. Without that description, only interpretation remains if a dispute arises. In Swiss law this distinction has a concrete contractual home: a work contract (Werkvertrag) under the Code of Obligations owes a result, and that result needs a verifiable description. This is precisely why a dependable delivery starts with clean requirements, long before the first line of code exists.

References

Related topics

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.