Lastenheft Vorlage Software: Word & PDF mit Beispiel

Ein Lastenheft ist das Dokument, in dem du als Auftraggeber festhältst, was ein Softwaresystem leisten soll und unter welchen Bedingungen. Das Kit unten enthält einen Anforderungsfragebogen, eine Kapitelgliederung mit Beispielsätzen, Formulierungsmuster für testbare Anforderungen und eine Checkliste vor dem Versand, als ausfüllbare Word-Datei und als PDF zum Ausdrucken.

Ich habe das Kit so gebaut, dass du mit dem Fragebogen anfängst. Die Grundlage sind die Fragen, die wir im Erstgespräch mit Auftraggebern stellen, übersetzt in deine Perspektive. Oft reicht der ausgefüllte Fragebogen schon als Basis für ein Gespräch mit einem Anbieter. Brauchst du mehr, folgt die Gliederung für ein ausführlicheres Lastenheft. Die Beispielsätze in der Datei und in diesem Artikel laufen alle als Reklamationsverwaltung eines Handelsbetriebs durch. Das Beispiel ist frei erfunden.

Das Kit besteht aus vier Teilen und hat als PDF 12 Seiten:

• Teil 1, Anforderungsfragebogen: elf Abschnitte von Ziel und Anlass bis Abnahmekriterien, mit Feldern für Rollen, Muss-, Soll- und Kann-Funktionen, Schnittstellen, Datenschutz, Betrieb, Termin, Budgetrahmen (bewusst leer) und Entscheidungsweg.
• Teil 2, Lastenheft-Gliederung: Dokumentkopf und zwölf Kapitel, jeweils mit einem Beispielsatz zum Anpassen.
• Teil 3, Anforderungen formulieren: Satzschablone, ID-Schema, Änderungsprotokoll und sechs Beispiele von vage zu testbar.
• Teil 4, Checkliste: was vor dem Versand geprüft sein sollte und was im Angebot stehen sollte.

Was ist ein Lastenheft in der Softwareentwicklung?

Ein Lastenheft beschreibt aus Sicht des Auftraggebers, was ein Softwaresystem können soll und welche Rahmenbedingungen gelten, ohne festzulegen, wie es technisch umgesetzt wird. Es beantwortet die Fragen was, wofür und für wen.

Die Norm DIN 69901-5 (Projektmanagement, Begriffe, Ausgabe Januar 2009, laut DIN Media aktuell gültig) versteht das Lastenheft als die vom Auftraggeber festgelegte Gesamtheit der Forderungen an Lieferungen und Leistungen eines Auftragnehmers. So gibt es auch Wikipedia wieder, denn der Normtext selbst ist kostenpflichtig. Eine DIN-Norm gilt nach Einschätzung der Wissenschaftlichen Dienste des Bundestags als private technische Regel mit Empfehlungscharakter und ist keine Rechtsnorm. Du musst also weder das Wort Lastenheft verwenden noch eine feste Gliederung einhalten, damit das Dokument seinen Zweck erfüllt. Stand: 30. September 2026.

International sind die Begriffe unüblich. Das Johner Institut rät in einem Fachartikel, auf Lastenheft und Pflichtenheft zu verzichten, weil sie sich außerhalb des deutschen Sprachgebiets nicht durchgesetzt hätten, und kritisiert, dass die meisten Hefte Stakeholder-, System- und Projektanforderungen vermischen. Schreibst du mit einem internationalen Team, sagst du besser Requirements Specification. Wie einzelne Anforderungen als Text formuliert sein sollten, behandelt die Norm ISO/IEC/IEEE 29148 (Requirements Engineering, Ausgabe 2018).

Anforderungskatalog und Lastenheft: ist das dasselbe?

Der Anforderungskatalog ist die Liste aller Anforderungen und damit der Kern des Lastenhefts. Das Lastenheft ergänzt ihn um Ziel, Ausgangslage, Rollen und Rahmenbedingungen. Wenn ein Anbieter dich nach einem Anforderungskatalog fragt, reicht Abschnitt D des Fragebogens (Funktionen mit Priorität) als Grundlage.

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Das Lastenheft schreibt der Auftraggeber und beschreibt, was gebraucht wird und wofür. Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf und beschreibt, wie er die Anforderungen umsetzt. Eine Eselsbrücke: Die Last trägt, wer etwas will, die Pflicht hat, wer liefert.

