Ein Pflichtenheft beschreibt, wie der Auftragnehmer die Anforderungen aus dem Lastenheft des Auftraggebers umsetzt: Funktionen, Daten, Schnittstellen, Qualitätsmerkmale, technische Umgebung und Abnahmekriterien. Der Auftragnehmer schreibt es, der Auftraggeber prüft es und gibt es frei. Danach ist es die verbindliche Grundlage für Angebot, Entwicklung, Test und Abnahme.
Das Wichtigste in Kürze
- Das Lastenheft sagt, was gebraucht wird und wofür. Das Pflichtenheft sagt, wie und womit es umgesetzt wird.
- Geschrieben wird es vom Auftragnehmer, also vom Entwicklungsteam. Gültig wird es erst mit der Freigabe durch den Auftraggeber.
- Jede Anforderung braucht eine Kennung und ein prüfbares Abnahmekriterium. Was sich nicht testen lässt, lässt sich auch nicht abnehmen.
- Nichtfunktionale Anforderungen, Schnittstellen und die technische Umgebung entscheiden über Aufwand und Architektur. Sie fehlen in der Praxis am häufigsten.
- Auch agile Projekte kommen nicht ohne Spezifikation aus. Sie wird nur schlanker und entsteht schrittweise.
Was ist ein Pflichtenheft?
Ein Pflichtenheft ist die Antwort des Auftragnehmers auf das Lastenheft. Die DIN 69901-5 definiert es als die „vom Auftragnehmer erarbeiteten Realisierungsvorgaben aufgrund der Umsetzung des vom Auftraggeber vorgegebenen Lastenhefts“ (zitiert nach Wikipedia). Das Dokument übersetzt fachliche Wünsche in eine technische Lösung, die sich planen, kalkulieren und testen lässt.
Im V-Modell XT Bund, dem Vorgehensmodell der Bundesverwaltung für IT-Projekte, heißt das Lastenheft „Anforderungen (Lastenheft)“ und das Pflichtenheft „Gesamtsystemspezifikation (Pflichtenheft)“. Diese Bezeichnung trifft den Kern: Das Pflichtenheft spezifiziert das Gesamtsystem so genau, dass ein Team es danach bauen kann.
Aus Sicht eines Entwicklungsteams erfüllt das Dokument drei Aufgaben:
- Es zeigt dem Auftraggeber, wie seine Anforderungen verstanden wurden, bevor Code entsteht.
- Es ist die Grundlage für Aufwandsschätzung, Architektur und Projektplan.
- Es legt fest, woran bei der Abnahme gemessen wird, ob die Software fertig ist.
Was gehört in ein Pflichtenheft?
Für Softwareprojekte hat sich im deutschsprachigen Raum eine Gliederung durchgesetzt, die sich an den Fragen Ziel, Einsatz, Funktion, Daten, Qualität und Umgebung orientiert. Eine verbindliche Norm für den Aufbau gibt es nicht. Passen Sie die Kapitel an Ihr Projekt an, lassen Sie aber keines stillschweigend weg.
| Kapitel | Inhalt | Leitfrage |
|---|---|---|
| Zielbestimmung | Musskriterien, Wunschkriterien, Abgrenzungskriterien | Was muss das System können, was wäre gut und was gehört ausdrücklich nicht dazu? |
| Produkteinsatz | Anwendungsbereiche, Zielgruppen, Betriebsbedingungen | Wer nutzt das System, wo und unter welchen Bedingungen? |
| Produktübersicht | Systemkontext, Hauptanwendungsfälle, Architekturskizze | Wie sieht das System im Überblick aus? |
| Produktfunktionen | Funktionale Anforderungen mit Kennung, Ablauf und Fehlerfällen | Was tut das System in welcher Situation? |
| Produktdaten | Datenobjekte, Attribute, Mengengerüst, Aufbewahrung | Welche Daten werden gespeichert und wie lange? |
| Produktleistungen | Nichtfunktionale Anforderungen: Antwortzeiten, Verfügbarkeit, Sicherheit, Datenschutz | Wie gut muss das System seine Aufgaben erfüllen? |
| Benutzungsoberfläche | Dialogstruktur, Wireframes, Barrierefreiheit, Sprachen | Wie bedienen Nutzer das System? |
| Schnittstellen | Angebundene Systeme, Protokolle, Datenformate, Verantwortliche | Mit welchen Systemen tauscht das System Daten aus? |
| Technische Produktumgebung | Software, Hardware, Hosting, Browser und Geräte | Worauf läuft das System? |
| Entwicklungsumgebung | Programmiersprachen, Frameworks, Repository, CI/CD | Womit wird entwickelt und ausgeliefert? |
| Testfälle und Abnahmekriterien | Testszenarien je Anforderung, Abnahmeverfahren | Woran wird die Erfüllung gemessen? |
| Anhang | Glossar, Datenmodell, offene Punkte | Welche Begriffe und Details braucht der Leser zusätzlich? |
Produktfunktionen: eine Anforderung, eine Kennung
Jede funktionale Anforderung erhält eine eindeutige Kennung, zum Beispiel /F10/, /F20/, /F30/. Die Zehnerschritte lassen Platz für spätere Ergänzungen. Über die Kennung lässt sich jede Anforderung bis ins Lastenheft zurückverfolgen und später einem Testfall, einem Ticket und einer Code-Änderung zuordnen. Beschreiben Sie zu jeder Funktion den Auslöser, den Normalablauf, die Fehlerfälle und das Ergebnis.
Produktleistungen: nichtfunktionale Anforderungen
Nichtfunktionale Anforderungen bestimmen die Architektur stärker als die meisten Funktionen. Ob ein System fünfzig oder fünfzigtausend gleichzeitige Nutzer bedienen muss, entscheidet über Datenbank, Caching und Hosting. Eine gute Checkliste liefern die Qualitätsmerkmale der Normenreihe ISO/IEC 25000: unter anderem Leistungseffizienz, Zuverlässigkeit, Sicherheit, Benutzbarkeit, Wartbarkeit und Übertragbarkeit. Formulieren Sie jede dieser Anforderungen mit Messgröße und Messbedingung. „Das System ist schnell“ ist keine Anforderung, „95 % der Suchanfragen werden bei 200 gleichzeitigen Nutzern in höchstens zwei Sekunden beantwortet“ ist eine.
Schnittstellen und technische Umgebung
Schnittstellen sind das größte Schätzrisiko in Softwareprojekten, weil sie von fremden Systemen abhängen. Halten Sie für jede Schnittstelle fest: Gegenstelle, Richtung des Datenflusses, Protokoll und Format (etwa REST mit JSON), Authentifizierung, Verhalten bei Fehlern und Ausfällen sowie den Ansprechpartner auf der Gegenseite. Zur technischen Umgebung gehören unterstützte Browser und Betriebssystemversionen, der Hosting-Standort und die Vorgaben der IT des Auftraggebers.
Wie sieht ein Pflichtenheft aus? Vorlage zum Kopieren
Die folgende Vorlage können Sie in ein Dokument oder Wiki übernehmen. Ersetzen Sie die Platzhalter in eckigen Klammern und streichen Sie Unterpunkte, die für Ihr Projekt nicht gelten. Notieren Sie kurz, warum ein Punkt entfällt: So sieht der Leser, dass er nicht vergessen wurde.
Deckblatt
- Projekt: [Projektname]
- Auftraggeber: [Unternehmen, Ansprechpartner]
- Auftragnehmer: [Unternehmen, Ansprechpartner]
- Version und Datum: [z. B. 1.0 vom TT.MM.JJJJ]
- Status: [Entwurf / zur Prüfung / freigegeben]
- Bezug: [Lastenheft, Version, Datum]
Änderungshistorie
| Version | Datum | Autor | Änderung |
|---|---|---|---|
| [0.1] | [TT.MM.JJJJ] | [Name] | [Erster Entwurf] |
| [1.0] | [TT.MM.JJJJ] | [Name] | [Freigabe durch den Auftraggeber] |
Gliederung
- Zielbestimmung: Musskriterien [Liste], Wunschkriterien [Liste], Abgrenzungskriterien [Liste]
- Produkteinsatz: Anwendungsbereiche [Text], Zielgruppen [Rollen], Betriebsbedingungen [Betriebszeiten, Aufsicht, Wartungsfenster]
- Produktübersicht: Systemkontext [Diagramm], Hauptanwendungsfälle [Liste], Architekturskizze [Diagramm]
- Produktfunktionen: /F10/ [Name der Funktion] bis /Fnn/, jeweils mit Auslöser, Ablauf, Fehlerfällen und Ergebnis
- Produktdaten: /D10/ [Datenobjekt] bis /Dnn/, jeweils mit Attributen, Mengengerüst und Aufbewahrungsfrist
- Produktleistungen: /L10/ [Qualitätsmerkmal] bis /Lnn/, jeweils mit Messgröße und Messbedingung
- Benutzungsoberfläche: Dialogstruktur [Übersicht], Wireframes [Verweis], Barrierefreiheit [Standard], Sprachen [Liste]
- Schnittstellen: /S10/ [Gegenstelle] bis /Snn/, jeweils mit Protokoll, Format, Authentifizierung und Fehlerverhalten
- Technische Produktumgebung: Software [Liste], Hardware [Liste], Hosting [Anbieter, Standort], unterstützte Browser und Geräte [Liste]
- Entwicklungsumgebung: Sprachen und Frameworks [Liste], Repository [Ort], Build und Auslieferung [Verfahren]
- Testfälle und Abnahmekriterien: /T10/ [Testfall] bis /Tnn/ mit Verweis auf die geprüfte Anforderung, Abnahmeverfahren [Ablauf, Fristen, Fehlerklassen]
- Anhang: Glossar, Datenmodell, offene Punkte mit Verantwortlichem und Termin
Freigabe
- Auftraggeber: [Name, Datum, Unterschrift]
- Auftragnehmer: [Name, Datum, Unterschrift]
Pflichtenheft-Beispiel: Auszug für ein Softwareprojekt
Der folgende Auszug ist ein frei erfundenes Beispiel. Er zeigt, wie Einträge in einem Pflichtenheft für ein Kundenportal mit Terminbuchung aussehen können, und stammt nicht aus einem Kundenprojekt.
| Kennung | Anforderung | Abnahmekriterium |
|---|---|---|
| /F10/ | Ein Kunde registriert sich mit E-Mail-Adresse und Passwort. Das Konto wird erst nach Bestätigung der E-Mail-Adresse aktiv. | Nach der Registrierung erhält der Kunde eine E-Mail mit Bestätigungslink. Vor dem Klick ist keine Anmeldung möglich, danach schon. |
| /F20/ | Ein angemeldeter Kunde bucht einen freien Termin aus dem Kalender eines Standorts. | Ein gebuchter Termin erscheint im Kundenkonto und ist für andere Kunden nicht mehr buchbar. Buchen zwei Kunden gleichzeitig denselben Termin, erhält genau einer die Bestätigung. |
| /F30/ | Ein Kunde storniert einen Termin bis 24 Stunden vor Beginn. | Bis 24 Stunden vorher wird der Termin wieder frei. Danach zeigt das System einen Hinweis und storniert nicht. |
| /D10/ | Kundendaten: Name, E-Mail-Adresse, Telefonnummer, Buchungshistorie. | Ein Kunde kann seine Daten einsehen, ändern und die Löschung des Kontos auslösen. |
| /L10/ | Die Kalenderansicht lädt bei 200 gleichzeitigen Nutzern in höchstens zwei Sekunden. | Ein Lasttest mit 200 simulierten Nutzern bestätigt den Wert für 95 % der Aufrufe. |
| /L20/ | Passwörter werden ausschließlich als gesalzene Hashwerte gespeichert. | Code-Review und Prüfung der Datenbank zeigen keine Passwörter im Klartext. |
| /S10/ | Gebuchte Termine werden über eine REST-Schnittstelle an das Kalendersystem des Auftraggebers übertragen. | Ein gebuchter Termin erscheint innerhalb einer Minute im Kalendersystem. Ist die Gegenstelle nicht erreichbar, wiederholt das Portal die Übertragung und protokolliert den Fehler. |
Ein dazugehöriger Testfall im selben Stil: /T20/ prüft /F20/. Vorbedingung: Zwei Kunden sind angemeldet, der Termin ist frei. Aktion: Beide bestätigen die Buchung zeitgleich. Erwartetes Ergebnis: Ein Kunde sieht die Buchungsbestätigung, der andere den Hinweis, dass der Termin vergeben ist.
Achten Sie auf drei Dinge. Jede Zeile beschreibt genau eine Anforderung. Jedes Kriterium lässt sich mit Ja oder Nein beantworten. Und auch die Fehlerfälle sind beschrieben, denn dort entstehen später die meisten Diskussionen.
Unterschied zwischen Lastenheft und Pflichtenheft
Das Lastenheft beschreibt die Aufgabe, das Pflichtenheft die Lösung. Beide Dokumente bauen aufeinander auf und gehören vertraglich zusammen.
| Merkmal | Lastenheft | Pflichtenheft |
|---|---|---|
| Verfasser | Auftraggeber | Auftragnehmer |
| Kernfrage | Was wird gebraucht und wofür? | Wie und womit wird es umgesetzt? |
| Zeitpunkt | Vor der Ausschreibung oder Anfrage | Nach der Anfrage, vor Beginn der Entwicklung |
| Sprache | Fachlich, lösungsneutral | Technisch, konkret, prüfbar |
| Detailgrad | Ziele, Rahmenbedingungen, Anforderungen | Funktionen, Daten, Schnittstellen, Architektur, Testfälle |
| Rolle im Vertrag | Grundlage für Anfrage und Angebotsvergleich | Grundlage für Angebot, Umsetzung und Abnahme |
| Bezeichnung im V-Modell XT | Anforderungen (Lastenheft) | Gesamtsystemspezifikation (Pflichtenheft) |
Wie Sie als Auftraggeber die Anforderungsseite aufbauen, lesen Sie im Artikel Lastenheft: Vorlage, Beispiel & Aufbau. Liegt kein Lastenheft vor, beginnt das Pflichtenheft mit einer Anforderungsaufnahme. Das Team führt dann Interviews und Workshops durch und hält die Ergebnisse im Kapitel Zielbestimmung fest.
Wer schreibt das Pflichtenheft und wer nimmt es ab?
Das Pflichtenheft schreibt der Auftragnehmer. In einem Softwareprojekt arbeiten daran in der Regel mehrere Rollen: Business-Analyse oder Requirements Engineering für die Funktionen, Softwarearchitektur für Aufbau, Schnittstellen und nichtfunktionale Anforderungen, QA für Testfälle und Abnahmekriterien, UX-Design für die Benutzungsoberfläche.
Der Auftraggeber liefert das Fachwissen, beantwortet Rückfragen und gibt das Dokument frei. Planen Sie für die Prüfung Zeit ein und beziehen Sie die späteren Anwender und Ihre IT ein. Erst nach der Freigabe sollte die Entwicklung beginnen.
Bei einem Werkvertrag ist das freigegebene Pflichtenheft der Maßstab für die Abnahme. Der Besteller ist nach § 640 BGB verpflichtet, das vertragsmäßig hergestellte Werk abzunehmen. Was vertragsgemäß ist, ergibt sich aus den dokumentierten Anforderungen und ihren Abnahmekriterien. Für die Vertragsgestaltung im Einzelfall ziehen Sie bitte juristischen Rat hinzu.
Braucht man ein Pflichtenheft in agilen Projekten?
Ja, aber in anderer Form. Agile Teams ersetzen das eine große Dokument durch mehrere kleinere Bausteine, die schrittweise entstehen:
- Produktvision und Abgrenzung übernehmen die Rolle der Zielbestimmung.
- Das Product Backlog mit User Storys und Akzeptanzkriterien entspricht den Produktfunktionen und Testfällen.
- Die Definition of Done legt fest, wann eine Arbeit als fertig gilt. Der Scrum Guide beschreibt sie als verbindliche Zusage für jedes Inkrement.
- Architekturentscheidungen und Schnittstellenbeschreibungen werden weiterhin schriftlich festgehalten, weil sie sich später nur teuer ändern lassen.
Was sich nicht ändert: Nichtfunktionale Anforderungen, Schnittstellen und Datenschutz müssen früh geklärt werden. Sie lassen sich nicht in Sprint zwölf nachrüsten, ohne Teile der Architektur umzubauen.
Bewährt hat sich ein gemischtes Vorgehen. In einer kurzen Konzeptphase entstehen Zielbestimmung, Architekturskizze, die wichtigsten Anforderungen und Abnahmekriterien. Auf dieser Grundlage lässt sich ein Festpreis für einen klar abgegrenzten Umfang vereinbaren, etwa für ein MVP. Die Details der einzelnen Funktionen werden danach Sprint für Sprint im Backlog ausgearbeitet. Ändern sich die Anforderungen laufend, passt Time & Material oder ein Dedicated Team besser als ein Festpreis.
Typische Fehler im Pflichtenheft
- Unprüfbare Formulierungen. „Benutzerfreundlich“, „performant“ und „modern“ lassen sich nicht abnehmen. Ersetzen Sie jedes dieser Wörter durch eine Messgröße oder ein beobachtbares Verhalten.
- Abschrift des Lastenhefts. Wiederholt das Pflichtenheft nur die Wünsche des Auftraggebers, fehlt die eigentliche Leistung: die Beschreibung der Lösung.
- Fehlende Abgrenzung. Was nicht zum Umfang gehört, muss genauso klar dastehen wie das, was dazugehört. Sonst wird jede Lücke später zum Änderungswunsch ohne Budget.
- Vergessene nichtfunktionale Anforderungen. Lastverhalten, Verfügbarkeit, Sicherheit und Datenschutz tauchen oft erst kurz vor dem Go-live auf.
- Offene Schnittstellen. „Anbindung an das ERP-System“ ist keine Spezifikation. Ohne Protokoll, Datenformat und Ansprechpartner bleibt die Schätzung ein Ratespiel.
- Keine Versionierung. Ohne Änderungshistorie weiß nach drei Monaten niemand mehr, welche Fassung freigegeben wurde.
- Zu viel Implementierungsdetail. Klassennamen und Datenbankindizes gehören ins technische Design. Das Pflichtenheft muss für den Auftraggeber lesbar bleiben, sonst kann er es nicht ernsthaft prüfen.
Wie Join.To.IT Sie unterstützt
Join.To.IT entwickelt seit 2012 Software, das Team sitzt in Kyjiw und ist Deutschland, Österreich und der Schweiz eine Stunde voraus. Business-Analyse, Architektur, UX-Design und QA arbeiten bei uns gemeinsam an der Spezifikation: Wir nehmen Ihr Lastenheft oder Ihre Idee auf, klären offene Punkte und erstellen daraus ein prüfbares Pflichtenheft mit Aufwandsschätzung. Auf dieser Grundlage setzen wir Webanwendungen, individuelle Software und mobile Apps für iOS und Android um. Mehr über unsere Arbeitsweise finden Sie auf der Startseite. Wenn Sie ein Projekt besprechen möchten, schreiben Sie uns.
FAQ
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Das Lastenheft stammt vom Auftraggeber und beschreibt, was er braucht und wofür. Das Pflichtenheft stammt vom Auftragnehmer und beschreibt, wie und womit er diese Anforderungen umsetzt. Das Lastenheft ist fachlich und lösungsneutral, das Pflichtenheft technisch und prüfbar.
Wer erstellt das Pflichtenheft?
Der Auftragnehmer, bei Softwareprojekten also das Entwicklungsunternehmen oder die interne IT. Der Auftraggeber wirkt mit, indem er Fragen beantwortet, und gibt das fertige Dokument frei.
Ist ein Pflichtenheft rechtlich bindend?
Wird das Pflichtenheft Bestandteil des Vertrags, beschreibt es die geschuldete Leistung und dient als Maßstab für die Abnahme. Ob und in welcher Form es Vertragsbestandteil wird, regeln die Parteien im Vertrag. Lassen Sie diese Frage juristisch prüfen.
Wie lang sollte ein Pflichtenheft sein?
So lang, dass jede Anforderung eindeutig und prüfbar ist, und nicht länger. Für ein überschaubares Web- oder App-Projekt reichen oft einige Dutzend Seiten, komplexe Systeme mit vielen Schnittstellen brauchen deutlich mehr. Entscheidend ist die Vollständigkeit der Kapitel, nicht die Seitenzahl.
Gibt es eine Norm für das Pflichtenheft?
Die DIN 69901-5 definiert den Begriff, schreibt aber keinen Aufbau vor. Für IT-Projekte der öffentlichen Hand gibt das V-Modell XT Bund Inhalte und Struktur der Gesamtsystemspezifikation vor. In der Privatwirtschaft ist die Gliederung frei wählbar.
Kann man ohne Lastenheft ein Pflichtenheft schreiben?
Ja. In diesem Fall erhebt der Auftragnehmer die Anforderungen selbst, meist in Workshops und Interviews, und dokumentiert sie im Kapitel Zielbestimmung. Wichtig ist, dass der Auftraggeber diese Anforderungen ausdrücklich bestätigt, bevor die Lösung beschrieben wird.
