Pflichtenheft: Vorlage, Beispiel & Anleitung

Das Pflichtenheft (Gesamtsystementwurf) ist ein zentrales Dokument der klassischen Projektdokumentation und das Gegenstück zum Lastenheft (Anforderungen) auf Auftragnehmerseite. Ein Pflichtenheft erstellen ist in der Regel Aufgabe des Auftragnehmers (AN) in Zusammenarbeit mit dem Auftraggeber (AG) und findet in der Projektmanagment-Phase “Planung” statt. Das Pflichtenheft ist das zentrale Ausgangsdokument für die Systemerstellung. Zum schnellen Einstieg gibt es eine Pflichtenheft-Vorlage.

Pflichtenheft-Struktur

Eine bewährte, konkrete Struktur für ein Pflichtenheft sieht in Anlehnung an das V-Modell XT so aus. Die Tabelle zeigt vorab, was in welchen Abschnitt gehört und woher der Inhalt stammt — die meiste Arbeit beim Pflichtenheft besteht darin, vorhandene Information richtig einzuordnen, nicht darin, sie neu zu erfinden.

#	Abschnitt	Was hineingehört	Woher der Inhalt kommt
1	Einleitung	Zweck des Dokuments, beteiligte Rollen, Verweis auf das Lastenheft	Projektauftrag
2	Ausgangssituation und Zielsetzung	Anlass, Defizite der heutigen Lösung, Stakeholder, Rahmenbedingungen	Lastenheft, Projekthandbuch
3	Dekomposition des Gesamtsystems	Systeme, Segmente, Logistikelemente, zu erstellende Architekturdokumente	Lastenheft, Grobarchitektur
4	Schnittstellenübersicht	Schnittstellen zu Anwendern, Nachbarsystemen und Logistik	Systemumfeld
5	Lebenszyklusanalyse	zu unterstützende Phasen, Bedarf an Unterstützungskonzepten	Anforderungen aus Abschnitt 6/7
6	Funktionale Anforderungen	Anwendungsfälle, fachliches Datenmodell	Lastenheft, konkretisiert
7	Nicht-funktionale Anforderungen	Konkretisierung und geplante Umsetzung; Sicherheit, Datenschutz, Betrieb	Lastenheft, konkretisiert
8	Anforderungsverfolgung zum Lastenheft	Zuordnung jeder Lastenheft-Anforderung zu einer Pflichtenheft-Anforderung	Abschnitte 6 und 7
9	Anforderungsverfolgung zu den Spezifikationen	Zuordnung jeder Anforderung zu einem Element der Architektur	Abschnitt 3
10	Abnahmekriterien und Ausgangsprüfung	Bedingungen der Abnahme, daraus abgeleitete Prüffälle	Lastenheft
11	Lieferumfang	Systeme, Dokumente und Dienstleistungen, die geliefert werden	Vertrag, Lastenheft

Die Abschnitte 8 und 9 werden in der Praxis am häufigsten weggelassen — und verursachen genau dann die Diskussionen bei der Abnahme, weil niemand mehr belegen kann, welche Forderung des Auftraggebers wo gelandet ist.

1. Einleitung

Wesentliche Inhalte des Pflichtenheftes sind die funktionalen und nicht-funktionalen Anforderungen an das zu entwickelnde Gesamtsystem. Die Anforderungen werden aus dem Lastenheft übernommen und geeignet aufbereitet. Eine erste Grobarchitektur des Systems wird entwickelt und in einer Schnittstellenübersicht beschrieben. Das zu entwickelnde System sowie weitere ggf. zu entwickelnde Systeme werden identifiziert und den Anforderungen zugeordnet. Zusätzliche Anforderungen an die Logistik werden in Zusammenarbeit mit dem Logistikverantwortlichen erarbeitet. Abnahmekriterien und Lieferumfang für das fertige Gesamtsystem werden aus dem Lastenheft (Anforderungen) übernommen und konkretisiert. Um sicher zu stellen, dass alle Anforderungen berücksichtigt sind, wird eine Anforderungsverfolgung, sowohl hin zum Lastenheft als auch zu den Systemen, durchgeführt.

