Pflichtenheft für Software: Vorlage, Aufbau — und wann ihr keins braucht
Lastenheft = was der Auftraggeber will. Pflichtenheft = wie der Auftragnehmer es umsetzt. Für den Projektstart braucht ihr weder das eine noch das andere in Reinform, sondern ein Anforderungsdokument von 2–4 Seiten: Ziel, Ist-Prozess, Muss/Soll/Kann-Funktionen, Schnittstellen, Rahmenbedingungen — und eine ehrliche Liste offener Fragen. Ausfüllen und direkt herunterladen könnt ihr es im Pflichtenheft-Generator; die leere Vorlage gibt es als Word-Datei oder als Markdown. Ein 80-Seiten-Pflichtenheft dagegen ist meist teure Fiktion — es beschreibt Software, die noch niemand benutzt hat.
Jede Woche bekommen wir Anfragen in zwei Extremformen: „Wir brauchen eine App, was kostet das?" (ein Satz) und ein 60-Seiten-PDF, in dem jede Maske pixelgenau beschrieben ist — nur leider an den echten Abläufen vorbei. Beide führen zu schlechten Angeboten. Hier ist das Format dazwischen, das funktioniert.
Lastenheft vs. Pflichtenheft — der Unterschied in einem Satz
Das Lastenheft schreibt der Auftraggeber: WAS soll erreicht werden und WOFÜR. Das Pflichtenheft schreibt klassisch der Auftragnehmer als Antwort darauf: WIE wird es konkret umgesetzt. In der Praxis der Individualentwicklung sind die Begriffe zusammengewachsen — was Unternehmen heute „Pflichtenheft-Vorlage" googeln, ist fast immer das, was wir ein Anforderungsdokument nennen: die strukturierte Grundlage, mit der ein Dienstleister ein seriöses Angebot rechnen kann.
Warum das 80-Seiten-Pflichtenheft ausgedient hat
Ein detailliertes Pflichtenheft vor Projektstart hat drei eingebaute Probleme:
- Es beschreibt Vermutungen. Niemand hat die Software benutzt; trotzdem werden Detailentscheidungen fixiert, die nach zwei Wochen echter Nutzung anders ausfallen würden.
- Es verschiebt Verantwortung statt Risiko. „Steht so im Pflichtenheft" gewinnt jede Diskussion — auch wenn das Ergebnis niemandem hilft. Ihr bekommt Vertragskonformität statt Problemlösung.
- Es kostet den Puffer, der euch fehlt. Vier Wochen Dokumentenarbeit plus Abstimmungsschleifen, bevor die erste Zeile Code existiert — bei iterativer Entwicklung hättet ihr nach vier Wochen bereits eine nutzbare erste Version.
Deshalb arbeiten moderne Projekte mit einem kompakten Anforderungsdokument plus Scoping: Die Detailtiefe entsteht gemeinsam, pro Iteration, am lebenden Produkt — mit wöchentlichen Demos statt Kapitelabnahmen.
Die 11 Kapitel, die ein Angebot präzise machen
Unsere Vorlage hat genau diese Struktur:
| # | Kapitel | Die eine Frage dahinter |
|---|---|---|
| 1 | Projektziel | Woran messt ihr Erfolg nach 6 Monaten? |
| 2 | Ist-Prozess | Wo genau geht heute Zeit verloren? |
| 3 | Ziele & Nicht-Ziele | Was ist ausdrücklich NICHT in Version 1? |
| 4 | Nutzer & Rollen | Wer arbeitet damit, wer darf was sehen? |
| 5 | Funktionen (Muss/Soll/Kann) | Ohne welche Funktion geht es nicht live? |
| 6 | Nicht-funktionale Anforderungen | Last, Verfügbarkeit, DSGVO, Hosting-Vorgaben |
| 7 | Schnittstellen | Hat das Altsystem eine echte API — und Testzugang? |
| 8 | Daten | Was muss migriert werden, in welcher Qualität? |
| 9 | Rahmenbedingungen | Budgetspanne, Termine, wer entscheidet? |
| 10 | Abnahme & Betrieb | Woran wird abgenommen, wer wartet danach? |
| 11 | Offene Fragen | Was wisst ihr ehrlich noch nicht? |
Zwei Kapitel entscheiden über die Angebotsqualität: Nicht-Ziele (das billigste Werkzeug gegen Scope-Explosion, das es gibt) und offene Fragen — ein „[OFFEN]" im Dokument ist Gold wert, denn erfundene Antworten werden als Anforderungen eingepreist und später teuer zurückgebaut.
Was ihr weglassen könnt
Pixelgenaue Masken-Beschreibungen (das Design entsteht iterativ), Technologie-Vorgaben ohne Grund („muss in Java sein", wenn niemand weiß warum), Gantt-Diagramme über 12 Monate und jede Anforderung, die mit „Das System muss benutzerfreundlich sein" beginnt. Eine Budgetspanne dagegen gehört hinein: Sie ist keine Verhandlungsschwäche, sondern der schnellste Filter dafür, welcher Lösungszuschnitt überhaupt in Frage kommt.
Lastenheft, Pflichtenheft oder Anforderungskatalog?
Die Begriffsfrage kostet in der Praxis mehr Zeit als sie wert ist. Nach DIN 69901 schreibt der Auftraggeber das Lastenheft (WAS und WOFÜR) und der Auftragnehmer antwortet mit dem Pflichtenheft (WIE). Wer intern von einem Anforderungskatalog spricht, meint meist dasselbe in Tabellenform.
Für ein Softwareprojekt in der Größenordnung, in der wir arbeiten, ist die Unterscheidung folgenlos: Ihr braucht ein Dokument, das euer Ziel, eure Nicht-Ziele und eure priorisierten Anforderungen festhält. Ob es Lastenheft, Pflichtenheft oder Anforderungsdokument heißt, ändert am Angebot nichts — an der Struktur schon. Erst wenn ihr öffentlich ausschreibt oder mehrere Anbieter formal vergleicht, lohnt die saubere Trennung: dann geht das Lastenheft an alle Anbieter und jedes Pflichtenheft kommt als individuelle Antwort zurück.
So geht es nach dem Dokument weiter
Mit einem 2–4-Seiten-Anforderungsdokument kann ein seriöser Anbieter im Erstgespräch die richtigen Rückfragen stellen und danach eine belastbare Spanne nennen. Bei uns folgt darauf das Scoping: Anforderungen priorisieren, Version 1 zuschneiden, Meilensteine und Schätzung — und dann wöchentliche Demos statt Pflichtenheft-Archäologie.
Direkt online ausfüllen: Pflichtenheft-Generator. Die leere Vorlage: Word (.docx) · Markdown (.md) — frei verwendbar. Wie der gesamte Prozess vom Dokument bis zum Release abläuft, steht unter Software entwickeln lassen; was euer Vorhaben kosten würde, beantwortet in zwei Minuten der MVP-Kostenrechner.
