Lastenheft und Pflichtenheft ohne versteckte Zielkonflikte

Entsteht ein Lastenheft in mehreren Abteilungen, liefert etwa der Service sein Kapitel, die Qualitätssicherung ihres, und der Vertrieb ergänzt zwei Seiten. Am Ende steht ein Dokument, das ordentlich aussieht. Das Problem beginnt, wenn die Wünsche der Abteilungen nur untereinanderstehen und niemand sie gegeneinander liest. Dann können in zwei Kapiteln zwei Zeilen stehen, die nicht zusammenpassen, ohne dass es jemand merkt. Wir bei der Truinorva GmbH klären mit Entwicklungsteams solche Zielkonflikte. Deshalb erklären wir beide Dokumente hier nur knapp und zeigen ausführlich den Schritt zwischen Sammeln und Übergeben.

TL;DR

• Ein Lastenheft hält aus Sicht des Auftraggebers fest, was ein zu entwickelndes System leisten soll und woran die Abnahme gemessen wird.
• Das Pflichtenheft ist die Antwort des Auftragnehmers: Es beschreibt, wie er die Anforderungen aus dem Lastenheft umsetzt.
• Auch ein vollständiges und prüfbares Lastenheft kann zwei Anforderungen enthalten, die sich gegenseitig erschweren oder ausschließen.
• Vor der Übergabe empfehlen wir, die Kapitel verschiedener Abteilungen gegeneinander zu lesen und solche Paare aufzuschreiben.
• Für jeden echten Zielkonflikt gibt es drei Wege: Rangfolge festlegen, Zielwert vereinbaren oder den Konflikt als Entwicklungsaufgabe ausweisen.

Was ein Lastenheft ist und was hineingehört

Ein Lastenheft ist das Dokument, in dem der Auftraggeber alle Anforderungen festhält, die er verbindlich an ein zu entwickelndes System stellt. So beschreibt es das V-Modell XT Bund, das Referenzmodell für Systementwicklungsprojekte der Bundesverwaltung, in der Version 2.4 von 2024. Nach diesem Modell ist das Lastenheft die Grundlage für Ausschreibung und Vertragsgestaltung.
Die Inhalte eines Lastenhefts sind nach dem V-Modell XT Bund vor allem die Anforderungen selbst: funktionale (was das System tut) und nicht funktionale (wie gut es das tut). Dazu kommen Lieferbedingungen und Abnahmekriterien. Wie sich das gliedern lässt, zeigt die Richtlinie VDI/VDE 3694 von 2014. Sie gibt einen Gliederungsvorschlag für Automatisierungssysteme, und ihr Lastenheft hat acht Teile:

1. Einführung in das Projekt
2. Beschreibung der Ausgangssituation (Istzustand)
3. Aufgabenstellung (Sollzustand)
4. Anforderungen für die Kommunikationsschnittstellen
5. Anforderungen an die Systemtechnik
6. Anforderungen für Systementwicklung, Inbetriebnahme und Einsatz
7. Anforderungen an die Qualität
8. Anforderungen an die Projektabwicklung
   Wer ein technisches Lastenheft im Maschinenbau schreibt, etwa für eine automatisierte Anlage, kann sich an dieser Gliederung orientieren. Geschrieben ist die Richtlinie für Automatisierungssysteme, nicht für jedes Gerät oder jede Baugruppe.

Lastenheft und Pflichtenheft: der Unterschied

Der Unterschied zwischen Lastenheft und Pflichtenheft liegt im Verfasser und in der Frage, die das Dokument beantwortet. Im Lastenheft legt der Auftraggeber fest, was das System leisten soll. Im Pflichtenheft legt der Auftragnehmer fest, wie er die Anforderungen umsetzt. Das Lastenheft kommt also zuerst.
Ein Pflichtenheft ist damit das Gegenstück zum Lastenheft auf der Seite des Auftragnehmers. Er übernimmt die Anforderungen, bereitet sie auf und konkretisiert Lieferumfang und Abnahmekriterien. Laut dem V-Modell XT Bund erstellt er das Pflichtenheft in Zusammenarbeit mit dem Auftraggeber.

Ein Beispiel für ein Lastenheft mit verstecktem Zielkonflikt

Wie zwei Zeilen aussehen, die nicht zusammenpassen, zeigt ein ausgedachtes Beispiel für ein Lastenheft.
Angenommen, ein Unternehmen schreibt das Lastenheft für ein tragbares Messgerät. Im Kapitel des Service steht: Der Akku lässt sich ohne Werkzeug wechseln. Im Kapitel der Qualitätssicherung steht: Das Gehäuse bleibt dauerhaft dicht. Beide Zeilen lesen sich eindeutig, und jede ist für sich erfüllbar.
Zusammen ziehen sie in verschiedene Richtungen. Ein Akkufach, das sich von Hand öffnen lässt, ist eine zusätzliche Öffnung im Gehäuse, und an ihr hängt dann die Dichtheit. Ein solches Paar nennen wir hier Zielkonflikt.
Geht das Lastenheft so hinaus, entscheidet später jemand anderes über den Zielkonflikt: der Auftragnehmer, die Konstruktion oder der Termindruck. Wer das Paar vor der Übergabe findet und benennt, entscheidet selbst.