Zur Erstellung des Gesamtsystementwurfs sind Kenntnisse aus unterschiedlichen Disziplinen wie Systementwicklung, Sicherheit, Ergonomie und Logistik notwendig, die üblicherweise nicht von einer Person abgedeckt werden können. Da Anforderungen den Kern der Spezifikation darstellen, fällt dem Anforderungsanalytiker (AN) die verantwortliche Rolle für die Erstellung des Gesamtsystementwurfs zu. Für die inhaltliche Ausarbeitung benötigt er jedoch intensive Unterstützung durch Experten der verschiedenen Disziplinen.

Zu jedem im Gesamtsystementwurf identifizierten System und Segment werden die entsprechenden Produkte wie Spezifikation und Architektur erstellt. Anforderungen an die Logistik werden in der Spezifikation logistische Unterstützung weiter verfolgt.

2. Ausgangssituation und Zielsetzung

In diesem Abschnitt werden die Ausgangssituation und der Anlass zur Durchführung des Projektes anschaulich dargestellt. Es wird beschrieben, welche Defizite bzw. Probleme existierender Systeme oder auch der aktuellen Situation zur Entscheidung geführt haben, das Projekt durchzuführen, und welche Vorteile durch den Einsatz des neuen Systems erwartet werden.

Es werden zusätzlich alle relevanten Stakeholder des Projektes benannt und die technische und fachliche Einbettung des zu entwickelnden Systems in seine Umgebung skizziert. Zusätzlich werden erste Rahmenbedingungen für die Entwicklung identifiziert und beschrieben. Rahmenbedingungen können beispielsweise eine erste grobe Projektplanung, ein Projekthandbuch mit Festlegungen zur Vorgehensweise, technische Vorgaben oder Vorgaben zur Sicherheit sein.

3. Dekomposition des Gesamtsystems

In der Dekomposition des Gesamtsystems wird das zentrale System mit allen ggf. zusätzlich benötigten Systemen identifiziert und festgelegt, welche Logistikelemente erstellt werden. Zudem werden die zu erstellenden Architekturdokumente und Implementierungs-, Integrations- und Prüfkonzepte benannt. Grundlage sind die funktionalen und nicht-funktionalen Anforderungen sowie die Skizze der Gesamtsystemarchitektur aus dem Lastenheft. Zur Einordnung in die Projektstruktur unterstützt ein Projektstrukturplan. Beistellungen des Auftraggebers werden berücksichtigt.

Die Gesamtsystemarchitektur wird hinsichtlich der möglichen Verwendung von Fertigprodukten geprüft. Gegebenenfalls wird deshalb bereits auf Basis des Pflichtenhefts eine Marktsichtung für Fertigprodukte durchgeführt, um den Einfluss möglicher Kandidaten auf die Anforderungen und die Systemarchitektur abschätzen zu können.

4. Schnittstellenübersicht

Zur Darstellung der Zusammenhänge zwischen dem System und seiner Umgebung wird eine Schnittstellenübersicht erstellt. Ausgehend vom System werden Schnittstellen zum Anwender, zu anderen im Projekt zu entwickelnden Systemen, zur Logistik und zu Nachbarsystemen identifiziert und in geeigneter Form dokumentiert.

Die konkrete Beschreibung der Schnittstellen erfolgt in den Spezifikationen der Systemelemente sowie in der “Spezifikation logistische Unterstützung”.

5. Lebenszyklusanalyse

Ausgehend von den Anforderungen werden die zu unterstützenden Phasen im Lebenszyklus (Entwicklung, Wartung und Stilllegung) bestimmt. Es wird festgelegt, für welche der im Abschnitt “Dekomposition des Gesamtsystems” identifizierten Systeme ein “Logistisches Unterstützungskonzept” zu erstellen ist.

6. Funktionale Anforderungen

Funktionale Anforderungen beschreiben die Fähigkeiten eines Systems, die ein Anwender erwartet, um mit Hilfe des Systems ein fachliches Problem zu lösen. Die Anforderungen werden aus den zu unterstützenden Geschäftsprozessen und den Ablaufbeschreibungen zur Nutzung des Systems abgeleitet.

