Management-Zusammenfassung zu diesem Beitrag:
Lastenheft und Pflichtenheft werden im deutschsprachigen → Projektmanagement-Umfeld häufig benutzt.
Dennoch sind die Bedeutung und der Einsatz nicht immer klar und führt zur Verwirrung.
In diesem Beitrag werden die Begriffe “Lastenheft und Pflichtenheft” beschrieben und eine Klärung der Unterschiede vorgenommen.
Ein Dauerthema in der deutschsprachigen Projektmanagement-Gemeinschaft ist der Gebrauch von Lastenheft und Pflichtenheft. In diesem Beitrag wird eine Übersicht mit verschiedenen Blickwinkeln geliefert.
Bei der Verwendung von Lastenheft und Pflichtenheft geht es immer um Anforderungen, die zur Umsetzung gelangen sollen. Die Disziplin, die sich hiermit in erster Linie beschäftigt ist das → Requirements Engineering (RE). Betrachtet man aber die aktuelle Literatur und die aktuellen Standards zum RE, so fällt auf, dass das Konzept Lastenheft und Pflichtenheft kaum verwendet wird.
Im Projektmanagement sieht es etwas anders aus: Im deutschsprachigen Raum wird häufig auf Lastenheft und Pflichtenheft zurückgegriffen. Daher wird hier primär eine Darstellung aus Sicht des Projektmanagements geliefert.
Abbildung 0.1: Einordnung von Lastenheft und Pflichtenheft
Die allgemeine Beschreibung zum Projektmanagement findet sich
hier
- 1. Einleitung und Grundlagen
- 2. Erstellung von Lastenheft und Pflichtenheft
- 3. Gegenüberstellungen Lastenheft und Pflichtenheft
- 4. Einbettung in den Projektkontext
- 5. Das Konzept von Lastenheft und Pflichtenheft in heutiger Zeit
- 6. Häufige Fragen und Antworten zum Thema “Lastenheft und Pflichtenheft”
- A. Präsentationen, Literatur und Weblinks
1. Einleitung und Grundlagen
Lastenheft und Pflichtenheft – diese Aufteilung ist in Deutschland fest im Projektleben verankert, außerhalb des deutschsprachigen Raums jedoch kaum bekannt. Das Lastenheft enthält (grob gesprochen) das “was gemacht” werden muss, das Pflichtenheft das “wie etwas umgesetzt” wurde oder wird.
Abbildung 1.1: Erstellung von Lastenheft und Pflichtenheft
Das Lastenheft wird nach gängiger Sicht vor Projektstart durch den Auftraggeber (Kunden) erstellt und an den Auftragnehmer weitergereicht, der auf dieser Basis ein Angebot abgeben kann, welches wiederum in einen Kundenvertrag münden kann. Hierzu sollte ein (vorläufiges) Pflichtenheft erstellt werden, welches “gut genug” sein sollte, um den Kundenvertrag “passend” zu ergänzen. Nach Vertragsunterzeichnung und Projektbeginn kann das Pflichtenheft durch den Auftragnehmer dann ergänzt oder vervollständigt werden.
Abbildung 1.2: Erstellung von Lastenheft, Pflichtenheft und Kundenvertrag
Abbildung 1.3: Legende zu Erstellung von Lastenheft und Pflichtenheft
In der Regel wird im Kundenvertrag auf das Lastenheft und auf das Pflichtenheft verwiesen: Die dort genannten Inhalte und Bedingungen sind zum Zeitpunkt der Vertragsunterzeichnung dann für beide Vertragspartner über die gesamte Projektlaufzeit bindend.
1.1 Definitionen
In der deutschsprachigen Literatur zum Projektmanagement wird oftmals auf Lasten- und Pflichtenhefte eingegangen, die Literatur zum Anforderungsmanagement (Requirements Engineering, Business Analysis) vermeidet diese Begriffe eher (und verwendet stattdessen den allgemeineren Begriff Spezifikationen).
In der deutschen Norm zum Projektmanagement DIN 69901–5:2009 /DIN16/ finden sich folgende Definitionen:
- Lastenheft (user specification): Vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines (Projekt-)Auftrags
- Pflichtenheft (functional specification): Vom Auftragnehmer erarbeitete Realisierungsvorgaben auf der Basis des vom Auftraggeber vorgegebenen Lastenheftes
In der deutschen Projektmanagement-Literatur sind oftmals Beschreibungen für das Lasten- und Pflichtenheft anzutreffen. So definiert beispielsweise Jakoby /Jakoby18/:
- “Lastenheft: Ein Lastenheft beschreibt aus Sicht des Auftraggebers die Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Projekts. Vor allem in der Baubranche wird es auch als Leistungsverzeichnis bezeichnet
- Pflichtenheft: Das Pflichtenheft beschreibt aus Sicht des Auftragnehmers Art und Umfang der Lieferungen und Leistungen, zu denen er sich verpflichtet”
In der Wikipedia /Wiki‑d/ finden sich zwei Eintragungen für Lastenheft (Product Requirements Document) und Pflichtenheft (Functional Specification).
Dort heißt es:
- “Das Lastenheft (teils auch Anforderungsspezifikation, Anforderungskatalog, Produktskizze, Kundenspezifikation oder englisch Requirements Specification genannt) beschreibt die Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers. Es ist z.B. im Software-Bereich das Ergebnis einer Anforderungsanalyse und damit ein Teil des Anforderungsmanagements.” /#Wiki-Lastenheft/
- “Das Pflichtenheft beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen des Auftraggebers zu lösen gedenkt – das sogenannte wie und womit. Der Auftraggeber beschreibt vorher im Lastenheft möglichst präzise die Gesamtheit der Forderungen – was er entwickelt oder produziert haben möchte. Erst wenn der Auftraggeber das Pflichtenheft akzeptiert, sollte die eigentliche Umsetzungsarbeit beim Auftragnehmer beginnen.” /#Wiki-Pflichtenheft/
1.2 Synonyme
Für das Lastenheft (“Was und Wofür”) sind unter anderem auch folgende Begriffe zu finden:
- Anforderungsspezifikation
- Leistungsverzeichnis
- Anforderungskatalog
- Produktskizze
- Kundenspezifikation
- engl. Customer Requirements Specification (CRS)
- engl. User Specification
- engl. Statement of Work (SOW)
- engl. Requirements Specification
- engl. Product Requirements Document
- engl. Terms of Reference
Statt Pflichtenheft (“Wie und Womit”) werden auch folgende Begriffe verwendet:
- Systemspezifikation
- Fachspezifikation
- Fachliche Spezifikation
- Fachfeinkonzept
- Sollkonzept
- Funktionelle Spezifikation
- Gesamtsystemspezifikation
- Implementierungsspezifikation
- engl. Project Scope Statement
- engl. System Requirements Specification (SRS)
- engl. Feature Specification
- engl. Functional Specification
- engl. Solution Concept
- engl. Design Specification
- engl. Technical Specification
1.3 Ein idealtypischer Ablauf bis zum Projektstart
Der Ablauf von der Erstellung des Lastenhefts bis zum Projektstart (und der Erstellung des Pflichtenhefts) kann in folgenden Einzelschritten ablaufen (siehe nächste Grafik):
- Der Kunde (Auftraggeber, AG) erstellt das Lastenheft (LH)
- Der Kunde reicht das Lastenheft an den (potenziellen) Auftragnehmer (AN) weiter
- Der Auftragnehmer überprüft das Lastenheft und reicht es intern an den (potenziellen) → Projektmanager weiter
- Der Projektmanager erstellt ein (vorläufiges) Pflichtenheft (PH) und einen Abnahmekatalog (AK). Sowohl Pflichtenheft wie auch Abnahmekatalog können an den Kunden gehen; das Pflichtenheft enthält verschiedene Abschätzungen (Aufwand, Dauer, Kosten)
- Auf der Basis der Angaben im Pflichtenheft wird ein Kundenvertrag durch den Auftragnehmer erstellt
- Der Kundenvertrag wird an den Kunden weitergereicht
- Der Kundenvertrag wird vom Kunden geprüft, unterzeichnet und zurückgegeben
- Nach Freigabe des Kundenvertrags wird der interne Projektauftrag freigegeben und das Projekt kann starten
Abbildung 1.4: Vom Lastenheft zum Kundenvertrag
Bei diesem Ablauf sind Iterationen nicht erfasst, dennoch wird offensichtlich, dass es an vielen Stellen (an den Übergabepunkten) zu Schwierigkeiten kommen kann. Die Erstellung von Angeboten ist hier ebenfalls nicht berücksichtigt.
1.4 Lastenheft und Pflichtenheft im Projektverlauf
Betrachtet man ein sechsstufiges Phasenmodell für Projekte und ordnet dort Lastenheft und Pflichtenheft ein, so ergibt sich (vereinfacht) folgendes Bild:
Abbildung 1.5: Lastenheft und Pflichtenheft und die → Projektphasen
Vor dem eigentlichen Projektstart, d.h. während der Initialisierungs- und Definitionsphase, wird auf Basis des Lastenhefts ein (vorläufiges) Pflichtenheft erstellt. Dieses Pflichtenheft ist die Grundlage des Abnahmekatalogs und führt zum Kundenvertrag. Erst mit Unterzeichnung des Kundenvertrags startet das Projekt und es entstehen im Projektverlauf eine Reihe von weiteren Dokumenten, die aber in erster Linie projektintern verwendet werden. Das Pflichtenheft kann jedoch im Laufe des Projekts weiter ergänzt werden und wird schließlich zum endgültigen Pflichtenheft, welches — je nach Vereinbarung — an den Kunden weitergereicht werden kann.
Bei → Projektabschluss erfolgt die Produktabnahme (auf Basis des Abnahmekatalogs) und ein Dokument zur Projektabnahme (beispielsweise ein Abnahmeprotokoll) wird verfasst, welches ebenfalls an den Kunden gehen kann.
1.5 Schwierigkeiten in der Praxis
Bei der Verwendung von Lastenheft und Pflichtenheft tauchen häufig die immer gleichen Probleme auf. Hier werden einige gelistet, wobei die Kunden- und Auftragnehmersichten sehr unterschiedlich sein können.
- Das Lastenheft des Kunden ist nicht “gut genug”, um daraus ein Pflichtenheft abzuleiten
- Das Lastenheft enthält “Soll- und Könnte-Formulierungen”, für die nicht klar ist, ob sie umgesetzt werden müssen
- Die Erstellung des (vorläufigen) Pflichtenhefts ist aufwendig und teuer: Kommt dann kein Auftrag zustande, sind die getätigten Investitionen wertlos
- Das Pflichtenheft nimmt keinen Bezug zum Lastenheft: Ob alle Anforderungen des Lastenhefts im Pflichtenheft abgedeckt werden, bleibt unklar
- Das vorläufige Pflichtenheft wird zwar zum endgültigen Pflichtenheft weiterentwickelt, der Bezug zwischen den beiden Fassungen kann aber nicht mehr hergestellt werden
- Der Kunde möchte ein vollständiges, endgültiges Pflichtenheft erhalten, obwohl dies nicht vertraglich vereinbart wurde
- Mit dem Kunden ist vereinbart worden, dass er ein vollständiges, endgültiges Pflichtenheft bei Projektabschluss erhält. Dieses endgültige Pflichtenheft wird aber nicht erstellt, sodass die Dokumentation des Projektprodukts unzureichend werden kann
- Der Kunde versteht wesentliche Teile des Pflichtenhefts nicht, was dazu führt, dass der Abnahmekatalog keine Relevanz hat
2. Erstellung von Lastenheft und Pflichtenheft
Generell sollten das Lastenheft und das Pflichtenheft mit Hilfe der → Werkzeuge und Methoden des Requirements Engineerings und der Business Analysis erstellt werden. Daher sind Kenntnisse auf diesen Gebieten für die Erstellung unbedingt notwendig.
Das Lastenheft erfasst aus Sicht der Business Analysis die Business Requirements, das Pflichtenheft die Solution Requirements. Die Stakeholder Requirements werden sowohl im Lasten- wie auch im Pflichtenheft erfasst (Abbildung 2.1).
Abbildung 2.1: Lasten- und Pflichtenheft und die Requirements-Typen
2.1 Das Lastenheft
Zum formalen Aufbau eines Lastenhefts gibt es in der Literatur verschiedene Vorgaben und Ansätze.
Es kann folgende Struktur / Gliederung als Basis verwendet werden:
- Einleitung und Motivation
- Inhalt
- Beschreibung der Ist-Situation
- Beschreibung der Soll-Situation
- Umfang mit allen gelisteten Anforderungen
- Organisatorische Rand- und Rahmenbedingungen
- Technische Schnittstellen
- Technische Randbedingungen
- Ausschlüsse
- → Glossar
- Anhang
- Mitgeltende Dokumente und Regelungen
Weitere Gliederungen finden sich in der Literatur zum Projektmanagement oder zum Requirements Engineering. Hier sind insbesondere zu nennen: Die Gliederung nach …
- dem → V‑Modell XT /#V‑Modell-XT-Lastenheft/.
- dem Volere-Template /#Wiki-Volere/.
- IEEE, so z.B. IEEE 830‑1998 oder IEEE 29148–2018.
Der Aufbau / die Gliederung dieser Standards ist beispielsweise beschrieben in meiner umfassenden Ausarbeitung zum Requirements Engineering: → Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) 
.
Generell sollte das Lastenheft eine Nummerierung der Kapitel und der einzelnen Anforderungen aufweisen, um so eine Zuordnung vornehmen zu können. Ebenso notwendig ist eine Versionierung mit Versionshistorie sowie Revisionsverweisen.
Was gehört nun zu einem “guten” Lastenheft und was nicht? Auch wenn es hier keine eindeutige Antwort gibt, so liefert nachfolgende Tabelle einen groben Überblick.
| Element | Muss | Soll | Kann | Soll nicht | Darf nicht |
|---|---|---|---|---|---|
| Deckblatt mit Versionshistorie (und Revisionsvermerken) | X | ||||
| Gliederung mit Kapitelnummern | X | ||||
| Benennung der → Ziele des Vorhabens / Projekts | X | ||||
| Organisatorische Rahmenbedingungen | X | X | |||
| Rechtliche Rahmenbedingungen | X | X | |||
| Technische Rahmen- oder Randbedingungen | X | ||||
| Fachlandkarte | X | ||||
| Anwendungslandkarte | X | ||||
| → Liste aller funktionalen Anforderungen | X | ||||
| Liste der nicht-funktionalen Anforderungen | X | ||||
| → UML-Grafiken (oberste Ebene) / → Use Cases | X | ||||
| Stakeholderbetrachtungen (grob) | X | ||||
| Risikobetrachtungen (grob) | X | ||||
| Wirtschaftlichkeitsbetrachtungen (grob) | X | ||||
| Betrachtungen zur Betriebseinführung | X | ||||
| Mengengerüste | X | X | |||
| Wachstumsabschätzungen | X | X | |||
| Ausschlüsse | X | ||||
| Arbeitsabläufe / Prozesse | X | X | |||
| Datenmodell | X | ||||
| Mockups / Wireframes | X | ||||
| Abnahmekriterien (grob) | X | X | X | ||
| Glossar / Fachglossar | X | X | |||
| Zu beachtende Normen und Standards | X | ||||
| Mitgeltende Dokumente | X | ||||
| Grober Projektplan / Meilensteinplan | X | X | |||
| Klassendiagramme | X | ||||
| Lösungsumsetzungen | X | ||||
| Vollständiger Projektplan mit festen Terminen | X |
In der Praxis zeigt sich, dass in vielen Lastenheften wesentliche Elemente, die sich aus der Gliederung ergeben, nicht vorhanden sind. Derartige Lastenheft sind dann häufig wertlos.
2.1.1 Einige typische Fehler und Fallstricke
Hier sind einige “typische” Fehler und Fallstricke bei der Erstellung von Lastenheften aufgeführt:
- Das Lastenheft ist nicht durchgängig im Präsens verfasst — das ist nicht erlaubt
- Das Lastenheft enthält “könnte”- und “sollte”-Formulierungen, deren Umsetzung daher unklar bleibt — das ist nicht erlaubt
- Nicht benötigte Elemente wie Ausschlüsse oder mitgeltende Dokumente werden weggelassen, sodass sich später bei der Umsetzung herausstellt, dass Neben-Inhalte nicht benannt wurden. Daher: Auch wenn es keine Ausschlüsse oder mitgeltenden Dokumente gibt, muss dies auch so benannt werden
- Die mitgeltenden Dokumente sowie die Normen und Standards haben als Gültigkeit “den aktuellen Zeitpunkt” angegeben; zwischen Lastenheftweitergabe und Pflichtenhefterstellung sowie Vertragsunterzeichnung können sich aber Änderungen ergeben, sodass unterschiedliche Auffassungen entstehen können. Daher: Alle mitgeltenden Dokumente, Normen und Standards müssen mit ihrem konkreten Stand benannt werden
- Es finden sich Formulierungen wie “genauso wie beim Altsystem, nur besser”. Dies kann in der Regel kaum von außen nachvollzogen werden. Daher: Verweise auf Altsysteme sollten vermieden werden
- Nicht-funktionale Anforderungen werden nicht konkretisiert, sodass ein Interpretationsspielraum entsteht und die nicht-funktionalen Anforderungen nicht operationalisiert werden können. Beispiel: “Das Wasser muss in kurzer Zeit ausreichend warm werden” ist nicht hilfreich, besser wäre: “Das Wasser muss innerhalb von 2 Minuten von 20 °C auf 60 °C erhitzt werden können”. Daher: Alle nicht-funktionalen Anforderungen müssen herausgestellt und operationalisiert werden
2.1.2 Einige Tipps und Tricks
Wenn Sie Lastenhefte erstellen müssen, so können folgende Empfehlungen hilfreich sein:
- Wenn das Lastenheft für Sie / für Ihr Vorhaben wirklich eine Bedeutung hat, so lassen Sie es durch Profis erstellen und auch (separat) durch Profis prüfen. Alles andere ist zu teuer
- Erstellen Sie Übersichtsgrafiken (für wesentliche Teile), denn “ein Bild sagt mehr als 1.000 Worte”
- Benennen Sie die Hintergründe der (wichtigsten) Anforderungen: Wenn die Intention einer Anforderung klar wird, so kann der Lösungsvorschlag einfacher erstellt werden
- Beachten Sie das “Zielpublikum” und verfassen Sie die Beschreibungen entsprechend: Wer soll das Lastenheft in erster Linie verstehen und verwenden? Sie (als Kunde) oder der potenzielle Auftragnehmer?
- Ordnen Sie jeder (einzelnen) Anforderung eine Quelle (wer wollte das / warum muss das sein) und einen Verantwortlichen zu
- Versionieren Sie — auf jeder Seite des Lastenhefts muss die Versionsnummer und das Versionsdatum erkennbar sein
2.1.3 Überprüfen vor der Frei- oder Weitergabe
Wenn das Lastenheft “fertig” ist, so sollte man dennoch ein → Review (“manuelle Prüfung”) vornehmen, um so die Qualität zu überprüfen und zu verbessern. Hierzu kann man eine Stellungnahme, eine Inspektion oder ein Walkthrough vornehmen. Mehr hierzu auf der Webseite “Requirements Engineering — 5. Das Prüfen und Abstimmen von Anforderungen” oder in meiner Präsentation → Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) .
2.2 Das Pflichtenheft
Das Pflichtenheft kann in einem ersten Schritt durch Übertragung und Anpassung des Lastenhefts entstehen (Abbildung 2.2).
Abbildung 2.2: Ableitung des Pflichtenhefts aus dem Lastenheft
Das vertragsrelevante, vorläufige Pflichtenheft kann dann im Laufe der Projektabwicklung nach und nach zu einem vollständigen Pflichtenheft weiterentwickelt werden (Abbildung 2.3). Bei Beendigung des Projekts liegt dann aber (immer) das endgültige Pflichtenheft vor, welches den abschließenden Stand der Entwicklung dokumentiert.
Abbildung 2.3: Vom vorläufigen zum endgültigen Pflichtenheft
Typischerweise hat das Pflichtenheft einen größeren Umfang als das Lastenheft. In der Regel geht man bei dem vertragsrelevanten, vorläufigen Pflichtenheft von einem Größenzuwachs um den Faktor 2 bis 3 gegenüber dem Lastenheft aus (siehe Abbildung 2.4). Wird das Pflichtenheft im Laufe des Projekts weiter ausgebaut, ergänzt und verfeinert so sind häufig Größenzuwächse um den Faktor 4 bis 10 zu finden.
Abbildung 2.4: Das Größenverhältnis von Lastenheft und Pflichtenheft
Um das Pflichtenheft nicht zu umfangreich werden zu lassen und auch um organisationsinterne oder vertrauliche Teile abzutrennen, werden in der Praxis häufig weitere, ergänzende technische Unterlagen (in Abbildung 2.4 “WTU — Weitere technische Unterlagen”) erstellt, die einen Bezug zum Pflichtenheft haben können (aber nicht haben müssen).
Generell ist das Pflichtenheft die “Antwort auf das Lastenheft”. Entsprechend müssen sich alle Anforderungen des Lastenhefts im Pflichtenheft wiederfinden lassen. Dies geschieht in der Regel durch Nummerierungen der einzelnen Anforderungen im Lastenheft und im Pflichtenheft und Verweisen zwischen den Einzelanforderungen.
Beispiel: Aus einem Lastenheft mit drei Anforderungen (LH-01, LH-02, LH-03) ergeben sich die Umsetzungsanforderungen PH-01, PH-02 und PH-03 mit ihren Detaillierungen (hier durch angehängte Kleinbuchstaben gekennzeichnet):
- LH-01 ergibt PH-01a, PH-01b
- LH-02 ergibt PH-02
- LH-03 ergibt PH-03a, PH-03b, PH-03c, PH-03d
Abbildung 2.5: Die Zusammenhänge der Einzelanforderungen im Lasten- und Pflichtenheft
Die Nachvollziehbarkeit, ob alle Anforderungen aus dem Lastenheft auch entsprechende Anforderungen im Pflichtenheft besitzen, muss gewährleistet sein, insbesondere wenn dies vertragsrelevant ist. Daher werden Verweise zwischen den Anforderungen erstellt und auch bis zum Projektende gepflegt. Bei einer geringen Anzahl von Anforderungen kann dies noch “von Hand” erfolgen, ab einer bestimmten Anzahl müssen aber softwaregestützte Tools eingesetzt werden.
Nicht alle Anforderungen des Lastenhefts müssen umsetzungsrelevant sein, jedoch sollten die nicht relevanten Anforderungen im Lastenheft deutlich erkennbar sein.
Abbildung 2.6: Nicht relevante Einzelanforderungen im Lastenheft
2.3 Umfang und Status des Pflichtenhefts
Das Pflichtenheft muss in der Regel immer dann erstellt werden, wenn der Kunde bei seiner Anfrage ein Lastenheft beifügt. In der Abbildung 2.7 sind vier Fälle gegenübergestellt, die jeweils auf der Annahme basieren, dass der Kunde ein “gutes Lastenheft” mitgeliefert hat.
Abbildung 2.7: Umfang und Form des Pflichtenhefts
Was ist jedoch zu tun, wenn der Kunde kein Lastenheft liefert und dennoch einen Auftrag erteilen möchte? Generell sollte dann der Auftrag abgelehnt werden, aber: Wenn dennoch das Projekt mit dem Kunden gestartet werden soll, so gibt es vier Möglichkeiten (Abbildung 2.8):
- Es wird ohne Pflichtenheft im Projekt gearbeitet, ein Werkvertrag (mit Festpreisvereinbarung) kann auf dieser Basis nicht entstehen, eine Vereinbarung auf Zeit- und Aufwand-Basis jedoch wohl
- Vor Projektstart wird zunächst das Lastenheft erstellt und von dem Kunden abgenommen. Auf dieser Basis entsteht das Pflichtenheft, sodass das Projekt den “normalen Ablauf” nehmen kann
- Auf das Lastenheft wird verzichtet und direkt das Pflichtenheft vor Projektstart erstellt (und von dem Kunden abgenommen) — das Projekt kann den “normalen Ablauf” nehmen
- Das Pflichtenheft entsteht parallel zur Projektumsetzung, der Kunde erhält es erst zum Projektende
Abbildung 2.8: Pflichtenhefterstellung: Was tun ohne Lastenheft?
3. Gegenüberstellungen Lastenheft und Pflichtenheft
Hier werden zur Unterscheidung Lastenheft und Pflichtenheft aus folgenden Sichten gegenübergestellt:
- Gesamtdarstellung
- Auftraggeber- und Auftragnehmer-Sicht
- Normen und Richtlinien
- Bezug zu den Spezifikationen
In der Gegenüberstellung in Abbildung 3.1 sind vereinfachte Stichpunkte wiedergeben. Diese sollten für den Einsatz im eigenen Kontext überprüft und weiter konkretisiert werden.
Abbildung 3.1: Gegenüberstellung Lastenheft und Pflichtenheft: Gesamtdarstellung
In der Abbildung 3.2 sind Sichten des Auftragnehmers und des Auftraggebers zum Thema Lastenheft und Pflichtenheft dargestellt. Hervorzuheben ist der Aspekt des “Einblicks in die Leistungsfähigkeit”: Überzeugen das Lastenheft und das Pflichtenheft, so kann mit hoher Wahrscheinlichkeit davon ausgegangen werden, dass die nachfolgende, gemeinsame Projektabwicklung auf einem hohen Niveau stattfinden wird.
Abbildung 3.2: Gegenüberstellung Lastenheft und Pflichtenheft: Auftraggeber- und Auftragnehmer-Sicht nach /#Doctima-15/
Nur wenige Normen, Standards und Richtlinien erläutern die Begriffe Lastenheft und Pflichtenheft oder nehmen Bezug darauf. Hervorzuheben ist hier die (deutsche) Projektmanagementnorm DIN 69901–5 aus dem Jahr 2009, die die Begriffe definiert (siehe Abbildung 3.3).
Abbildung 3.3: Gegenüberstellung Lastenheft und Pflichtenheft: Normen und Richtlinien
Die Tabelle in Abbildung 3.4 stellt die Unterkategorien zu Lastenheft und Pflichtenheft dar: Während das Lastenheft “für sich” steht und als Ergebnis einer Anforderungserhebung gesehen werden kann, erhält das Pflichtenheft häufig — entsprechend der Detaillierung — andere Bezeichnungsweisen, die aber immer den Teilbegriff Spezifikation verwenden.
Abbildung 3.4: Gegenüberstellung Lastenheft und Pflichtenheft: Bezug zu den Spezifikationen
4. Einbettung in den Projektkontext
Mit der Erstellung eines Lastenhefts und eines Pflichtenhefts zu Projektstart entstehen auch weitere Dokumente, die für den weiteren Verlauf (bis zur Produktabnahme) relevant werden. Dies ist insbesondere der “Abnahmekatalog”, der im Idealfall vor Vertragsunterzeichnung erstellt und durch den Kunden abgenommen wird.
Abbildung 4.1: Lastenheft und Pflichtenheft: Von der Erstellung zur Produktabnahme
In Abbildung 4.1 ist dargestellt, wie mit dem Pflichtenheft (bei der Softwareerstellung) weiter verfahren wird: Aus dem Pflichtenheft wird der Abnahmekatalog erstellt, der festlegt, welche Punkte bei der Abnahme des Produkts berücksichtigt werden müssen. Im Idealfall ist der Abnahmekatalog in der Form einer Liste aufgebaut, die dann bei der Produktabnahme herangezogen werden kann.
Aus dem ursprünglichen Pflichtenheft wird zudem eine Feinspezifikation erstellt, die dazu dient, die Vorgaben so genau zu benennen, dass es möglich wird, Umsetzungen und Tests auf Arbeitspaket- oder Funktionsebene vorzunehmen.
Wird das Pflichtenheft im Projektverlauf weiterentwickelt, so sollten zu den Übergabepunkten im Projekt auch immer (eigenständige) versionierte Pflichtenhefte entstehen: Diese können dann auch auditiert und gereviewt sowie an den Auftraggeber weitergereicht werden. Typische Übergabepunkte sind die Meilensteine in (phasenorientierten) Projekten (Abbildung 4.2). Eine andere Möglichkeit wäre eine Kopplung an Releases oder an kalendarische Zeitpunkte (wie beispielsweise dem Monatsende).
Abbildung 4.2: Pflichtenheft: Weiterentwicklung bis zur endgültigen Fassung
5. Das Konzept von Lastenheft und Pflichtenheft in heutiger Zeit
Die Idee, Soll-Anforderungen von den Ist-Anforderungen über Lasten- und Pflichtenheft zu trennen, ist durchaus sinnvoll. Dennoch muss hinterfragt werden, ob dieses Konzept auch heute noch tragfähig ist.
Folgende Überlegungen und Betrachtungen sind dabei relevant:
- Ist ein Lastenheft fertig, so sind die Inhalte auch potenziell vertragsrelevant. Hiermit geht eine gewisse Schwerfälligkeit einher: Änderungen an bestehenden Verträgen sind mit Aufwand verbunden
- Die agile Projekt- und Produktentwicklungswelt basiert auf (leichtgewichtigen) → User Stories, die Kundenwünsche repräsentieren. Lastenhefte kommen in diesem Kontext nicht vor und sind auch nicht notwendig
- Um große Systeme zu spezifizieren, werden in der Regel software-gestützte Tools eingesetzt, in denen die Anforderungen einzeln erfasst und beschrieben werden. Herausgelöste Dokumente, wie Lastenhefte oder Pflichtenhefte sind dann wenig hilfreich, da sie nur eine Momentaufnahme wiedergeben und kaum als “Einzeldokumente” verwendet werden können; Lastenhefte und Pflichtenhefte sind dann eher als Berichte zu sehen
5.1 Wann Sie auf “Lastenheft und Pflichtenheft” verzichten sollten
In folgenden Konstellationen sollten Sie auf die Verwendung von “Lastenheft und Pflichtenheft” verzichten:
- Wenn Sie in erster Linie nach agilem Vorgehen arbeiten
- Bei rein internen Projekten
- Bei sehr großen Projekten, die viele hundert bis einige tausend Anforderungen umfassen
5.2 Wann Sie Lastenhefte und Pflichtenhefte einsetzen sollten
In folgenden Konstellationen sind “Lastenheft und Pflichtenheft” durchaus sinnvoll oder notwendig:
- Als Auftragnehmer: Wenn der potenzielle Kunde / Auftraggeber ein ausgearbeitetes Lastenheft vorlegt
- Bei kleineren Beschaffungsprojekten
- Bei rechtlichen oder organisatorischen Vorgaben
- In einigen Branchen, bei denen das Konzept etabliert ist und in Ablaufprozessen gelebt wird
6. Häufige Fragen und Antworten zum Thema “Lastenheft und Pflichtenheft”
Einige Fragen zu Lastenheft und Pflichtenheft werden häufig gestellt – diese werden hier wiedergegeben und beantwortet.
- F: Ist die Unterscheidung von Lastenheft und Pflichtenheft “streng”?
A: Ja und nein. Die Übergänge und Inhalte von Lastenheft und Pflichtenheft können fließend sein. In einem Projekt sollte daher vorab geklärt werden, welche Bedeutung Lastenheft und Pflichtenheft haben. - F: Muss der Kunde Lastenheft selber “schreiben”?
A: Nein – der Kunde muss das Lastenheft “liefern” und kann es auch (durch Dritte) schreiben lassen. Der Kunde ist aber immer für das Lastenheft verantwortlich. - F: Ist eine Anforderungsliste schon ein Lastenheft?
A: Nein, in der Regel nicht. Eine Anforderungsliste beschreibt Anforderungen in Listenform. Bei Lastenheft sollten auch Zusammenhänge erläutert werden. - F: Kann das Lastenheft aus mehreren Dokumenten bestehen?
A: Ja, aber im Normalfall ist das Lastenheft genau ein Dokument — das ist gerade die Besonderheit. - F: Ist das Lastenheft “vertragsrelevant”?
A: Ja. Das Lastenheft ist im Allgemeinen dem Kundenvertrag hinzuzufügen, da es die Basis des Kundenvertrags darstellt. - F: Darf das Lastenheft nach Vertragsunterzeichnung geändert werden?
A: Ja – aber nur in Ausnahmefällen. Ergibt sich im Laufe der Umsetzung, dass bestimmte Teile anders umgesetzt werden müssen als in der Ursprungsplanung vorgesehen, so kann das Lastenheft geändert werden. Allerdings sollten beide Parteien der Änderung zustimmen. - F: Muss immer ein Pflichtenheft erstellt werden?
A: Nicht unbedingt. Wenn das Lastenheft bereits detailliert genug ist, sodass direkt in die Umsetzung gegangen werden kann, so kann auf ein Pflichtenheft verzichtet werden. Diese Vorgehensweise bietet sich aber nur bei kleinen Projekten oder Projekten mit Standardbestandteilen an. Zudem muss von beiden Vertragspartnern ausdrücklich darauf hingewiesen werden, dass auf das Pflichtenheft verzichtet wird. - F: Ist das Pflichtenheft “vertragsrelevant”?
A: Ja. Zumindest in der “Erst-” oder vorläufigen Fassung. - F: Lässt sich aus dem Pflichtenheft das Lastenheft ableiten?
A: Nein, in der Regel nicht, da die Motivation für eine Einzelanforderung sich in der Regel nur im Lastenheft befindet. - F: Wird das endgültige Pflichtenheft (welches zum Abschluss des Projekts entsteht) an den Kunden weitergereicht?
A: Das kommt auf die Vereinbarung zwischen Kunden und Auftragnehmer an. Häufig wünschen die Kunden bei Projektabnahme auch ein endgültiges, abgeschlossenes Pflichtenheft, während es aus Auftragnehmersicht häufig günstiger ist, das Pflichtenheft nur intern zu verwenden. - F: Muss das Lastenheft durch den Auftraggeber (Kunden) oder durch den Auftragnehmer (Lieferanten) erstellt werden?
A: Grundsätzlich muss der Kunde bei Beauftragung ein “valides” Lastenheft vorlegen, denn nur so kann sichergestellt werden, dass ein Angebot auch die Kundenwünsche berücksichtigt. - F: Wie groß ist der Aufwand zur Erstellung eines Lastenhefts?
A: Hierzu gibt es keine pauschale Antwort, denn der Aufwand hängt von vielen Parametern ab. In der Praxis ist jedoch festzustellen, dass der Aufwand häufig massiv unterschätzt wird. - F: Kann der Auftraggeber die Lastenhefterstellung nicht (einfach) durch einen externen Experten durchführen lassen?
A: Ja und nein. Auch wenn externe Experten viele Aufgaben bei der Lastenhefterstellung übernehmen können, so muss der Auftragnehmer sein Know-how und seine Bedürfnisse miteinbringen — auch das kostet Zeit und wird in der Praxis häufig unterschätzt.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
A.1 Meine öffentliche Präsentation zu Lastenheft und Pflichtenheft
Die Präsentation ist in weiten Teilen deckungsgleich mit der Darstellung auf dieser Website und kann für eine “Schnelldarstellung” genutzt werden.
| Inhalt | Version | Stand | Seiten | Größe | Typ |
|---|---|---|---|---|---|
| Projektmanagement: Lastenheft und Pflichtenheft – Eine Übersicht | 1.00 | 01/2020 | 72 | 0,5 MB | |
Ebenfalls von hoher Relevanz zum Thema Lastenheft und Pflichtenheft sind meine folgenden → Präsentationen:
| Inhalt | Version | Stand | Seiten | Größe | Typ |
|---|---|---|---|---|---|
| Projektmanagement – Eine Einführung (PM-Basispräsentation) | 1.83 | 09/2012 | 228 | 1,2 MB | |
Projektmanagement: Ziele im Projekt, Zielentwicklung und SMARTe Zielformulierung – Eine Übersicht  | 0.60 | 08/2015 | 86 | 0,6 MB | |
| Projektmanagement: Stakeholdermanagement – Eine Übersicht | 0.10 | 03/2015 | 138 | 0,8 MB | |
| Projektmanagement: Beschaffung (Procurement) – Eine Übersicht | 0.20 | 03/2018 | 104 | 0,5 MB | |
| Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) | 0.96 | 03/2017 | 248 | 1,3 MB | |
| Requirements Engineering: Spezifikationen – Eine Übersicht | 1.50 | 12/2016 | 44 | 0,3 MB | |
A.2 Literatur zu Lastenheft und Pflichtenheft
- /DIN16/ DIN: Projektmanagement. Netzplantechnik und Projektmanagementsysteme. DIN-Taschenbuch 472, Beuth, Berlin 3. Auflage 2016, ISBN 978–3‑410–27041‑6
- /GPM16/ Deutsche Gesellschaft für Projektmanagement: Kompetenzbasiertes Projektmanagement (PM3), → GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 8. Auflage 2016, ISBN 978–3‑924841–40‑9
- /GPM19/ Deutsche Gesellschaft für Projektmanagement: Kompetenzbasiertes Projektmanagement (PM4), GPM, Deutsche Gesellschaft für Projektmanagement, Nürnberg 2019, ISBN 978–3‑924841–77‑5
- /IREB15/ Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering: Aus- und Weiterbildung nach → IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt, Heidelberg 4. Auflage 2015, ISBN 978–3‑86490–283‑3
- /Jakoby18/ Walter Jakoby: Projektmanagement für Ingenieure: Ein praxisnahes Lehrbuch für den systematischen Projekterfolg, Springer Vieweg, Wiesbaden 4. Auflage 2018, ISBN 978–3‑658–23332‑7
- /Patzak17/ Gerold Patzak, Günter Rattay: Projektmanagement. Projekte, Projektportfolios, Programme und projektorientierte Unternehmen, Linde, Wien 7. Auflage 2017, ISBN 978–3‑7143–0321‑6
- /PBG17/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), → PMI, Project Management Institute, Philadelphia, Pennsylvania Sixth Edition 2017, ISBN 978–1‑62825–184‑5
- /PBG17‑d/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), PMI, Project Management Institute, Philadelphia, Pennsylvania Sechste Ausgabe 2017, ISBN 978–1‑62825–188‑3
- /Pfingsten16/ Maik Pfingsten: Erfolgreich Lastenhefte schreiben. Eine Schritt-für-Schritt-Anleitung aus der Praxis eines Troubleshooters, Books on Demand, Norderstedt 2. Auflage 2016, ISBN 978–3‑7392–4911‑7
A.3 Weblinks zu Lastenheft und Pflichtenheft
- /#Doctima-15/ Fa. Doctima, Vortrag am 26.03.2015: Lasten- und Pflichtenhefte für IT-Projekte (“https://www.nik-nbg.de/uploads/tx_seminars/doctima_Lasten-und-Pflichtenhefte.pdf”)
- /#IREB-Glossar-17/ IREB: Glossar des IREB, Version 1.7 vom Mai 2017
- /#IREB-Glossar-20/ IREB: Glossar des IREB, Version 2.0.1 vom Oktober 2020
- /#V‑Modell-XT-Lastenheft/ Beschreibung des Lastenhefts im V‑Modell-XT
- /Wiki‑d/ Deutsche Wikipedia
- /#Wiki-Lastenheft/ Lastenheft (engl. Product Requirements Document) in der deutschen Wikipedia
- /#Wiki-Pflichtenheft/ Pflichtenheft (engl. Functional Specification) in der deutschen Wikipedia
- /#Wiki-Spezifikation/ Spezifikation in der deutschen Wikipedia
- /#Wiki-Volere/ Das Volere-Template in der deutschen Wikipedia
- /#Wolf-15/ Max Wolf: “Die Last mit der Last” (pdf-Datei, 8 Seiten, deutsch): www.wolf-pmt.de/wp-content/uploads/2015/12/Encrypted_Die-Last-mit-der-Last_WOLF-PMT.pdf
Legende zu den Weblinks
/ / Verweis auf eine Website (generell)
/*/ Verweis auf eine Website, die als Buch-Ergänzung dient
/#/ Verweis auf einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 30.04.2019 © Peterjohann Consulting, 2005–2021