Widersprüchliche Anforderungen im Lastenheft finden

Widersprüchliche Anforderungen finden Sie, indem Sie vor der Übergabe die Kapitel verschiedener Abteilungen gegeneinander lesen. Wir empfehlen diesen Schritt für jedes Lastenheft, an dem mehr als eine Abteilung geschrieben hat. Zum Hintergrund: Beate Bender und Kilian Gericke zählen in der Pahl/Beitz Konstruktionslehre von 2021 die Widersprüchlichkeit der Ziele zu den Kriterien, an denen sich bemisst, wie anspruchsvoll ein Konstruktionsauftrag ist.
Das Gegenlesen ist der dritte von vier Schritten, die wir vorschlagen, wenn Sie ein Lastenheft erstellen:

1. Ziel und Ausgangslage in wenigen Sätzen festhalten.
2. Anforderungen je Abteilung sammeln, jede prüfbar und ohne Lösung formuliert.
3. Die Kapitel verschiedener Abteilungen gegeneinander lesen und jedes Paar notieren, bei dem eine Anforderung die andere schwerer erfüllbar macht.
4. Für jedes Paar entscheiden, wie Sie damit umgehen, und die Entscheidung ins Lastenheft schreiben. Erst dann geht das Dokument an den Auftragnehmer.
   Zu Schritt 2 sagt das V-Modell XT Bund zweierlei. Anforderungen sollen so beschrieben sein, dass ihre Erfüllung prüfbar ist, und das Lastenheft soll im Allgemeinen keine technischen Lösungen vorgeben. Der zweite Punkt hilft auch bei der Suche nach Konflikten. Steht im Lastenheft schon die Lösung, etwa „Akkufach mit Schnappdeckel“, geht nach unserer Einschätzung der Zielkonflikt dahinter unter, und der Auftragnehmer hat im Pflichtenheft an dieser Stelle weniger Spielraum.
   Für Schritt 3 müssen Sie nicht jede Zeile mit jeder vergleichen. Innerhalb eines Kapitels hat wenigstens der Verfasser beide Zeilen gesehen, über Kapitelgrenzen hinweg womöglich niemand. Als Ergebnis genügt eine einfache Liste: Anforderung A, Anforderung B und ein Satz dazu, warum die eine die andere erschwert. Im Beispiel steht darauf: Akku ohne Werkzeug wechselbar, Gehäuse dauerhaft dicht, Grund ist das Akkufach als zusätzliche Öffnung.

Scheinbarer Konflikt oder echter Zielkonflikt

Ein Zielkonflikt ist echt, wenn mehr vom einen weniger vom anderen bedeutet. Er ist nur scheinbar, wenn zwei Abteilungen mit demselben Wort Verschiedenes meinen. Dieses Muster beschreibt unser Beitrag Die Entwicklung steckt fest unter der Überschrift „Das Problem ist unscharf“.
Bei einem scheinbaren Konflikt helfen ein Gespräch und eine genauere Formulierung. Im Beispiel kann sich dabei zeigen, dass die Zeile der Qualitätssicherung weniger klar war, als sie aussah. Meint die Qualitätssicherung mit „dicht“ nur den Schutz gegen Staub, ist ein Akkufach ohne Werkzeug womöglich gar kein Problem. Danach steht im Lastenheft, wogegen das Gehäuse dicht sein soll.

Drei Wege, mit einem echten Zielkonflikt umzugehen

Wählen Sie für jeden echten Zielkonflikt bewusst einen von drei Wegen und halten Sie ihn im Lastenheft fest.
Rangfolge festlegen. Sie schreiben ins Lastenheft, welche Anforderung vorgeht. Im Beispiel könnte das heißen: Die Dichtheit geht vor, der Akkuwechsel darf ein Werkzeug brauchen.
Zielwert vereinbaren. Die Abteilungen einigen sich auf einen Wert, und das Lastenheft nennt ihn. Im Beispiel wäre das eine vereinbarte Zahl von Akkuwechseln, die das Gehäuse dicht überstehen muss.
Als Entwicklungsaufgabe ausweisen. Sollen beide Anforderungen ohne Abstriche gelten, schreiben Sie den Zielkonflikt offen als Aufgabe ins Lastenheft. Für diesen Fall gibt es einen Namen aus TRIZ. Das ist nach der Richtlinie VDI 4521 Blatt 2 von 2018 eine Systematik aus Annahmen, Regeln, Methoden und Werkzeugen, mit der sich Systeme wie Produkte oder Prozesse verbessern lassen. TRIZ spricht von einem technischen Widerspruch: Wer einen Parameter verbessert, verschlechtert einen anderen Parameter desselben Systems so stark, dass die Verschlechterung nicht hinnehmbar ist. Im Lastenheft steht dann ein Satz wie dieser: Der Akku soll ohne Werkzeug wechselbar sein, ohne dass die Dichtheit des Gehäuses leidet. Der Satz enthält keine Lösung und zeigt dem Auftragnehmer offen, wo die schwierige Entwicklungsarbeit liegt.
Der dritte Weg ist nicht immer der richtige. Ein scheinbarer Konflikt oder eine fehlende Rangfolge ist keine Entwicklungsaufgabe und braucht kein TRIZ. Dafür genügt eine Stunde mit den beteiligten Abteilungen. Ein kaufmännischer Konflikt, etwa Preis gegen Liefertermin, ist keine technische Aufgabe. Und wo noch niemand gemessen hat, ob zwei Anforderungen einander überhaupt stören, kommt zuerst ein Versuch.
Wie sich ein technischer Widerspruch auflösen lässt, erklärt unser Beitrag Technische Widersprüche lösen. Wie sich Zielkonflikte in einer laufenden Entwicklung einordnen lassen, zeigt ein weiterer Beitrag am Beispiel nachhaltiger Produktentwicklung.