Die Beschreibung der funktionalen Anforderungen erfolgt beispielsweise in Form von Anwendungsfällen (Use Cases). Ein Anwendungsfall beschreibt dabei einen konkreten, fachlich in sich geschlossenen Teilvorgang. Die Gesamtheit der Anwendungsfälle definiert das Systemverhalten. Ein Anwendungsfall kann in einfachem Textformat beschrieben werden, häufig stehen jedoch organisationsspezifische Muster zur Beschreibung zur Verfügung. Für datenzentrierte Systeme ist im Rahmen der funktionalen Anforderungen ein erstes fachliches Datenmodell zu bearbeiten, das als Grundlage des späteren Datenbankentwurfs dient. Das fachliche Datenmodell des Systems wird aus den Entitäten des Domänenmodells abgeleitet.

Die funktionalen Anforderungen sind die zentralen Vorgaben für die Systementwicklung. Sie werden in das Pflichtenheft (Gesamtsystementwurf) übernommen und bei Bedarf konkretisiert.

7. Nicht-funktionale Anforderungen

In diesem Thema werden die im Lastenheft beschriebenen nicht-funktionalen Anforderungen aufgeführt, ggf. konkretisiert und deren Umsetzung erläutert.

Sofern das Lastenheft Vorgaben zur Informationssicherheit, zum Datenschutz oder zum IT-Betrieb enthält, ist basierend auf diesen Vorgaben, den übrigen Anforderungen, der “Dekomposition des Gesamtsystems” und der “Schnittstellenübersicht” festzulegen,

• ob bereits auf der Ebene des Gesamtsystems eine Sicherheitskonzeption zu entwickeln ist, um Bedrohungen und Maßnahmen dokumentieren zu können.
• ob diese Vorgaben geändert oder erweitert werden müssen. Beabsichtigte Änderungen und Erweiterungen müssen mit dem Auftraggeber abgestimmt werden und führen ggf. zu einer Vertragsanpassung.

8. Anforderungsverfolgung zum Lastenheft

Im Rahmen der Anforderungsverfolgung zum Lastenheft wird zusammenfassend die Zuordnung der funktionalen und nicht-funktionalen Anforderungen aus dem Lastenheft zu den Anforderungen im Pflichtenheft dargestellt. Besonders bei Software in sicherheitskritischen Systemen muss die bidirektionale Verfolgbarkeit sichergestellt werden. In der Praxis benötigt man dazu Unterstützung durch eine Projektmanagement-Software wie Allegra, die die Erstellung von Dokumenten und Verknüpfung von Themen erlaubt. In einfachen Fällen kann die Darstellung anhand einer Matrix erfolgen.

9. Anforderungsverfolgung zu den Spezifikationen

Im Rahmen der Anforderungsverfolgung wird im Pflichtenheft zusammenfassend die Zuordnung der funktionalen und nicht-funktionalen Anforderungen zu den Elementen der Gesamtsystemarchitektur (System, Segment oder Logistik) dargestellt. Besonders bei Software in sicherheitskritischen Systemen muss die bidirektionale Verfolgbarkeit sichergestellt werden. Die Darstellung kann beispielsweise anhand einer Matrix erfolgen.

10. Abnahmekriterien und Vorgehen zur Ausgangsprüfung

Abnahmekriterien definieren die Bedingungen, die eine den Anforderungen entsprechende Lieferung erfüllen muss. Wie SMART-Ziele sollten sie messbar und strukturiert sein. Abnahmekriterien können sich sowohl auf einzelne Anforderungen (“Unter welchen Bedingungen gilt die Anforderung als erfüllt?”) als auch auf den Lieferumfang (“Welche Bedingungen müssen erfüllt sein, damit eine konkrete Lieferung abgenommen wird?”) beziehen. Die Definition der Abnahmekriterien ist in der Regel Aufgabe des Auftraggebers; der Auftragnehmer sollte sie aber kennen und in seinem Pflichtenheft auch benennen, um Klarheit darüber zu besitzen, unter welchen Bedingungen das System abgenommen wird. In manchen Fällen kann es sinnvoll sein, wenn der Auftragnehmer oder Auftragnehmer und Auftraggeber die Abnahmekriterien gemeinsam definieren.

