Wissen
Lastenheft und Pflichtenheft: der Unterschied, klar erklärt
Zwei Dokumente, die ständig verwechselt werden. Das eine schreibst du, das andere der Anbieter. Hier steht, was in welches gehört, mit einer Struktur zum Abtippen, und die ehrliche Antwort auf die Frage, ob du überhaupt ein Lastenheft brauchst.
Kurz gesagt
Das Lastenheft schreibt der Auftraggeber und beschreibt das Was und Wozu: Ziele, Anforderungen, Rahmen. Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf und beschreibt das Wie und Womit: die technische Umsetzung.
Für wen diese Seite ist: Unternehmen und Projektverantwortliche, die ein Softwareprojekt vorbereiten und die Anforderungen sauber aufschreiben wollen.
Lastenheft und Pflichtenheft im direkten Vergleich
| Lastenheft | Pflichtenheft | |
|---|---|---|
| Wer schreibt es | Der Auftraggeber, also du | Der Auftragnehmer, also die Agentur oder der Dienstleister |
| Kernfrage | Was soll entstehen und wozu? | Wie und womit wird es gebaut? |
| Inhalt | Ziele, Anforderungen, Rahmen, Abnahmekriterien | Technische Lösung, Architektur, Meilensteine |
| Zeitpunkt | Vor der Anbieterauswahl | Als Antwort auf das Lastenheft, oft Teil des Vertrags |
| Zweck | Grundlage, um vergleichbare Angebote einzuholen | Verbindlicher Plan und Maßstab für die Abnahme |
Was ins Lastenheft gehört
Nimm das als Gliederung und füll sie mit deinem Projekt. Vollständigkeit um jeden Preis ist nicht das Ziel. Das Ziel ist, dass ein Anbieter danach ein belastbares Angebot rechnen kann, ohne zu raten.
- 1
Ausgangslage und Ziel
Warum das Projekt jetzt kommt und woran du in einem Jahr Erfolg misst.
- 2
Ist-Zustand
Wie der Prozess heute läuft, mit welchen Tools, wo es hakt.
- 3
Funktionale Anforderungen
Was das System können muss, in der Sprache deines Ablaufs, nicht in Technik.
- 4
Nicht-funktionale Anforderungen
Tempo, Datenschutz, Barrierefreiheit, Verfügbarkeit, Sicherheit.
- 5
Schnittstellen
Welche bestehenden Systeme mitspielen müssen, etwa Warenwirtschaft, PMS oder Buchhaltung.
- 6
Rahmen
Budgetkorridor, Wunschtermine, rechtliche Vorgaben.
- 7
Abnahmekriterien
Woran alle erkennen, dass eine Anforderung wirklich erfüllt ist.
Was ins Pflichtenheft gehört
Das Pflichtenheft ist die Antwort des Anbieters. Es übersetzt jede Anforderung aus dem Lastenheft in eine konkrete Lösung: welche Architektur, welche Schnittstellen, welche Schritte in welcher Reihenfolge. Dazu gehören die technische Umsetzung je Anforderung, die Aufteilung in Meilensteine, die Schnittstellen und Datenflüsse, und ein Plan, an dem sich später die Abnahme misst. Ein gutes Pflichtenheft macht sichtbar, wo Annahmen stecken, bevor sie Geld kosten.
Die Fehler, an denen Projekte scheitern, bevor die erste Zeile Code steht
Die meisten gescheiterten Projekte scheitern nicht am Programmieren. Sie scheitern davor, im Papier. Drei Muster tauchen immer wieder auf.
Anforderungen als Technik statt als Ablauf. Wer ins Lastenheft schreibt, welche Datenbank es sein soll, engt die Lösung ein, bevor sie durchdacht ist. Beschreibe, was der Prozess leisten muss, nicht womit.
Das Unsichtbare fehlt. Datenschutz, Barrierefreiheit, Tempo bei Last, Rechte und Rollen. Was nicht drinsteht, wird später teuer nachgezogen.
Keine Abnahmekriterien. Ohne den Satz, woran Fertig erkennbar ist, streiten am Ende beide Seiten über Auslegung. Wie wir aus Anforderungen ein Projekt machen, das nicht an diesen Stellen kippt, steht unter Softwareentwicklung.
Ist ein Lastenheft noch zeitgemäß?
Kommt darauf an, und das ist keine Ausrede. Für ein klar abgegrenztes Projekt mit festen Vorgaben ist ein Lastenheft weiter das richtige Werkzeug.
Für Software, deren Anforderungen sich erst im Tun schärfen, ist ein starres Heft oft ein Problem. Du legst früh Dinge fest, die nach dem ersten echten Test anders aussehen, und arbeitest dann gegen dein eigenes Papier. In diesen Fällen bringt ein gemeinsamer Discovery-Schritt mehr: Anforderungen, Prioritäten und ein erster Plan entstehen zusammen, bevor größere Beträge gebunden sind.
FAQ
Häufig gestellte Fragen
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Das Lastenheft schreibt der Auftraggeber und beschreibt das Was und Wozu: Ziele, Anforderungen, Rahmen. Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf und beschreibt das Wie und Womit: die technische Lösung. Kurz: erst das Problem aus deiner Sicht, dann der Lösungsplan aus Sicht des Umsetzers.
Wer erstellt das Lastenheft und wer das Pflichtenheft?
Das Lastenheft kommt von dir als Auftraggeber, oft mit den Menschen, die den Prozess täglich machen. Das Pflichtenheft kommt vom Anbieter, der die Umsetzung übernimmt. In der Praxis erarbeiten gute Anbieter das Pflichtenheft gemeinsam mit dir, damit keine Annahme unausgesprochen bleibt.
Was gehört alles ins Lastenheft?
Ausgangslage und Ziel, der Ist-Zustand, funktionale und nicht-funktionale Anforderungen, Schnittstellen zu bestehenden Systemen, der Rahmen aus Budget und Terminen, und die Abnahmekriterien. Wichtig ist nicht Vollständigkeit um jeden Preis, sondern dass ein Anbieter danach ein belastbares Angebot rechnen kann.
Ist ein Lastenheft noch zeitgemäß?
Für ein klar abgegrenztes Projekt mit festen Vorgaben ist es weiter sinnvoll. Für Software, deren Anforderungen sich im Lauf der Arbeit schärfen, ist ein starres Heft oft das falsche Werkzeug. Dann bringt ein gemeinsamer Discovery-Schritt mehr, in dem Anforderungen, Prioritäten und ein erster Plan zusammen entstehen.
Brauche ich für ein Softwareprojekt zwingend ein Lastenheft?
Nein. Du brauchst Klarheit über Ziel, Ablauf und Prioritäten. Ob das ein formales Lastenheft wird oder das Ergebnis eines Discovery-Workshops, ist zweitrangig. Entscheidend ist, dass beide Seiten vor dem Bau dasselbe Bild haben.