header-image

Lastenheft und Pflichtenheft Unterscheidungen und Einsatz

Ein Dauerthema in der deutschsprachigen Projektmanagement-Gemeinschaft ist der Gebrauch von Lastenheft und Pflichtenheft. In diesem Beitrag wird eine Übersicht mit verschiedenen Blickwinkeln geliefert.

Management-Zusammenfassung zu diesem Beitrag:
Lastenheft und Pflichtenheft werden im deutschsprachigen Projektmanagement-Umfeld häufig benutzt.
Dennoch ist 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.

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.

Einordnung von Lastenheft und Pflichtenheft, (C) Peterjohann Consulting, 2018-2019

Abbildung 0.1: Einordnung von Lastenheft und Pflichtenheft


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.

Erstellung von Lastenheft und Pflichtenheft, (C) Peterjohann Consulting, 2018-2019

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.

Erstellung von Lastenheft, Pflichtenheft und Kundenvertrag, (C) Peterjohann Consulting, 2018-2019

Abbildung 1.2: Erstellung von Lastenheft, Pflichtenheft und Kundenvertrag

Legende zu Erstellung von Lastenheft und Pflichtenheft, (C) Peterjohann Consulting, 2018-2019

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 finden sich oftmals Beschreibungen für das Lasten- und Pflichtenheft. So definiert beispielsweise Jakoby /Jakoby15/:

  1. „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
  2. 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:

  1. „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/
  2. „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):

  1. Der Kunde (Auftraggeber, AG) erstellt das Lastenheft (LH)
  2. Der Kunde reicht das Lastenheft an den (potenziellen) Auftragnehmer (AN) weiter
  3. Der Auftragnehmer überprüft das Lastenheft und reicht es intern an den (potenziellen) Projektmanager weiter
  4. 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)
  5. Auf der Basis der Angaben im Pflichtenheft wird ein Kundenvertrag erstellt
  6. Der Kundenvertrag wird an den Kunden weitergereicht
  7. Der Kundenvertrag wird vom Kunden geprüft, unterzeichnet und zurückgegeben
  8. Nach Freigabe des Kundenvertrags wird der interne Projektauftrag freigegeben und das Projekt kann starten

Vom Lastenheft zum Kundenvertrag, (C) Peterjohann Consulting, 2018-2019

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.

1.4 Lastenheft und Pflichtenheft im Projektverlauf

Betrachtet man einen sechsphasigen Projektverlauf und ordnet man dort Lastenheft und Pflichtenheft ein, so ergibt sich (vereinfacht) folgendes Bild:

Lastenheft und Pflichtenheft und die Projektphasen, (C) Peterjohann Consulting, 2018-2019

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, so dass 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 und Struktur 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).

Lasten- und Pflichtenheft und die Requirements-Typen, (C) Peterjohann Consulting, 2018-2019

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.
  • 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) pdf.

Generell sollte das Lastenheft eine Nummerierung der Kapitel und der einzelnen Anforderungen aufweisen, um so ein 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 gibt nachfolgende Tabelle einen groben Überblick.

ElementMussSollKannSoll nichtDarf nicht
Deckblatt mit Versionshistorie (und Revisionsvermerken)X
Gliederung mit KapitelnummernX
Benennung der Ziele des Vorhabens / ProjektsX
Organisatorische RahmenbedingungenXX
Rechtliche RahmenbedingungenXX
Technische Rahmen- oder RandbedingungenX
FachlandkarteX
AnwendungslandkarteX
Liste aller funktionalen AnforderungenX
Liste der nicht-funktionalen AnforderungenX
UML-Grafiken (oberste Ebene) / Use CasesX
Stakeholderbetrachtungen (grob)X
Risikobetrachtungen (grob)X
Wirtschaftlichkeitsbetrachtungen (grob)X
Betrachtungen zur BetriebseinführungX
MengengerüsteXX
WachstumsabschätzungenXX
AusschlüsseX
Arbeitsabläufe / ProzesseXX
DatenmodellX
Mockups / WireframesX
Abnahmekriterien (grob)XXX
Glossar / FachglossarXX
Zu beachtende Normen und StandardsX
Mitgeltende DokumenteX
Grober Projektplan / MeilensteinplanXX
KlassendiagrammeX
LösungsumsetzungenX
Vollständiger Projektplan mit festen TerminenX

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, so dass 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, so dass unterschiedliche Auffassungen entstehen können. Daher: Alle mitgeltenden Dokumente, Normen und Standards mit ihrem konkreten Stand benennen
  • 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, so dass 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“

2.1.2 Einige Tipps und Tricks

Wenn Sie Lastenhefte erstellen müssen, so können folgende Empfehlungen hilfreich sein:

  • Wenn das Lastenheft 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 Hintergründe: Wenn die Intention einer Anforderung klar wird, so kann der Lösungsvorschlag auch einfacher erstellt werden
  • Beachten Sie das „Zielpublikum“: 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 Engieering – 5. Das Prüfen und Abstimmen von Anforderungen“ oder → Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) pdf.

2.2 Das Pflichtenheft

Das Pflichtenheft kann in einem ersten Schritt durch Übertragung und Anpassung des Lastenhefts entstehen (Abbildung 2.1).

