Pflichtenheft erstellen: ein Leitfaden für erfolgreiche Projekte

Ein Pflichtenheft entscheidet früher über Erfolg oder Scheitern eines Projekts als jede Technologie. Fast die Hälfte aller gescheiterten IT-Vorhaben stolpert nicht über den Code, sondern über unklare Anforderungen. Wo genau die teuersten Missverständnisse entstehen und wie ein einziges Dokument sie abfängt, klärt dieser Leitfaden.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Die meisten Projektpannen entstehen lange vor der ersten Zeile Code, und ein schwaches oder fehlendes Pflichtenheft steht oft am Anfang dieser Kette. Auftraggeber und Dienstleister benutzen dieselben Worte und meinen verschiedene Dinge. Ohne ein Dokument, das die Umsetzung verbindlich festhält, verlagert sich die Klärung in die teuerste Projektphase überhaupt.

Das Wichtigste in Kürze

Ein Pflichtenheft beschreibt, wie ein Auftragnehmer die Anforderungen aus dem Lastenheft technisch umsetzt.
Das Lastenheft kommt vom Auftraggeber und nennt das Ziel, die Spezifikation kommt vom Auftragnehmer und nennt den Weg.
Nach der Freigabe wird das Dokument zur verbindlichen Grundlage für Umsetzung und Abnahme.
Fast die Hälfte aller gescheiterten Projekte scheitert an unklaren Anforderungen, nicht an der Technik (PMI, 2014).

Was ist ein Pflichtenheft?

Offenes Buch „Pflichtenheft“ mit Miniatur-Baustelle: Kräne, Bagger, Bauarbeiter, Notiz — Das Pflichtenheft dokumentiert die technische Umsetzung der Anforderungen des Auftraggebers und dient nach Freigabe als verbindliche Abnahmegrundlage

Ein Pflichtenheft ist das Dokument, in dem der Auftragnehmer festhält, wie er die Anforderungen des Auftraggebers technisch umsetzt. Das Dokument übersetzt die Wünsche aus dem Lastenheft in konkrete, prüfbare Vorgaben und wird nach der Freigabe zur verbindlichen Abnahmegrundlage.

Der Begriff stammt aus dem klassischen Projektmanagement und ist in Deutschland über die Norm DIN 69901-5 definiert. Dort gilt die Spezifikation als die vom Auftragnehmer erarbeiteten Realisierungsvorgaben auf Basis des Lastenhefts. Kurz gesagt beschreibt das Lastenheft das Was, das Pflichtenheft das Wie.

Wer ein Haus bauen lässt, würde den Handwerkern nie nur zurufen, sie sollten mal drauflosbauen. Beim Software- oder Website-Projekt passiert fast genau das: Der Auftraggeber nennt ein grobes Ziel, und alles Weitere bleibt Auslegungssache. Das Dokument nimmt diese Auslegung aus dem Bauch heraus und schreibt sie fest, bevor der erste Handgriff geschieht.

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Zwei graue Ordner mit Fragezeichen, Pfeil und Schraubenschlüssel davor und darauf — Lastenheft und Pflichtenheft: Das eine fragt nach dem Ziel, das andere liefert den Weg.

Das Lastenheft kommt vom Auftraggeber und beschreibt, was er braucht. Das Pflichtenheft kommt vom Auftragnehmer und beschreibt, wie er die Anforderungen umsetzt. Das Lastenheft steht am Anfang und lässt die Lösung offen, die Spezifikation folgt darauf und legt jedes technische Detail fest.

Beide Dokumente gehören zusammen und bauen aufeinander auf. Das eine formuliert den Bedarf, das andere die Antwort darauf. Die folgende Übersicht stellt die wichtigsten Merkmale gegenüber.