Das Pflichtenheft als Gegenprobe

Am Pflichtenheft lässt sich ablesen, was aus den notierten Zielkonflikten geworden ist, auch aus denen, die Sie als Entwicklungsaufgabe ausgewiesen haben. Der Auftragnehmer beschreibt dort seine Lösung. Aus unserer Sicht steckt darin oft eine Entscheidung zwischen zwei Anforderungen, die sich nicht gleichzeitig voll erfüllen lassen, ob der Auftragnehmer sie ausspricht oder nicht.
Nehmen Sie deshalb die Liste der notierten Paare und lesen Sie das Pflichtenheft Paar für Paar durch. Was ist aus dem Akkufach geworden, was aus der Dichtheit? Steht zu einem Paar nichts im Pflichtenheft, ist das die Stelle für eine Rückfrage.

Häufig gestellte Fragen

Welche Norm regelt das Lastenheft?

Das Lastenheft ist als Begriff in der DIN 69901-5 festgelegt, der Begriffsnorm des Projektmanagements. DIN Media führt die Ausgabe von 2009 als aktuell, die ältere DIN 69905 von 1997 ist durch sie ersetzt. Zum Vorgehen gibt es unter anderem zwei VDI-Richtlinien: VDI 2519 Blatt 1 von 2001 für Materialfluss- und Automatisierungssysteme und VDI/VDE 3694 für Automatisierungssysteme.

Was heißt Lastenheft auf Englisch?

Zwei VDI-Richtlinien zum Lastenheft übersetzen den Begriff unterschiedlich: VDI 2519 Blatt 1 mit „tender specification“, VDI/VDE 3694 mit „system requirement“. Das Pflichtenheft heißt in der ersten „performance specification“, in der zweiten „specification“. Verbindlich ist bei beiden Richtlinien die deutsche Fassung.

Was sind funktionale und nicht funktionale Anforderungen?

Funktionale Anforderungen beschreiben, was ein System leisten soll. Nicht funktionale Anforderungen beschreiben, wie gut es das leisten soll. Das V-Modell XT Bund teilt die nicht funktionalen Anforderungen in Qualitätsanforderungen und Randbedingungen. Als Beispiele für nicht funktionale Anforderungen nennt es Angaben zur Verfügbarkeit oder die Erfüllung von Normen.

Ist ein Lastenheft noch zeitgemäß?

Das hängt vom Vorgehen ab. Das V-Modell XT Bund sieht das Lastenheft vor. Wird Software nach Scrum entwickelt, also in kurzen, aufeinanderfolgenden Zyklen, tritt dort an seine Stelle ein Anforderungskonzept. Es ist deutlich gröber und kürzer, sein Aufbau kann sich aber am Lastenheft orientieren.

Fazit: der nächste Schritt vor der Übergabe

Nehmen Sie das Lastenheft, das als nächstes Ihr Haus verlässt, und lesen Sie zwei Kapitel aus verschiedenen Abteilungen gegeneinander. Bleibt dabei ein Zielkonflikt, den weder Rangfolge noch Zielwert auflösen, müssen Sie ihn nicht allein klären: Dafür gibt es unser Format Structured Innovation, drei Tage plus Follow-up. Melden Sie sich, wenn er in Ihrem Projekt mehrere Abteilungen beschäftigt.

Quellen

• DIN 69901-5:2009-01, Projektmanagement, Projektmanagementsysteme, Teil 5: Begriffe. DIN Media.
• VDI 2519 Blatt 1:2001-12, Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheften. DIN Media.
• VDI/VDE 3694:2014-04, Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen. DIN Media.
• VDI 4521 Blatt 2:2018-04, Erfinderisches Problemlösen mit TRIZ, Zielbeschreibung, Problemdefinition und Lösungspriorisierung. DIN Media.
• Informationstechnikzentrum Bund (Hrsg.): V-Modell XT Bund, Version 2.4, 2024. PDF.
• Bender, B., Gericke, K. (2021): Entwickeln der Anforderungsbasis: Requirements Engineering. In: Pahl/Beitz Konstruktionslehre. Springer Vieweg. DOI 10.1007/978-3-662-57303-7_7.