Ableitung des Pflichtenhefts aus dem Lastenheft, (C) Peterjohann Consulting, 2018-2019

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.

Vom vorläufigen zum endgültigen Pflichtenheft, (C) Peterjohann Consulting, 2018-2019

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 3.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.

Das Größenverhältnis von Lastenheft und Pflichtenheft, (C) Peterjohann Consulting, 2018-2019

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

Die Zusammenhänge der Einzelanforderungen im Lasten- und Pflichtenheft, (C) Peterjohann Consulting, 2018-2019

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 Lastemheft deutlich erkennbar sein.

Nicht relevante Einzelanforderungen im Lastenheft, (C) Peterjohann Consulting, 2018-2019

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 bei 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.

Umfang und Form des Pflichtenhefts, (C) Peterjohann Consulting, 2018-2019

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 Kunden abgenommen. Auf dieser Basis entsteht das Pflichtenheft, so dass das Projekt den „normalen Ablauf“ nehmen kann
  • Auf das Lastenheft wird verzichtet und direkt das Pflichtenheft vor Projektstart erstellt (und von Kunden abgenommen) – das Projekt kann den „normalen Ablauf“ nehmen
  • Das Pflichtenheft entsteht parallel zur Projektumsetzung, der Kunde erhält es erst zum Projektende

Pflichtenhefterstellung: Was tun ohne Lastenheft?, (C) Peterjohann Consulting, 2018-2019

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:

  1. Gesamtdarstellung
  2. Auftraggeber- und Auftragnehmer-Sicht
  3. Normen und Richtlinien
  4. 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.

Gegenüberstellung Lastenheft und Pflichtenheft: Gesamtdarstellung, (C) Peterjohann Consulting, 2018-2019

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.

Gegenüberstellung Lastenheft und Pflichtenheft: Auftraggeber- und Auftragnehmer-Sicht, (C) Peterjohann Consulting, 2018-2019

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 die (deutsche) Projektmanagementnorm DIN 69901-5 aus dem Jahr 2009, die die Begriffe definiert (siehe Abbildung 3.3).

Gegenüberstellung Lastenheft und Pflichtenheft: Normen und Richtlinien, (C) Peterjohann Consulting, 2018-2019

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 auf Basis der Detaillierung andere Bezeichnungsweisen, die aber immer den Teilbegriff Spezifikation verwenden.

Gegenüberstellung Lastenheft und Pflichtenheft: Bezug zu den Spezifikationen, (C) Peterjohann Consulting, 2018-2019

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.

Lastenheft und Pflichtenheft: Von der Erstellung zur Produktabnahme, (C) Peterjohann Consulting, 2019

Abbildung 4.1: Lastenheft und Pflichtenheft: Von der Erstellung zur Produktabnahme

In Abbildung 4.1 wird 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 reviewed sowie an den Auftraggeber weitergereicht werden. Typische Übergabepunkte sind die Meilensteine in (phasenorientierten) Projekten (Abbildung 4.2). Ein andere Möglichkeit wäre eine Kopplung an Releases oder an kalendarische Zeitpunkte (wie zum Monatsende).

Pflichtenheft: Weiterentwicklung bis zur endgültigen Fassung, (C) Peterjohann Consulting, 2019

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 einem gewissen 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: Kann das Lastenheft aus mehreren Dokumenten bestehen?
    A: Ja, aber im Normalfall ist das Lastemheft 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: 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 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.

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. Ressourcen

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.

InhaltVersionStandSeitenGrößeTyp
Projektmanagement: Lastenheft und Pflichtenheft – Eine Übersicht0.2001/2017320,4 MB pdf (pdf)

Ebenfalls von hoher Relevanz zum Thema Lastenheft und Pflichtenheft sind meine folgenden Präsentationen:

InhaltVersionStandSeitenGrößeTyp
Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation)0.9603/20172481,3 MB pdf (pdf)
Requirements Engineering: Spezifikationen – Eine Übersicht1.5012/2016440,3 MB pdf (pdf)
Projektmanagement: Beschaffung (Procurement) – Eine Übersicht0.2003/20181040,5 MB pdf (pdf)

A.2 Literatur

  1. /DIN16/ DIN: Projektmanagement. Netzplantechnik und Projektmanagementsysteme. DIN-Taschenbuch 472, Beuth, Berlin 3. Auflage 2016, ISBN 978-3-410-27041-6
  2. /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
  3. /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
  4. /Jacoby15/ Walter Jacoby: Projektmanagement für Ingenieure: Ein praxisnahes Lehrbuch für den systematischen Projekterfolg, Springer Vieweg, Wiesbaden 3. Auflage 2015, ISBN 978-3-658-02607-3
  5. /Patzak17/ Gerold Patzak, Günter Rattay: Projektmanagement. Projekte, Projektportfolios, Programme und projektorientierte Unternehmen, Linde, Wien 7. Auflage 2017, ISBN 978-3-7143-0321-6
  6. /PBG17/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Sixth Edition 2017, ISBN 978-1-62825-184-5
  7. /PBG17-d/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Sechste Ausgabe 2017, ISBN 978-1-62825-188-3
  8. /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

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