Merkmal	Lastenheft	Pflichtenheft
Verfasser	Auftraggeber	Auftragnehmer
Kernfrage	Was soll entstehen?	Wie erfolgt die Umsetzung?
Zeitpunkt	vor der Ausschreibung	nach der Auftragsvergabe
Zielgruppe	Anbieter und Stakeholder	Entwicklungs- und Projektteams
Verbindlichkeit	Grundlage für Angebote	Grundlage für Umsetzung und Abnahme

In der Praxis entsteht das Lastenheft oft in enger Abstimmung mit dem späteren Dienstleister, der früh Rückfragen stellt. Wie ein solches Lastenheft für ein Website-Projekt Schritt für Schritt aussieht, zeigt unser Leitfaden zum Lastenheft für die Website.

Der Nutzen dieser Trennung zeigt sich schon bei der Ausschreibung. Weil das Lastenheft nur das Ziel beschreibt, kalkulieren mehrere Anbieter auf derselben Grundlage, und der Auftraggeber vergleicht Angebote, die wirklich vergleichbar sind. Erst der Zuschlag löst die Detailarbeit aus, aus der die Spezifikation des Auftragnehmers entsteht.

Lastenheft und Pflichtenheft im Vergleich

Zwei Dokumente, zwei Verfasser, eine Reihenfolge

Lastenheft

Das WAS und WOFÜR

Vom Auftraggeber verfasst
Beschreibt Ziele und Anforderungen
Lässt die technische Lösung offen
Grundlage für vergleichbare Angebote

Pflichtenheft

Das WIE und WOMIT

Vom Auftragnehmer verfasst
Beschreibt die technische Umsetzung
Legt Architektur, Schnittstellen, Tests fest
Wird zur verbindlichen Abnahmegrundlage

Von der Idee zur Abnahme: der Ablauf

Lastenheft

Der Auftraggeber formuliert, was das Ergebnis leisten soll.

Pflichtenheft

Der Auftragnehmer beschreibt, wie er die Anforderungen umsetzt.

Umsetzung

Das Team baut das Produkt entlang der festgelegten Vorgaben.

Abnahme

Die Spezifikation ist der Maßstab, an dem die Abnahme gemessen wird.

Was gehört in ein Pflichtenheft?

Abgerollte To-do-Liste von einem weißen Tisch mit der Zahl 8 oben — Acht Bausteine, jeder einzeln abgehakt: So wird aus einer Idee ein prüfbares Pflichtenheft.

Ein vollständiges Pflichtenheft deckt acht Bereiche ab: Ausgangslage und Ziele, funktionale Anforderungen, nicht-funktionale Anforderungen, Schnittstellen, Daten und Datenschutz, Abnahmekriterien, Termine und Budget sowie offene Punkte und Risiken. Jeder Bereich macht eine Anforderung nachprüfbar.

Die Reihenfolge folgt einer Logik: von der groben Ausgangslage über die einzelnen Anforderungen bis zu Terminen und Risiken. Die folgende Grafik zeigt alle acht Bausteine im Überblick.

Die acht Bausteine eines Pflichtenhefts

Was eine vollständige Spezifikation abdecken sollte

Ausgangslage und Ziele

Projekthintergrund, messbare Ziele, Abgrenzung zu anderen Systemen.

Funktionale Anforderungen

Was das Produkt können muss, konkret und einzeln prüfbar.

Nicht-funktionale Anforderungen

Tempo, Sicherheit, Bedienbarkeit, Barrierefreiheit, Skalierung.

Schnittstellen und Umgebung

Anbindung an bestehende Systeme, Hardware, Browser, Endgeräte.

Daten und Datenschutz

Datenmodell, Datenflüsse, Vorgaben aus der DSGVO.

Abnahmekriterien und Tests

Woran sich messen lässt, ob eine Anforderung erfüllt ist.

Termine und Meilensteine

Zeitplan, Abhängigkeiten, Budget- und Ressourcenrahmen.

Offene Punkte und Risiken

Bekannte Unsicherheiten, Annahmen und geplante Klärungen.

