Kurzantwort: Das Lastenheft kommt vom Auftraggeber und beschreibt, was eine Software leisten soll und wofür. Das Pflichtenheft kommt vom Auftragnehmer und beschreibt, wie er diese Anforderungen umsetzt. Die Anforderungsanalyse ist die Arbeit davor: Anforderungen erheben, klären, priorisieren und prüfen. Für ein kleineres Softwareprojekt im Mittelstand reicht oft ein kurzes Lastenheft mit konkreten Abnahmefällen, wenn ein Prototyp die offenen Fragen klärt. Wichtig ist nicht der Umfang des Dokuments, sondern dass Umfang und Abnahme vor dem Build schriftlich feststehen.
Wer Software entwickeln lassen will, bekommt früh die Frage nach dem Lastenheft gestellt. Viele Unternehmen haben keines und fragen sich, ob sie erst ein langes Dokument schreiben müssen, bevor ein Gespräch sinnvoll ist. Dieser Ratgeber erklärt die Begriffe und den Unterschied, zeigt eine Gliederung, die es auch als kostenlose Word-Vorlage gibt, und beschreibt, wann ein schlanker Start besser passt.
Was ist ein Lastenheft?
Das Lastenheft fasst die Anforderungen des Auftraggebers zusammen. Die Norm DIN 69901-5 zu Begriffen im Projektmanagement ordnet es dem Auftraggeber zu: Er legt darin fest, welche Lieferungen und Leistungen er vom Auftragnehmer erwartet. Für Software heißt das: Das Lastenheft beschreibt das Problem, die Abläufe und das gewünschte Ergebnis. Es beschreibt nicht, mit welcher Technik die Lösung gebaut wird.
Ein gutes Lastenheft beantwortet drei Fragen. Wer arbeitet mit der Software und in welcher Rolle? Welche Abläufe soll sie unterstützen, mit welchen typischen Fällen und Ausnahmen? Woran erkennen Sie am Ende, dass sie funktioniert? Die dritte Frage wird am häufigsten vergessen.
Was ist ein Pflichtenheft?
Das Pflichtenheft ist die Antwort des Auftragnehmers. Laut DIN 69901-5 erarbeitet er darin auf Grundlage des Lastenhefts seine Vorgaben für die Umsetzung. Für Software beschreibt es zum Beispiel die geplanten Funktionen und Ansichten, das Datenmodell, die Schnittstellen, den Betrieb und die Art der Abnahme.
Eine verbreitete Eselsbrücke fasst den Unterschied zusammen: Das Lastenheft sagt, was und wofür, das Pflichtenheft sagt, wie und womit. Die VDI-Richtlinie 2519 Blatt 1 beschreibt das Vorgehen beim Erstellen beider Dokumente. Sie stammt aus dem Jahr 2001 und wurde ursprünglich für Materialfluss- und Automatisierungssysteme geschrieben. Die Aufteilung der Rollen gilt aber für Softwareprojekte ebenso.
Unterschied zwischen Lastenheft und Pflichtenheft
Der Unterschied liegt im Absender und in der Leitfrage: Das Lastenheft schreibt der Auftraggeber, es sagt, was gebraucht wird. Das Pflichtenheft schreibt der Auftragnehmer, es sagt, wie er es liefert.
| Lastenheft | Pflichtenheft | |
|---|---|---|
| Wer schreibt es? | Auftraggeber, also das Unternehmen mit dem Bedarf | Auftragnehmer, also der Dienstleister |
| Leitfrage | Was soll die Software leisten, und wofür? | Wie wird das umgesetzt, und womit? |
| Inhalt | Ausgangslage, Rollen, Abläufe, Anforderungen, Rahmenbedingungen, Abnahmekriterien | Funktionen, Datenmodell, Schnittstellen, Architektur, Betrieb, Abnahmeverfahren |
| Wann? | Vor der Angebotsanfrage | Nach dem Lastenheft, vor oder zu Beginn der Umsetzung |
| Typischer Fehler | Lösung vorgeben statt Problem beschreiben | Anforderungen aus dem Lastenheft stillschweigend weglassen |
Was ist eine Anforderungsanalyse?
Die Anforderungsanalyse ist die Arbeit, aus der beide Dokumente entstehen. Sie hat vier Schritte: Anforderungen bei den Beteiligten erheben, unklare Stellen klären, Anforderungen priorisieren und das Ergebnis auf Widersprüche und Lücken prüfen. Die internationale Norm ISO/IEC/IEEE 29148 beschreibt die Prozesse des Requirements Engineering und die Eigenschaften guter Anforderungen. Laut ISO ist die Ausgabe von 2018 aktuell; eine überarbeitete Fassung liegt als Norm-Entwurf vor (Stand Oktober 2026).
Praktisch heißt das für ein mittelständisches Unternehmen: Sprechen Sie mit den Menschen, die den Ablauf heute bearbeiten, nicht nur mit der Geschäftsführung. Lassen Sie sich echte Vorgänge zeigen, auch die unangenehmen Ausnahmen. Und schreiben Sie jede Anforderung so, dass man später prüfen kann, ob sie erfüllt ist.
Was gehört in ein Lastenheft für Software? Eine Gliederung als Vorlage
Diese Gliederung passt für die meisten Vorhaben im Mittelstand. Laden Sie die Word-Vorlage unten herunter oder kopieren Sie die Überschriften in ein eigenes Dokument und füllen Sie sie mit Stichpunkten.
- Ausgangslage und Ziel: Was läuft heute wie, was kostet es, und was soll sich ändern?
- Beteiligte und Rollen: Wer arbeitet mit der Software, wer gibt frei, wer betreut sie?
- Abläufe: Jeder wichtige Ablauf mit einem typischen Fall und den häufigsten Ausnahmen.
- Fachliche Anforderungen: Was die Software können muss, jeweils mit Priorität (muss, soll, kann).
- Daten und Schnittstellen: Welche Daten es heute gibt, wo sie liegen und welches System für welche Angabe führend ist.
- Datenschutz und Sicherheit: Welche personenbezogenen Daten verarbeitet werden und wer worauf zugreifen darf.
- Betrieb: Wo die Software laufen soll, wer sie aktualisiert und was bei einem Ausfall passiert.
- Rahmenbedingungen: Termine, Budgetrahmen, Vorgaben der eigenen IT.
- Abnahmekriterien: Fünf bis zehn konkrete Fälle, an denen Sie die fertige Software prüfen.
Die Vorlage ist ohne Anmeldung nutzbar. Sie enthält die neun Abschnitte mit kurzen Hinweisen, Tabellen für Rollen, Abläufe, Anforderungen, Daten und Abnahmefälle sowie je eine als Beispiel markierte Zeile. Die Beispielzeilen sind konstruiert und enthalten keine Kundendaten; löschen Sie sie beim Ausfüllen.
Lastenheft fertig? Beim kostenlosen Lastenheft-Check liest Simon Maiwald Ihr Dokument und schickt Ihnen innerhalb von drei Werktagen eine schriftliche Einschätzung: Lücken, unklare Anforderungen und die Fragen, die vor dem Versand an Anbieter geklärt sein sollten.
Beispiel: eine Anforderung prüfbar formulieren
Konstruiertes Beispiel ohne Kundendaten. Warum wir so arbeiten
Ein Großhändler will ein Kundenportal. Im ersten Entwurf des Lastenhefts steht: „Kunden sollen ihre Bestellungen einsehen können.“ Das klingt klar, lässt aber offen, welche Bestellungen, welche Angaben und welche Personen gemeint sind.
Prüfbar formuliert wird daraus: „Eine Ansprechperson eines Kunden sieht alle Bestellungen ihres Unternehmens aus den letzten 24 Monaten mit Status, Liefertermin und Rechnung als PDF. Bestellungen anderer Kunden sieht sie nicht, auch nicht über einen direkten Link.“ Daraus ergibt sich ein Abnahmefall, den man vor dem Start testen kann. Das Beispiel zeigt nur die Formulierung.
Typische Fehler beim Lastenheft
- Lösung statt Problem: „Wir brauchen eine App“ ist eine Lösung. Das Problem dahinter, etwa dass Aufträge doppelt erfasst werden, gehört ins Lastenheft.
- Nur der Normalfall: Ausnahmen wie Teillieferungen, Stornos oder Vertretungen verursachen später den meisten Aufwand. Nennen Sie sie früh.
- Keine Prioritäten: Wenn alles „muss“ ist, lassen sich Angebote nicht vergleichen und Umfang nicht verhandeln.
- Betrieb vergessen: Hosting, Updates und Zuständigkeiten nach dem Start bestimmen die laufenden Kosten. Unser Ratgeber zu Kosten individueller Software trennt Einmalkosten und Betrieb.
- Keine Abnahmekriterien: Ohne vereinbarte Fälle wird die Abnahme zur Diskussion.
Wann ein schlanker Start besser ist als ein langes Pflichtenheft
Ein ausführliches Pflichtenheft lohnt sich bei Ausschreibungen, bei großen Festpreisprojekten und wenn mehrere Anbieter auf derselben Grundlage anbieten sollen. Bei einer neuen Produktidee oder einem abgegrenzten Ablauf kann ein langes Dokument dagegen Wochen kosten, bevor jemand prüft, ob der Ansatz trägt.
Dann hilft ein schlanker Start: ein kurzes Lastenheft nach der Gliederung oben, dazu ein Prototyp an echten Beispielen. Bei NLD ist das der Discovery-Sprint: 5 Arbeitstage für 4.900 € netto. Am ersten Tag legen wir die Abnahmefälle fest, an Tag drei entsteht ein Prototyp mit Ihren Beispielen, am Ende stehen Live-Demo, Bewertung und Empfehlung. Der geprüfte Umfang ist dann die Grundlage für den Festpreis des optionalen Builds. Wie das bei einer neuen Produktidee aussieht, beschreibt unsere Seite zur MVP-Entwicklung, für bestehende Abläufe die Seite zur individuellen Softwareentwicklung.
Die Entscheidung in einem Satz
Schreiben Sie ein Lastenheft, das Abläufe, Ausnahmen und Abnahmefälle konkret beschreibt; ob daraus ein langes Pflichtenheft oder ein Prototyp mit festem Umfang wird, hängt von der Größe des Vorhabens und der Art der Vergabe ab. Bevor Sie das Lastenheft verschicken, können Sie es im kostenlosen Lastenheft-Check prüfen lassen.
Quellen und weiterführende Dokumente
Häufige Fragen
Kurz und direkt beantwortet.
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Das Lastenheft beschreibt aus Sicht des Auftraggebers, was die Software leisten soll und wofür. Das Pflichtenheft beschreibt aus Sicht des Auftragnehmers, wie diese Anforderungen umgesetzt werden. Die Norm DIN 69901-5 grenzt die Begriffe nach dem Urheber ab: Das Lastenheft legt der Auftraggeber fest, das Pflichtenheft erarbeitet der Auftragnehmer auf dessen Grundlage.
Sind Lastenhefte noch zeitgemäß?
Ja, in schlanker Form. Auch agile Projekte brauchen ein gemeinsames Verständnis von Ziel, Abläufen und Abnahme, bevor das Budget fließt. Überholt ist eher das lange Dokument, an dem monatelang geschrieben wird. Ein kurzes Lastenheft mit Abnahmefällen, ergänzt um einen Prototyp oder ein gepflegtes Backlog, erfüllt den Zweck meist besser.
Wer schreibt das Lastenheft?
Der Auftraggeber, also das Unternehmen, das die Software braucht. Er kann sich dabei helfen lassen, etwa durch eine Beratung oder den späteren Dienstleister. Wichtig ist, dass die Fachbereiche mitschreiben, die den Ablauf täglich bearbeiten, nicht nur die IT oder die Geschäftsführung.
Was gehört in ein Lastenheft für Software?
Ausgangslage und Ziel, die beteiligten Rollen, die Abläufe mit typischen Fällen und Ausnahmen, die fachlichen Anforderungen mit Priorität, Anforderungen an Daten, Schnittstellen, Datenschutz und Betrieb, Rahmenbedingungen wie Termine und Budget sowie Abnahmekriterien. Lösungsvorgaben wie eine bestimmte Technik gehören nur hinein, wenn sie wirklich feststehen.
Gibt es ein Beispiel und eine Vorlage für ein Lastenheft?
Ja. Dieser Ratgeber zeigt eine Gliederung mit neun Abschnitten und ein konstruiertes Beispiel, wie eine Anforderung prüfbar formuliert wird. Die kostenlose Word-Vorlage enthält dieselbe Gliederung mit Tabellen für Rollen, Abläufe, Anforderungen und Abnahmefälle sowie je einer Beispielzeile, die Sie beim Ausfüllen löschen.
Braucht jedes Softwareprojekt ein Pflichtenheft?
Nein. Bei Ausschreibungen und großen Festpreisprojekten ist ein ausführliches Pflichtenheft üblich. Bei kleineren Vorhaben und neuen Produktideen genügt oft ein kurzes Lastenheft mit Abnahmefällen, ergänzt um einen Prototyp, an dem sich die Anforderungen prüfen lassen. Entscheidend ist, dass Umfang und Abnahme vor dem Build schriftlich feststehen.
Was ist eine Anforderungsanalyse?
Die Anforderungsanalyse ist der Teil des Requirements Engineering, in dem Anforderungen erhoben, geklärt, priorisiert und auf Widersprüche geprüft werden. Sie liefert die Inhalte für Lasten- und Pflichtenheft. Die internationale Norm ISO/IEC/IEEE 29148 beschreibt die zugehörigen Prozesse und die Eigenschaften guter Anforderungen.