Bei MVP-Projekten läuft es so: Das Pflichtenheft erarbeiten wir im Discovery-Sprint gemeinsam mit dir, wie auf der Seite zur MVP-Entwicklung beschrieben, typischerweise in 5 bis 10 Werktagen. Am Ende stehen Scope, Architektur, Wireframes und ein Festpreis. Du musst dafür kein fertiges Lastenheft mitbringen. Ein ausgefüllter Fragebogen gibt dem Gespräch aber eine Grundlage.

Pflichtenheft Vorlage: musst du das selbst schreiben?

Normalerweise nein. Das Pflichtenheft gehört zum Auftragnehmer, du prüfst es. Drei Fragen genügen für den ersten Check: Kommt jede deiner Anforderungs-IDs darin vor? Sind Abweichungen begründet? Gibt es zu jeder Muss-Anforderung ein Abnahmekriterium? Wenn du selbst eine Ausschreibung mit vorgegebener Struktur schreiben willst, übernimmst du die Kapitel aus Teil 2 des Kits.

Wann brauchst du ein Lastenheft und wann reicht ein Anforderungsgespräch?

Ein ausführliches Lastenheft lohnt sich, wenn mehrere Anbieter vergleichbare Angebote abgeben sollen, mehrere Abteilungen mitreden oder das System für den Betrieb kritisch wird. Bei einem kleinen, klar umrissenen Projekt reichen ein ausgefüllter Fragebogen und ein Gespräch.

Zwei Projekte von uns zeigen, wie stark Anforderungen am gelebten Ablauf hängen. Bei der Buchungsplattform für einen Eisenbahninfrastruktur-Betreiber lief die Verwaltung von Werkstattgleisen, Abstellgleisen und Geräten vorher über Outlook-Kalender, E-Mail-Bestätigungen und eine Tabelle. Überbuchungen ließen sich nur durch manuelle Kontrolle vermeiden. Die Anforderungen ergaben sich aus diesem Ablauf. Für eine Handwerker-Software in der Schweiz haben wir den Ablauf aus Angebot, Rapport und QR-Rechnung als ein System gebaut. Es ist mit 143+ Funktionen in Produktion.

Hast du eine Produktidee und noch keinen Markttest, ist ein dickes Lastenheft eher hinderlich. Wie du den Umfang für ein erstes Produkt schneidest, steht im MVP-Leitfaden, warum zu große Startumfänge scheitern, in Warum MVPs scheitern.

Ist ein Lastenheft noch zeitgemäß?

Ja, als kurzes Dokument, das mit dem Projekt mitwächst. Als umfangreiche Festschreibung aller Details vor Projektbeginn passt es schlecht zu Projekten, die in kurzen Etappen entstehen.

Das Manifest für Agile Softwareentwicklung stellt Funktionierende Software mehr als umfassende Dokumentation, betont aber ausdrücklich, dass die Dinge auf der rechten Seite ebenfalls wichtig sind. Für dich heißt das: Schreibe so viel auf, wie nötig ist, damit Dritte kalkulieren und du später abnehmen kannst. Für den ersten Bauabschnitt und für ein Festpreisangebot bleibt eine klare, testbare Anforderungsliste sinnvoll. Was später dazukommt, trägst du im Änderungsprotokoll nach, mit Datum und ID. Wer in Etappen baut, kann Kernabläufe auch als User Story formulieren. Das Muster steht in Teil 3 des Kits.

Was gehört in ein Lastenheft für Software?

In ein Lastenheft für Software gehören ein Dokumentkopf und zwölf Kapitel, von Ziel und Rollen über die Anforderungen bis zu Betrieb und Abnahme. Die folgende Tabelle zeigt, welche Frage jedes Kapitel beantwortet.

Das Kit hat zu jedem dieser Kapitel einen Beispielsatz, den du auf dein Projekt umschreibst.

Wie erstellst du ein Lastenheft in sieben Schritten?

Du erstellst ein Lastenheft, indem du zuerst Ziel und Rollen klärst, dann den Ist-Ablauf aufschreibst und erst danach Anforderungen sammelst und testbar formulierst. Die Reihenfolge verhindert, dass du Funktionen beschreibst, bevor klar ist, wofür sie da sind.