Den größten Unterschied macht die Trennung von funktionalen und nicht-funktionalen Anforderungen. Funktionale Anforderungen beschreiben, was das Produkt tun soll, etwa eine Bestellung abschließen. Nicht-funktionale Anforderungen legen fest, wie gut das Produkt das tut, also Ladezeit, Sicherheit und Bedienbarkeit.

Weil die Spezifikation den Leistungsumfang festschreibt, wird das Dokument zur belastbaren Grundlage für die Kalkulation. Was ein neues Website-Projekt am Ende tatsächlich kostet, hängt unmittelbar an diesem Umfang, nicht an einem Bauchgefühl.

In der Praxis hilft eine klare Priorisierung der Anforderungen, etwa nach dem MoSCoW-Schema in Muss, Soll, Kann und Nicht. So bleibt bei knappem Budget nachvollziehbar, welche Funktion zuerst wegfällt. Gerade die nicht-funktionalen Anforderungen geraten dabei leicht ins Hintertreffen, obwohl eine langsame oder unsichere Anwendung Nutzer schneller vertreibt als eine fehlende Zusatzfunktion.

Welche Normen definieren ein Pflichtenheft?

Drei graue Ordner zu DIN EN ISO 9001 im Regal, Band 2 mit Aufkleber — Veraltet gegen gültig: DIN 69905 ist längst durch DIN 69901-5 ersetzt.

In Deutschland definiert die Norm DIN 69901-5 das Pflichtenheft, ergänzt um die VDI-Richtlinie 2519 für das methodische Vorgehen. International gilt die Norm ISO/IEC/IEEE 29148 für das Anforderungsmanagement. Ältere Standards wie DIN 69905 und IEEE 830 sind zurückgezogen und nicht mehr maßgeblich.

DIN 69901-5 aus dem Jahr 2009 hat die frühere DIN 69905 abgelöst und liefert die bis heute gültigen Definitionen von Lasten- und Pflichtenheft. Ein Verweis auf DIN 69905 zitiert damit eine längst zurückgezogene Norm, die man in aktuellen Projekten getrost beiseitelegt.

International hat die ISO/IEC/IEEE 29148 in ihrer Fassung von 2018 den älteren Standard IEEE 830 aus dem Jahr 1998 ersetzt. Für die tägliche Projektarbeit zählt weniger die Normnummer als das Prinzip dahinter: Jede Anforderung wird eindeutig, vollständig und überprüfbar formuliert.

Die VDI-Richtlinie 2519 beschreibt zusätzlich, wie Lasten- und Pflichtenheft methodisch aufgebaut werden. Gerade in technischen Branchen wie dem Maschinen- und Anlagenbau ist diese Vorgehensweise fest etabliert.

Für die Praxis folgt daraus ein einfacher Grundsatz: Eine Vorlage aus dem Netz taugt als Gerüst, sollte aber gegen die aktuelle Normlage geprüft werden, bevor veraltete Begriffe und überholte Gliederungen in das eigene Dokument wandern.

Warum scheitern Projekte ohne gutes Pflichtenheft?

Umstürzender Bauklotzturm, beschriftet mit „Anforderungen“, daneben Schild „STABILITÄTSTEST“ auf weiß — Ein einziger fehlender Baustein bringt den Turm zu Fall: unklare Anforderungen sind die häufigste Scheiterursache.

Projekte scheitern selten an der Technik und meistens an unklaren Anforderungen. Fast die Hälfte aller gescheiterten Vorhaben führt das Project Management Institute auf mangelhaftes Anforderungsmanagement zurück, und große IT-Projekte liefern im Schnitt deutlich weniger Nutzen als geplant.

Die Zahlen sind eindeutig. Eine gemeinsame Untersuchung von McKinsey und der Universität Oxford aus dem Jahr 2012 wertete über 5.000 große IT-Projekte aus. Im Schnitt lagen diese 45 Prozent über dem Budget und lieferten 56 Prozent weniger Nutzen als versprochen.