Der Auftragnehmer sollte vor der Auslieferung möglichst sicher sein, dass die Lieferung auch abgenommen wird und deswegen eine geeignete Ausgangsprüfung durchführen. Die zu liefernden Systemelemente werden anhand einer »Prüfspezifikation Systemelement, die zu liefernden Dokumente (insbesondere die “Logistische Unterstützungsdokumentation”) anhand einer “Prüfspezifikation” geprüft. Die dazu notwendigen Prüffälle werden aus den Abnahmekriterien abgeleitet, können aber in der Regel nicht vollständig identisch mit den Prüffällen des Auftraggebers sein, da der Auftragnehmer z.B. keinen Zugang zur Zielplattform hat oder die tatsächlichen Anwender nicht einbinden kann.

11. Lieferumfang

Es sind alle Gegenstände (dazu gehören auch Software und Dokumente) und Dienstleistungen aufzulisten, die im Projektverlauf oder zum Abschluss des Projektes zu liefern sind. Jede Lieferung erfordert eine Abnahmeprüfung. Der Lieferumfang kann je nach Vereinbarung ein System, Teile eines Systems, Dokumente und Dienstleistungen enthalten.

Glossar

Technische Dokumente beinhalten oft Begriffe, die nicht für alle Nutzer dieser Dokumente gleich verständlich sind. Es ist deshalb nützlich, ein Glossar anzulegen, in dem diese Begriffe geklärt werden. Verwendet man ein einfaches ALM-System wie Allegra, kann ein Glossar zentral erstellt und gepflegt werden.

Pflichtenheft-Beispiel

Die Abschnittsbeschreibungen oben sagen, was hineingehört. Dieses Beispiel zeigt, wie es dann aussieht. Es setzt bewusst genau dort an, wo das Lastenheft-Beispiel endet: Derselbe Auftraggeber, dieselben Anforderungen — diesmal aus Sicht des Auftragnehmers.

Ausgangssituation. Ein Maschinenbauunternehmen mit 350 Mitarbeitern erfasst Instandhaltungsaufträge auf Papier und hat dafür ein Lastenheft ausgeschrieben. Der Auftragnehmer hat den Zuschlag erhalten und beschreibt nun, wie er die Anforderungen umsetzt.

Lösungsentscheidung im Pflichtenheft. „Die Instandhaltungsaufträge werden in einem webbasierten System abgebildet, das über den Browser des Tablets ohne eigene App bedient wird. Die Anlagenstammdaten werden nächtlich aus dem ERP-System repliziert. Der Betrieb erfolgt in einem Rechenzentrum in Frankfurt am Main.” — Genau hier unterscheidet sich das Pflichtenheft vom Lastenheft: Es nennt Produkt, Technologie und Betriebsmodell. Das Lastenheft durfte das nicht.

Anforderungen mit Umsetzung und Prüfvorschrift. Jede Zeile trägt eine eigene Kennung, den Bezug zur Forderung des Auftraggebers und eine Prüfvorschrift, mit der die Ausgangsprüfung später arbeitet:

ID	Lastenheft	Umsetzung im Gesamtsystementwurf	Prüfvorschrift
PF-101	FA-011	Responsive Weboberfläche „Auftrag anlegen” mit Pflichtfeldern Anlage, Fehlerbild, Datum; Anlagenauswahl über Scan des QR-Codes an der Anlage.	Auftrag auf Tablet (10”, Chrome) anlegen, danach am Arbeitsplatzrechner vollständig sichtbar.
PF-104	FA-014	Statuswechsel auf „abgeschlossen” löst eine Regel im Workflow aus, die den im Anlagenstamm hinterlegten Verantwortlichen per E-Mail benachrichtigt.	Statuswechsel auslösen; Zustellung im Postfach des Verantwortlichen innerhalb von 5 Minuten.
PF-108	FA-021	Auswertung „Aufträge je Anlage” mit frei wählbarem Zeitraum, Export nach CSV und XLSX.	Auswertung für ein Quartal erzeugen; Summe stimmt mit der Anzahl der Einzelaufträge überein.
PF-112	FA-032	Foto-Upload je Auftrag, maximal 10 Dateien à 10 MB, Anzeige als Vorschau in der Auftragsansicht.	Zwei Fotos anhängen, nach dem Speichern in der Auftragsansicht abrufbar.
PF-201	NF-004	Zwei Anwendungsserver hinter einem Load Balancer, Datenbank mit Read-Replica für Auswertungen.	Lasttest mit 40 parallelen Sitzungen; 95 % der Seitenaufrufe unter 2 Sekunden.
PF-205	NF-009	Betrieb ausschließlich im Rechenzentrum Frankfurt am Main; Backups verbleiben im selben Rechenzentrum.	Schriftlicher Nachweis der Standorte aller verarbeitenden Systeme inklusive Backup.
PF-301	SS-002	Nächtlicher Import der Anlagenstammdaten aus dem ERP-System über eine CSV-Schnittstelle.	Import einer Beispieldatei mit 50 Anlagen ohne manuelle Nacharbeit.