1. Ziel in einem Satz und ein Erfolgsmaß festlegen. Zum Beispiel: Jede Reklamation wird genau einmal erfasst, und der Bearbeitungsstand ist für alle sichtbar. Ohne Erfolgsmaß bleibt später offen, ob das Projekt geklappt hat.
2. Rollen sammeln. Sprich pro Rolle mit mindestens einer Person, die sie täglich ausübt, nicht nur mit deren Vorgesetzten.
3. Den Ist-Ablauf aufschreiben. Ein Durchlauf von Anfang bis Ende, mit den Systemen, die dabei angefasst werden. Hänge anonymisierte Beispiele an, etwa die Excel-Datei mit geschwärzten Namen.
4. Anforderungen sammeln und sortieren. Eine Runde pro Rolle, danach Muss, Soll, Kann. Was im ersten Release fehlen darf, gehört auf Kann.
5. Jede Anforderung testbar formulieren. Rolle, Tätigkeit, Objekt, Grenzwert und Prüfschritt. Das Muster steht weiter unten.
6. Schnittstellen, Datenschutz, Betrieb und Termin ergänzen. Das sind die Kapitel, die in Entwürfen am häufigsten fehlen. Bei personenbezogenen Daten klärst du früh mit der für den Datenschutz zuständigen Person, welche Vorgaben gelten.
7. Abgrenzung, offene Fragen und Checkliste. Danach schickst du allen Anbietern dasselbe Dokument mit derselben Frist für Rückfragen.

Wie formulierst du eine Anforderung so, dass sie testbar ist?

Eine testbare Anforderung nennt eine Rolle, eine Tätigkeit, ein Objekt und ein prüfbares Ergebnis oder einen Grenzwert. Die Kontrollfrage lautet: Könnte jemand ohne Kenntnis des Projekts ohne Rückfrage einen Test dafür schreiben?

Die Schablone aus dem Kit: [ID] [Rolle] kann [Tätigkeit] [Objekt] [Bedingung oder Grenzwert]. Priorität: Muss, Soll oder Kann. Abnahme: [Prüfschritt und erwartetes Ergebnis].

Die IDs bekommen ein Präfix: F für Funktion, Q für Qualität, S für Schnittstelle, D für Daten und Datenschutz, B für Betrieb. Jede ID vergibst du einmal und änderst sie nie. Gestrichene Anforderungen bleiben mit dem Vermerk entfallen stehen, damit sich Angebot, Rückfragen und Abnahme immer auf dieselbe Zeile beziehen.

So wird aus einer vagen Formulierung eine prüfbare:

Wörter wie schnell, einfach, flexibel, intuitiv, modern oder benutzerfreundlich sind ein Signal zum Nachfragen. Ersetze sie durch Zahlen, Beispiele oder Prüfschritte. Setze die Priorität konsequent: Wenn fast alles Muss ist, ist nichts priorisiert.

Wie sieht ein Lastenheft-Beispiel für Software aus?

Das folgende Beispiel ist frei erfunden. Es zeigt die Tiefe, die für ein internes Tool mit wenigen Rollen ausreicht, und lehnt sich eng an die Beispiele im Kit an.

Ausgangslage und Ziel. Wir sind ein Handelsbetrieb mit zwölf Mitarbeitenden. Reklamationen kommen per E-Mail und Telefon an und werden in einer Excel-Datei gepflegt. Regelmäßig bearbeiten zwei Personen dieselbe Reklamation. Ziel ist ein System, in dem jede Reklamation genau einmal erfasst wird und der Bearbeitungsstand für alle sichtbar ist.

Rollen.

Anforderungen.

Abgrenzung. Nicht Teil des Projekts sind die Warenwirtschaft, die Buchhaltung und ein Kundenportal.

Offene Frage O-01. Sollen Fotos im System gespeichert oder nur verlinkt werden? Verantwortlich: Teamleitung, Klärung bis 15.11.

Abnahme. Pro Meilenstein. Die Teamleitung prüft mit zehn anonymisierten Reklamationen aus dem Vorjahr. Ein Meilenstein ist abgenommen, wenn alle Muss-Anforderungen bestanden sind und kein blockierender Fehler offen ist.

Im Beispiel hat jede Zeile einen Prüfschritt: F-02 lässt sich mit zehn Testdatensätzen abhaken, und die offene Frage steht offen da, statt geraten zu werden. Ein Anbieter kann aus F-01 bis F-03 den Aufwand für den Kern abschätzen und weiß bei S-01 und B-01, wo Abstimmung mit deiner IT nötig ist.

Wie wird aus dem Lastenheft ein Festpreisangebot?