Schon der bekannte CHAOS-Report der Standish Group von 1994 nannte unvollständige Anforderungen und die fehlende Einbindung der Nutzer als die beiden häufigsten Scheiterursachen. An dieser Rangfolge hat sich über Jahrzehnte erstaunlich wenig geändert.

Die unbequeme Wahrheit dahinter: Ein Pflichtenheft verhindert keine Probleme. Aber das Dokument holt diese Probleme an die Oberfläche, solange sie noch auf Papier stehen und ein paar Zeilen kosten, statt später Wochen an Nacharbeit.

Besonders teuer wird der schleichende Zuwachs an Anforderungen, im Fachjargon Scope Creep. Jede kleine Zusatzbitte klingt für sich harmlos, in Summe sprengen diese Wünsche aber Budget und Zeitplan. Ein freigegebenes Dokument bremst diesen Effekt, weil jede Abweichung gegen eine vereinbarte Grundlage läuft und nicht gegen eine vage Erinnerung.

Fast die Hälfte aller gescheiterten Projekte scheitert an unklaren Anforderungen, nicht an schlechter Technik. Ein sauberes Pflichtenheft ist die billigste Versicherung gegen dieses Risiko, und trotzdem sparen sich viele Teams genau diesen Schritt.
— Markus Seyfferth, Chefredakteur Dr. Web

Ist das Pflichtenheft rechtlich bindend?

Dokument mit Richterhammer, Anhänger — Freigegeben und gesiegelt: Das Pflichtenheft wird zur bindenden Vertragsgrundlage.

Sobald der Auftraggeber das Pflichtenheft freigibt, wird das Dokument in der Regel Vertragsbestandteil und damit rechtlich bindend. Bei individueller Software gilt meist Werkvertragsrecht nach § 631 BGB, und die Spezifikation beschreibt die geschuldete Beschaffenheit, an der die Abnahme gemessen wird.

Individuelle Softwareentwicklung ordnet die Rechtsprechung überwiegend als Werkvertrag ein. Geschuldet ist damit ein Ergebnis, nicht bloße Mühe. Das Dokument definiert dieses Ergebnis und wird so zum Maßstab für Mängel und Gewährleistung.

Vor der Abnahme lohnt ein systematischer Abgleich mit jedem einzelnen Punkt der Spezifikation. Für den Start einer Website haben wir diesen Abgleich als Checkliste vor dem Go-live zusammengestellt.

Ob im Einzelfall Werkvertrag oder Dienstvertrag vorliegt, hängt von der konkreten Ausgestaltung ab und ist juristisch umstritten. Klar ist jedoch: Ein freigegebenes Pflichtenheft schafft für beide Seiten eine belastbare Grundlage, auf die sich im Streitfall jeder berufen kann.

In größeren Vorhaben wird oft in Teilabnahmen gearbeitet, damit am Ende nicht das gesamte Werk auf einmal auf dem Prüfstand steht. Jede Teilabnahme misst sich an dem Abschnitt der Spezifikation, der zu diesem Zeitpunkt fertig sein sollte. So lassen sich Mängel früh erkennen, bevor sie sich durch das ganze Projekt ziehen.

Braucht man im agilen Projekt noch ein Pflichtenheft?

Arbeitsplatz mit Ordner, Wegweiser und Pinnwand — Vom festen Dokument zum lebenden Backlog: Die Anforderungsarbeit wandert, verschwindet aber nicht.

In agilen Projekten ersetzt das Team das klassische Pflichtenheft meist durch einen Product Backlog aus User Stories. Die Anforderungsarbeit verschwindet dabei nicht, sie verlagert sich vom Vorab-Dokument in einen laufend gepflegten Prozess. In regulierten oder fest budgetierten Projekten bleibt das klassische Dokument dagegen Standard.

Das Pflichtenheft ist im agilen Umfeld also nicht tot, wie oft behauptet wird. Scrum kennt zwar kein solches Vorabdokument, dafür beschreiben User Stories jede Anforderung aus Sicht der Nutzer, ergänzt um klare Akzeptanzkriterien.