Anforderungsverfolgung. Abschnitt 8 verlangt den Nachweis, dass jede Forderung des Auftraggebers angekommen ist. Im Beispiel ist das eine Tabelle mit drei Spalten — und ihr Wert liegt in der letzten Zeile:

Lastenheft	Pflichtenheft	Status
FA-011, FA-014, FA-021, FA-032	PF-101, PF-104, PF-108, PF-112	vollständig übernommen
NF-004, NF-009	PF-201, PF-205	vollständig übernommen
SS-002 (KANN)	PF-301	übernommen, Umsetzung im zweiten Release

Eine als KANN gekennzeichnete Anforderung darf verschoben werden — aber nur, wenn das im Pflichtenheft steht. Wird sie stillschweigend weggelassen, fällt sie bei der Abnahme auf und wird dann teuer.

Was das Pflichtenheft anders macht als das Lastenheft

• Es nennt die Lösung. Das Lastenheft beschreibt das Problem und hält Technologie bewusst offen; das Pflichtenheft legt sich fest und wird damit zur Grundlage der Aufwandsschätzung.
• Jede Anforderung bekommt eine Prüfvorschrift, nicht nur ein Abnahmekriterium. Das Abnahmekriterium sagt, wann der Auftraggeber zufrieden ist; die Prüfvorschrift sagt, wie der Auftragnehmer das vor der Auslieferung selbst feststellt.
• Die Nummerierung ist eine eigene. PF-101 und FA-011 gehören zusammen, sind aber nicht dasselbe — eine Lastenheft-Anforderung kann auf mehrere Pflichtenheft-Anforderungen führen und umgekehrt.
• Das Weglassen muss dokumentiert werden. Alles, was nicht oder später umgesetzt wird, gehört sichtbar in die Anforderungsverfolgung, nicht in ein Gespräch.

Zusammen mit dem Lastenheft bildet das Pflichtenheft die Grundlage für den Projekt-Scope. Ein Projektablaufplan hilft, die im Pflichtenheft definierten Ergebnisse zeitlich einzuordnen.

Ein Pflichtenheft erstellen geht schneller mit einer Pflichtenheft-Dokumentvorlage. Die Vorlagen gibt es im Microsoft Word-Format sowie für Allegra Project.

Pflichtenheft ohne Word erstellen

Ein Pflichtenheft als Word-Datei ist schnell begonnen und wird spätestens beim dritten Änderungsstand unangenehm. Der Grund steht in den Abschnitten 8 und 9 der Struktur: Die Anforderungsverfolgung verknüpft ein Dokument mit einem zweiten Dokument und beide mit der späteren Spezifikation. Sobald sich im Lastenheft eine Nummer ändert, muss jemand alle Verweise von Hand nachziehen. Das ist der Punkt, an dem Pflichtenhefte veralten.

Die Alternative ist, die Anforderungen nicht als Text in einer Datei zu führen, sondern als einzeln adressierbare Objekte in einem System — jede Anforderung ein Datensatz mit Kennung, Priorität, Status, Verantwortlichem und Verknüpfung zur Quelle. Das Dokument entsteht daraus per Export, wenn es gebraucht wird.

	Pflichtenheft als Word-Datei	Anforderungen im System
