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. Unsere Vorlage dafür gibt es hier kostenlos: 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.
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.
Die 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.