Zwischen beiden Welten existieren Mischformen. Manche Teams nutzen ein schlankes Lastenheft für die Ausschreibung und führen die Detailanforderungen anschließend im Backlog weiter. Entscheidend bleibt, dass jemand die Anforderungen sauber festhält, ob auf 40 Seiten oder in 200 Backlog-Einträgen.

Der Backlog kann dabei sogar zur Vertragsanlage werden. Manche Verträge verweisen auf den priorisierten Backlog zum Projektstart und regeln, wie neue Einträge bewertet und eingeplant werden. Die Anforderungsarbeit bleibt damit genauso verbindlich wie im klassischen Modell, nur ihr Rhythmus ist ein anderer.

Wie erstellen Sie ein Pflichtenheft Schritt für Schritt?

Betonstufen 1-5, Dokumentation mit Stempel und Schnecke darauf, weißer Hintergrund — In fünf Schritten zum fertigen Pflichtenheft, das alle Beteiligten unterschreiben können.

Ein Pflichtenheft entsteht in fünf Schritten: Lastenheft auswerten, Anforderungen strukturieren, technische Lösung beschreiben, Abnahmekriterien festlegen und das Dokument gemeinsam freigeben. Am Ende steht eine Fassung, die alle Beteiligten unterschreiben können.

Lastenheft auswerten: Ziele, Rahmenbedingungen und offene Fragen des Auftraggebers sichten und alle Rückfragen klären.
Anforderungen strukturieren: Funktionale und nicht-funktionale Anforderungen trennen und jede einzeln nummerieren.
Technische Lösung beschreiben: Architektur, Schnittstellen, Datenmodell und eingesetzte Technologien festlegen.
Abnahmekriterien festlegen: Für jede Anforderung definieren, woran sich die Erfüllung messbar zeigt.
Gemeinsam freigeben: Das Dokument mit dem Auftraggeber durchgehen, anpassen und verbindlich freigeben.

Ein Praxistipp aus vielen Projekten: Formulieren Sie jede Anforderung testbar. Statt „Die Seite soll schnell laden“ gehört der Satz „Die Startseite lädt in unter zwei Sekunden“ in das Dokument. Aus einer Meinung wird so ein messbares Kriterium, über das später niemand mehr streiten muss.

Ein gutes Pflichtenheft kostet zu Beginn Zeit, die niemand gern investiert. Genau diese Zeit ist aber der günstigste Moment im ganzen Projekt, um Missverständnisse auszuräumen. Später wird jede Korrektur teurer, und die Rechnung dafür zahlt am Ende immer der Auftraggeber.

Glossar: 12 wichtige Fachbegriffe zum Pflichtenheft

Aufgeschlagenes Buch mit orangefarbenem Lesezeichen und Metallsuchleiste darauf — Zwölf Fachbegriffe rund um das Pflichtenheft, kompakt nachgeschlagen.

Abnahme

Abnahme bezeichnet die formale Bestätigung des Auftraggebers, dass das gelieferte Produkt die vereinbarten Anforderungen erfüllt. Im Werkvertragsrecht löst die Abnahme wichtige Rechtsfolgen aus, etwa den Beginn der Gewährleistung. Als Maßstab dient das freigegebene Dokument.

Agile Entwicklung

Agile Entwicklung ist ein iteratives Vorgehen, bei dem ein Produkt in kurzen Zyklen wächst, statt vorab komplett spezifiziert zu werden. Bekanntester Vertreter ist Scrum. Anforderungen entstehen hier laufend im Product Backlog statt in einem einmaligen Vorabdokument.

Funktionale Anforderung

Funktionale Anforderung beschreibt eine konkrete Fähigkeit, die ein Produkt besitzen muss, etwa das Versenden einer Bestellbestätigung. Funktionale Anforderungen beantworten die Frage, was das System tun soll, und bilden den Kern jeder Spezifikation.