# Lastenheft und Pflichtenheft: Unterschied und Vorlage > Lastenheft und Pflichtenheft für Software: der Unterschied, was hineingehört, ein Beispiel und eine kostenlose Word-Vorlage für den Mittelstand. - URL: https://newlifedigital.de/blog/lastenheft-pflichtenheft-anforderungsanalyse-software/ - Autor: Simon Maiwald (https://newlifedigital.de/team/simon-maiwald/) - Veröffentlicht: 2026-10-24 - Aktualisiert: 2026-10-25 **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](https://www.dinmedia.de/de/norm/din-69901-5/113428752) 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](https://www.vdi.de/richtlinien/details/vdi-2519-blatt-1-procedures-for-the-compilation-of-tender-and-performance-specifications) 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](https://www.iso.org/standard/72089.html) 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. 1. **Ausgangslage und Ziel:** Was läuft heute wie, was kostet es, und was soll sich ändern? 2. **Beteiligte und Rollen:** Wer arbeitet mit der Software, wer gibt frei, wer betreut sie? 3. **Abläufe:** Jeder wichtige Ablauf mit einem typischen Fall und den häufigsten Ausnahmen. 4. **Fachliche Anforderungen:** Was die Software können muss, jeweils mit Priorität (muss, soll, kann). 5. **Daten und Schnittstellen:** Welche Daten es heute gibt, wo sie liegen und welches System für welche Angabe führend ist. 6. **Datenschutz und Sicherheit:** Welche personenbezogenen Daten verarbeitet werden und wer worauf zugreifen darf. 7. **Betrieb:** Wo die Software laufen soll, wer sie aktualisiert und was bei einem Ausfall passiert. 8. **Rahmenbedingungen:** Termine, Budgetrahmen, Vorgaben der eigenen IT. 9. **Abnahmekriterien:** Fünf bis zehn konkrete Fälle, an denen Sie die fertige Software prüfen. Lastenheft-Vorlage als Word-Datei herunterladen 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](/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](/redaktionsgrundsaetze/) 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](/blog/individuelle-software-kosten-mittelstand-2026/) 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](/leistungen/mvp-entwicklung/), für bestehende Abläufe die Seite zur [individuellen Softwareentwicklung](/leistungen/individuelle-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](/lastenheft-check/) prüfen lassen.