Anforderungsverfolgung	manuell gepflegte Tabelle	Verknüpfung, jederzeit auswertbar
Paralleles Arbeiten	eine Person zur Zeit, danach Zusammenführen	mehrere Personen gleichzeitig
Änderungshistorie	Dokumentversionen	je Anforderung nachvollziehbar
Status einzelner Anforderungen	nicht abbildbar	Feld am Datensatz
Abgabe an den Auftraggeber	die Datei selbst	Export als PDF oder Word
Aufwand zu Beginn	sehr gering	Struktur muss einmal angelegt werden

Die Entscheidungsregel ist die Zahl der Anforderungen und die Laufzeit. Unter etwa 50 Anforderungen und bei einem Projekt, das in wenigen Monaten abgenommen wird, ist die Word-Datei die richtige Wahl — der Einrichtungsaufwand rechnet sich nicht. Darüber, oder sobald das System nach der Abnahme gepflegt und erweitert wird, lohnt sich das System: Dann wird aus dem Pflichtenheft kein abgelegtes Dokument, sondern die Grundlage für Änderungsanträge und Releases.

Für den zweiten Fall bildet Allegra Anforderungen als verknüpfbare Vorgänge ab, aus denen sich das Pflichtenheft als Dokument erzeugen lässt. Wer zunächst bei der Datei bleiben möchte, findet die Word-Vorlage oben am Anfang dieser Seite.

Häufig gestellte Fragen

Was ist ein Pflichtenheft?

Ein Pflichtenheft ist ein technisches Dokument, das beschreibt, wie die Anforderungen aus dem Lastenheft umgesetzt werden. Es enthält detaillierte Spezifikationen, Lösungsansätze und technische Rahmenbedingungen für die Projektumsetzung.

Wer erstellt das Pflichtenheft?

Das Pflichtenheft wird in der Regel vom Auftragnehmer oder dem Entwicklerteam erstellt. Es dient als verbindliche Grundlage für die technische Umsetzung der Anforderungen des Auftraggebers.

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Das Lastenheft beschreibt die Anforderungen des Auftraggebers an ein Produkt oder System (Was soll erreicht werden?). Das Pflichtenheft definiert die technische Umsetzung dieser Anforderungen durch den Auftragnehmer (Wie wird es umgesetzt?).

Welche Inhalte sollte ein Pflichtenheft enthalten?

Ein Pflichtenheft sollte eine detaillierte Beschreibung der technischen Umsetzung enthalten, inklusive Systemarchitektur, Schnittstellen, Funktionen, Leistungsanforderungen, Testkriterien und Abnahmekriterien.

Wie schreibt man ein Pflichtenheft?

In vier Schritten: die Anforderungen aus dem Lastenheft übernehmen und dabei durchnummerieren, zu jeder Anforderung die geplante Umsetzung und eine Prüfvorschrift ergänzen, die Zuordnung zwischen beiden Dokumenten in der Anforderungsverfolgung festhalten und zuletzt Lieferumfang und Abnahmekriterien konkretisieren. Der häufigste Fehler ist, mit der Einleitung zu beginnen — sie lässt sich am Ende in zehn Minuten schreiben, wenn alles andere steht.

Was gehört in ein Pflichtenheft für ein IT-Projekt?

Zusätzlich zu den elf Abschnitten oben drei Dinge, die in IT-Projekten regelmäßig fehlen: die Schnittstellen zu den Nachbarsystemen mit der Angabe, wer die Altdaten aufbereitet; Rollen und Berechtigungen als fachliche Festlegung, nicht als technisches Detail; und das Betriebsmodell mit Wartungsfenstern und Reaktionszeiten. Diese drei Punkte entscheiden über den Aufwand und lassen sich nachträglich kaum noch verhandeln.

Ist ein Pflichtenheft verpflichtend?

Das Pflichtenheft ist nicht immer gesetzlich vorgeschrieben, aber es dient als verbindliche Grundlage zwischen Auftraggeber und Auftragnehmer. Es hilft, Missverständnisse zu vermeiden und technische Anforderungen klar zu definieren.