Lastenheft vs Pflichtenheft: Was und Wie, sauber getrennt

Die deutsche Ingenieurskunst hat zwei Wörter, wo der Rest der Welt keines hat: Lastenheft und Pflichtenheft. Zusammen bilden sie die sauberste Vertragsgrenze im Systems Engineering — das eine Dokument beschreibt, WAS der Kunde braucht, das andere, WIE der Lieferant es umsetzt.

Wer schon einmal erlebt hat, wie ein Projekt in „ich wollte doch nur X“ gegen „aber X bedeutet offensichtlich Y“ abrutscht, hat gesehen, was passiert, wenn diese beiden Dokumente zu einem verschmelzen. Dieser Beitrag erklärt die Trennung, warum es sie gibt und wie man sie nutzt.

Zwei Dokumente, eine Grenze

Das Lastenheft ist die Anforderungsspezifikation des Auftraggebers: alles, was der Kunde vom System erwartet — aus Sicht des Kunden formuliert, ohne vorzuschreiben, wie es gebaut wird. Es ist das „Was“.

Das Pflichtenheft ist die Antwort des Auftragnehmers: wie der Lieferant jede dieser Anforderungen erfüllen will, ausgearbeitet bis ins technische, testbare Detail. Es ist das „Wie“.

Die Nahtstelle zwischen beiden ist genau dort, wo die Verantwortung den Besitzer wechselt — und genau deshalb ist die Trennung wichtig.

Lastenheft: das WAS

Verfasst vom — oder gemeinsam mit dem — Kunden. Es enthält:

• Zweck und Ziele — warum das System existieren soll und welches Problem es löst.
• Funktionale Anforderungen — was das System tun muss, in der Sprache des Kunden.
• Qualitätsanforderungen — Ziele für Leistung, Sicherheit, Verfügbarkeit und Zuverlässigkeit.
• Randbedingungen und Schnittstellen — Umgebung, Normen, Vorschriften und angrenzende Systeme.
• Abnahmekriterien — woran der Kunde misst, ob das Ergebnis akzeptabel ist.
• Abgrenzungen — ausdrücklich, was außerhalb des Umfangs liegt, damit es später nicht unterstellt wird.

Pflichtenheft: das WIE

Verfasst vom Lieferanten, als Antwort auf das Lastenheft. Es enthält:

• Die Systemarchitektur und die Komponenten, die sie realisieren.
• Technische Entwurfsentscheidungen — samt der verworfenen Alternativen und der Gründe.
• Detaillierte Schnittstellenspezifikationen — Daten, Protokolle, Registertabellen, Nachrichtenschemata.
• Einen Prüf- und Testplan, der auf jede Anforderung abgebildet ist.
• Liefergegenstände, Meilensteine und das Abnahmeverfahren.

Warum man sie trennt

• Scope-Streitigkeiten bekommen einen Referenzpunkt: das unterschriebene Lastenheft ist das, was wirklich vereinbart wurde.
• Der Lieferant besitzt das WIE und kann die günstigste konforme Lösung wählen, ohne jede Entscheidung neu zu verhandeln.
• Nachverfolgbarkeit wird mechanisch: Jeder Eintrag im Pflichtenheft verweist auf einen Eintrag im Lastenheft.
• Es zwingt den Kunden, das WAS zu benennen statt das WIE — und verhindert, dass der Kunde die Umsetzung vorschreibt und später das Ergebnis bemängelt.

Die Normen hinter den Wörtern

In Deutschland ist die Trennung normiert: DIN 69901-5 definiert das Lastenheft als die vom Auftraggeber erstellte Anforderungsbeschreibung und das Pflichtenheft als die vom Auftragnehmer erarbeitete Realisierungsvorgabe. VDI 3694 verwendet dasselbe Begriffspaar für Automatisierungssysteme.

Der englischsprachige Raum kennt keine exakte Entsprechung. Er behilft sich mit „requirements specification“ gegenüber „design specification“ — oder einem SRS, das beides stillschweigend vermischt. Genau diese Mehrdeutigkeit beseitigt die deutsche Trennung.

Die Begriffe reisen gut: Zulieferer in Automotive, Maschinenbau und Automatisierung schreiben Lastenheft/Pflichtenheft-Paare heute auch in englischsprachigen Projekten — weil die Grenze so nützlich ist.

Wie sie zusammenhängen: Nachverfolgbarkeit

Jede Anforderung im Pflichtenheft beantwortet eine Anforderung im Lastenheft. Nichts im Pflichtenheft existiert, was das Lastenheft nicht verlangt hat — falls doch, ist es Scope-Creep, und es sollte gekennzeichnet, nicht eingeschmuggelt werden.

Diese Verknüpfung macht aus zwei Dokumenten ein System:

• Abdeckung — auf einen Blick sichtbar, ob jedes „Was“ ein „Wie“ hat.
• Änderungswirkung — wenn sich eine Anforderung ändert, ist sofort klar, welche Entwurfsentscheidungen betroffen sind.
• Audit — Prüfer oder Kunde können jede Anforderung von der Notwendigkeit über die Umsetzung bis zum Test verfolgen.

Ein Beispiel

Lastenheft: „Der Kunde muss die Anforderungsliste als PDF exportieren können.“

Pflichtenheft: „Das System muss ein PDF erzeugen, Abschnitte mit ihrer Nummerierung paginieren und die Nachverfolgbarkeitsmatrix als Anhang aufnehmen. Die Erzeugung muss für Dokumente mit bis zu 500 Anforderungen innerhalb von 2 Sekunden abgeschlossen sein.“

Das eine benennt den Bedarf; das andere verpflichtet zu einer messbaren Umsetzung. Das erste gehört dem Kunden, das zweite muss der Lieferant vertreten.