Ein Festpreis ist nur so belastbar wie der Umfang, auf den er sich bezieht. Das Lastenheft beschreibt diesen Umfang, das Angebot bezieht sich darauf. Ohne beschriebenen Umfang und Abnahmekriterien bleibt einem Anbieter nur, Puffer einzurechnen oder später über Änderungen zu verhandeln.

Bei alloq.digital läuft der Weg vom Dokument zum Angebot in vier Schritten:

1. Projekt anfragen. Du schickst Kontext, Ziele, Budgetrahmen und Zeitplan. Der ausgefüllte Fragebogen ersetzt dabei viele Rückfragen.
2. Erstgespräch. Wir klären Idee, Ist-Situation, Geschäftsziel und technische Komplexität. Mit dem Fragebogen sind die Grundfragen beantwortet, das Gespräch geht direkt in die Tiefe.
3. Technische Einschätzung. Du bekommst einen Überblick, was möglich ist, was zuerst gebaut werden sollte und wo die Risiken liegen.
4. Angebot. Es enthält Umfang, Zeitplan, Investition, Zahlungsstruktur und die nächsten Schritte, zum Festpreis statt nach Stundensatz.

Nenne einen Budgetrahmen, wenn du einen hast. Er hilft, den ersten Bauabschnitt so zu schneiden, dass er hineinpasst. Prüfe bei jedem Angebot, von wem auch immer, ob es sich auf deine Anforderungen bezieht: Umfang je ID, ausdrückliche Annahmen, Zeitplan mit Meilensteinen, Regel für Änderungswünsche, Betrieb nach dem Launch und Übergabe von Quellcode, Zugängen und Dokumentation. Die Liste steht als Checkliste in Teil 4 des Kits. Wie Kosten und Ablauf im Ganzen aussehen, erklärt der Ratgeber Software entwickeln lassen.

Ist ein Lastenheft rechtlich verbindlich?

Als Arbeitsdokument ist ein Lastenheft für sich genommen kein Vertrag. Welche Wirkung es hat, hängt davon ab, ob und wie du es mit dem Anbieter im Vertrag oder Angebot vereinbarst.

Bei einem Werkvertrag nach deutschem Recht ist das Werk nach § 633 Abs. 2 Satz 1 BGB frei von Sachmängeln, wenn es die vereinbarte Beschaffenheit hat. Ein Lastenheft oder Pflichtenheft, das ausdrücklich als Anlage vereinbart wird, kann diese Beschaffenheit und damit den Maßstab für die Abnahme festlegen. Ob dein Projekt rechtlich ein Werkvertrag ist, hängt vom Vertrag im Einzelfall ab. Für Österreich und die Schweiz gelten eigene Regeln. Stand: 30. September 2026. Das ist eine allgemeine Orientierung und keine Rechtsberatung, lass den Vertrag rechtlich prüfen.

Welche Fehler solltest du im Lastenheft vermeiden?

Die häufigsten Fehler entstehen, wenn das Dokument zu früh Technik festlegt, zu vage bleibt oder den Betrieb ausklammert.

• Die Umsetzung vorwegnehmen. „Wir brauchen eine App mit Push-Nachrichten“ sagt weniger als „Die Teamleitung erfährt innerhalb von zehn Minuten von einer neuen Reklamation.“ Mit dem zweiten Satz kann der Anbieter die passende Technik wählen.
• Alles zum Muss machen. Dann gibt es keinen kleinsten sinnvollen ersten Bauabschnitt, und jede Kürzung wird zum Streit.
• Vage Adjektive stehen lassen. Schnell und einfach heißen für jede Person etwas anderes.
• Den Ist-Zustand weglassen. Ohne den heutigen Ablauf rät der Anbieter. Ein anonymisiertes Beispieldokument erklärt oft mehr als eine Seite Text.
• Schnittstellen vergessen. Daten liegen fast immer in Altsystemen. Eine Schnittstelle, die erst im Projekt auftaucht, verändert Aufwand und Termin.
• Den Betrieb nach dem Launch ausklammern. Software läuft weiter, wenn das Projekt endet. Schreibe auf, wer bei einer Störung erreichbar sein muss, wie schnell du eine Reaktion brauchst und wer den Quellcode besitzt.
• Keine Entscheidungsperson nennen. Ein Dokument ohne benannte Entscheidungsperson bleibt hängen, sobald zwei Abteilungen unterschiedlicher Meinung sind.
• Es einmal schreiben und ablegen. Änderungen kommen mit Datum und ID ins Änderungsprotokoll.

Nächster Schritt: technische Einschätzung

Hast du den Fragebogen ausgefüllt und möchtest wissen, was davon in welcher Reihenfolge gebaut werden sollte, melde dich über die Kontaktseite. Wir schauen uns das Projekt an, geben dir eine technische Einschätzung und zeigen, wie der erste sinnvolle Bauabschnitt aussieht. Weitere kostenlose Vorlagen und Rechner findest du in der Übersicht der Tools.

Häufige Fragen zum Lastenheft für Software

Wer erstellt ein Lastenheft?

Ein Lastenheft erstellt der Auftraggeber, also die Person oder das Unternehmen, die Software beauftragen wollen. Fachlich ist es ein Gemeinschaftsprodukt: Die Fachabteilung liefert Abläufe und Anforderungen, die Geschäftsführung Ziel und Budgetrahmen, die IT Schnittstellen und Betriebsvorgaben. Ein Anbieter kann beim Formulieren helfen, das Dokument bleibt aber die Beschreibung dessen, was du brauchst.

Was gehört alles in ein Lastenheft?

In ein Lastenheft für Software gehören Ausgangslage und Ziel, Umfang und Abgrenzung, Nutzerrollen, der heutige Ablauf, die Anforderungen mit Priorität, Schnittstellen und Daten, Qualitätsanforderungen wie Antwortzeiten, Datenschutz und Hosting, Termine und Budgetrahmen, Betrieb und Übergabe sowie Abnahmekriterien. Ein Anhang mit Glossar, anonymisierten Beispielen und offenen Fragen rundet das Dokument ab.

Wie formuliert man ein Lastenheft?

Formuliere jede Anforderung als einen Satz mit Rolle, Tätigkeit, Objekt und einem prüfbaren Ergebnis, zum Beispiel: Die Teamleitung kann eine Gutschrift freigeben, die Sachbearbeitung kann sie nicht freigeben. Gib jeder Anforderung eine feste ID und eine Priorität. Ersetze Wörter wie schnell oder einfach durch Zahlen oder Prüfschritte. Prüfe, ob jemand ohne Kenntnis des Projekts ohne Rückfrage einen Test dafür schreiben könnte.

Ist ein Lastenheft noch zeitgemäß?

Ja, wenn du es als kurzes Dokument behandelst, das mit dem Projekt mitwächst. Ein umfangreiches Lastenheft, das alle Details vor Projektbeginn festschreibt, passt schlecht zu Projekten, die in kurzen Etappen entstehen. Für den ersten Bauabschnitt und für Festpreisangebote bleibt eine klare, testbare Anforderungsliste sinnvoll. Was später dazukommt, trägst du im Änderungsprotokoll nach.

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Das Lastenheft schreibt der Auftraggeber und beschreibt, was gebraucht wird und wofür. Das Pflichtenheft schreibt der Auftragnehmer als Antwort darauf und beschreibt, wie er die Anforderungen umsetzt, mit Architektur, Schnittstellen und Abnahmekriterien. Das Lastenheft dient als Grundlage für Angebote, das Pflichtenheft ist oft die detaillierte Arbeitsgrundlage und Anlage zum Vertrag.

Wer schreibt ein Pflichtenheft?

Ein Pflichtenheft schreibt der Auftragnehmer, also der Anbieter oder das Entwicklungsteam, auf Basis des Lastenhefts. Es konkretisiert, wie jede Anforderung technisch umgesetzt wird. Du als Auftraggeber prüfst es: Kommt jede deiner Anforderungen vor, sind Abweichungen begründet und gibt es zu jeder Muss-Anforderung ein Abnahmekriterium? Erst danach solltest du es freigeben.

Wie lang sollte ein Lastenheft sein?

So lang, dass Dritte ohne Rückfrage kalkulieren und du später abnehmen kannst, und keine Seite länger. Die Länge hängt an der Zahl der Rollen, Abläufe und Schnittstellen, nicht an einer festen Vorgabe. Bei einem kleinen internen Tool reichen oft wenige Seiten, bei einer Plattform mit vielen Funktionen legst du die Details je Bauabschnitt fest.

Ist die Lastenheft-Vorlage wirklich kostenlos?

Ja. Du trägst deine E-Mail-Adresse ein, bestätigst sie per Link, und danach lädst du Word-Datei und PDF sofort herunter. Der Link kommt zusätzlich per Mail. Der Download kostet nichts und ist an keine Bestellung gebunden. Danach bekommst du gelegentlich Tipps von alloq.digital zu digitalen Abläufen, jederzeit abmeldbar.