Lastenheft für Software schreiben: Aufbau und die typischen Lücken

Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?

Die beiden Begriffe stammen aus dem Projektmanagement; die DIN 69901-5 legt fest, was darunter zu verstehen ist. Sinngemäß ist das Lastenheft dort die Gesamtheit der Forderungen, die der Auftraggeber an die Lieferungen und Leistungen des Auftragnehmers stellt. Das Pflichtenheft enthält die Vorgaben, die der Auftragnehmer daraus für die Umsetzung erarbeitet. Kurz gesagt: Das Lastenheft beschreibt, was gebraucht wird und wofür. Das Pflichtenheft ist die Antwort des Auftragnehmers — wie und womit er die Anforderungen umsetzen will.

Ein Vorgehen für beide Dokumente beschreibt die VDI-Richtlinie 2519 Blatt 1 (Ausgabe Dezember 2001). Sie wurde für Materialfluss- und Automatisierungssysteme geschrieben, die Arbeitsteilung ist in Softwareprojekten aber dieselbe: Der Betrieb kennt seine Abläufe, der Entwickler kennt die Technik. Keiner von beiden kann die Arbeit des anderen ersetzen.

In kleineren Projekten heißt das zweite Dokument oft anders — Fachkonzept, Spezifikation, Leistungsbeschreibung. Der Name ist zweitrangig. Entscheidend ist, dass am Ende ein Dokument steht, das beide Seiten gelesen und freigegeben haben und an dem sich die Abnahme messen lässt.

Wann lohnt sich ein Lastenheft, und wie ausführlich muss es sein?

Ein Lastenheft lohnt sich, sobald Sie mehr als ein Angebot einholen oder einen Festpreis wollen. Ohne schriftliche Anforderungen rechnet jeder Anbieter mit eigenen Annahmen, und die Angebote lassen sich nicht vergleichen. Welche Faktoren den Preis dann tatsächlich bestimmen, steht im Ratgeber Was kostet Individualsoftware?.

Der Umfang richtet sich nach dem Vorhaben, nicht nach einer Seitenzahl. Für ein abgegrenztes Werkzeug, das genau eine Aufgabe erledigt, genügen wenige Seiten. Eine Anwendung mit mehreren Rollen, Schnittstellen und Datenübernahme braucht deutlich mehr. Ein kurzes Lastenheft, das die schwierigen Fälle vollständig beschreibt, ist besser als ein langes, das nur den Normalfall ausführlich darstellt.

Auch wenn noch offen ist, ob es überhaupt eine Eigenentwicklung wird, ist das Lastenheft der richtige erste Schritt. Mit denselben Anforderungen prüfen Sie fertige Produkte. Wie Sie zwischen beiden Wegen abwägen, beschreibt der Ratgeber Individualsoftware oder Standardsoftware.

Wie ist ein Lastenheft aufgebaut? Gliederung als Vorlage

Die folgende Gliederung passt für die meisten Softwarevorhaben in kleinen und mittleren Betrieben. Zwei Begriffe darin brauchen eine Erklärung: Nicht-funktionale Anforderungen beschreiben nicht, was die Software tut, sondern wie gut — wie schnell, wie verfügbar, wie sicher. Das Mengengerüst sind die Zahlen, mit denen die Software umgehen muss: Datensätze, Vorgänge, Nutzer, Wachstum.

Das letzte Kapitel wird am häufigsten vergessen und erspart am meisten Streit. Was dort steht, muss niemand anbieten, niemand bauen und niemand testen. Und wenn es später doch gebraucht wird, ist klar, dass es eine Erweiterung ist und kein Mangel. Kapitel, die für Ihr Vorhaben keine Rolle spielen, dürfen Sie weglassen — aber bewusst, nicht aus Versehen.

Welche Lücken hat fast jedes Lastenheft?

Lücken in einem Lastenheft fallen selten beim Lesen auf, sondern erst, wenn die Software fast fertig ist. Dann sind sie teuer. Diese Punkte fehlen besonders oft:

• Sonderfälle: Beschrieben ist der Normalfall. Aber was passiert bei einer Gutschrift, einer Teillieferung, einem Kunden mit zwei Anschriften? Fragen Sie die Personen, die den Ablauf täglich machen, nach den Fällen, in denen sie heute improvisieren.
• Rechte und Vertretung: Wer darf Preise ändern, wer Rechnungen freigeben, wer Daten löschen? Und wer übernimmt, wenn diese Person im Urlaub ist?
• Datenmigration: Welche Altdaten übernommen werden, aus welchen Quellen, in welchem Zustand — und wer sie vorher bereinigt. Gewachsene Tabellen enthalten oft Dubletten und Freitext, wo Zahlen stehen sollten; mehr dazu im Ratgeber Excel als Firmensoftware.
• Mengengerüst: Ohne Zahlen zu Datensätzen, Nutzern und Wachstum kann niemand beurteilen, ob eine Lösung in drei Jahren noch trägt.
• Auswertungen: Welche Listen, Berichte und Exporte die Geschäftsführung oder die Steuerberatung braucht, wird oft erst nach dem Start gefragt.
• Betrieb und Wartung: Wer die Software betreibt, sichert und aktualisiert, wer bei einer Störung zuständig ist und was mit Quellcode und Dokumentation passiert, wenn die Zusammenarbeit endet.
• Umstellung: Wie der Wechsel vom alten auf das neue System laufen soll, mit Stichtag oder Parallelbetrieb. Die Möglichkeiten vergleicht der Ratgeber Legacy-Software ablösen.

Barrierefreiheit gehört ins Lastenheft, wenn Verbraucher über die Software Verträge abschließen können, etwa in einem Online-Shop oder einem Buchungsportal. Das Barrierefreiheitsstärkungsgesetz (BFSG) erfasst unter anderem Dienstleistungen im elektronischen Geschäftsverkehr, die nach dem 28. Juni 2025 für Verbraucher erbracht werden (§ 1 Abs. 3 BFSG). Gemeint sind Angebote auf Webseiten und in Apps, die auf den Abschluss eines Verbrauchervertrags zielen (§ 2 Nr. 26 BFSG). Kleinstunternehmen, die Dienstleistungen anbieten oder erbringen, sind nach § 3 Abs. 3 BFSG ausgenommen; das sind Unternehmen mit weniger als zehn Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz oder Jahresbilanzsumme (§ 2 Nr. 17 BFSG). Eine rein interne Anwendung, die nur Ihre Mitarbeitenden nutzen, richtet sich nicht an Verbraucher und dürfte deshalb nicht unter diese Pflichten fallen. Dieser Artikel ersetzt keine Rechtsberatung — ob das Gesetz in Ihrem Fall greift, klärt im Zweifel eine Rechtsanwältin oder ein Rechtsanwalt.

Wie formulieren Sie Anforderungen, die sich prüfen lassen?

Die Qualität eines Lastenhefts hängt weniger an der Gliederung als an den einzelnen Anforderungen. Drei Regeln helfen:

• Probleme beschreiben, nicht Lösungen: „Die Disposition muss auf einen Blick sehen, welche Aufträge heute noch offen sind“ ist eine Anforderung. „Wir brauchen eine Tabelle mit Ampelfarben“ ist eine Lösung — womöglich die, die Sie aus der alten Software kennen. Wer das Problem beschreibt, lässt dem Anbieter Raum für einen besseren Weg.
• Beispiele mitgeben: Ein echter, anonymisierter Vorgang mit allen Zahlen erklärt mehr als eine Seite Beschreibung. Legen Sie typische Belege, Listen und Ausdrucke bei, auch die unschönen.
• Nach Muss, Soll und Kann ordnen: Muss heißt, ohne diese Funktion ist die Software für Sie wertlos. Soll heißt, wichtig, aber notfalls in einer zweiten Stufe. Kann heißt, wünschenswert, wenn es wenig kostet.

Jede Anforderung sollte so formuliert sein, dass sich am Ende mit Ja oder Nein beantworten lässt, ob sie erfüllt ist. Das ist die Brücke zu den Abnahmekriterien: Aus einer prüfbaren Anforderung wird fast von selbst ein Testfall. Die Zahlen in den Beispielen sind Platzhalter — setzen Sie die Werte ein, die für Ihren Betrieb gelten.

Wie gehen Sie beim Schreiben vor?

1. 01

   Verantwortliche Person bestimmen

   Eine Person im Betrieb hält das Dokument zusammen und entscheidet bei Widersprüchen. Ohne diese Rolle wird das Lastenheft zur Sammlung von Einzelwünschen.

2. 02

   Abläufe mit den Beteiligten aufnehmen

   Sprechen Sie mit den Personen, die den Ablauf täglich machen, nicht nur mit der Leitung. Der beschriebene und der tatsächliche Ablauf unterscheiden sich fast immer.

3. 03

   Anforderungen sammeln und ordnen

   Jede Anforderung bekommt eine Nummer, eine Priorität und, wo möglich, ein Beispiel. Doppelte und widersprüchliche Wünsche fallen beim Ordnen auf.

4. 04

   Mengengerüst und Rahmenbedingungen ergänzen

   Zahlen zu Datensätzen, Nutzern und Wachstum, dazu Vorgaben zu Datenschutz, Hosting und Aufbewahrung. Oft hilft ein Blick in die vorhandenen Systeme, um die Zahlen zu ermitteln.

5. 05

   Abnahmekriterien festlegen

   Für jede Muss-Anforderung mindestens ein Testfall: Ausgangssituation, Handlung, erwartetes Ergebnis.

6. 06

   Gegenlesen lassen

   Lassen Sie das Dokument von jemandem lesen, der nicht beteiligt war. Jede Rückfrage zeigt eine Stelle, an der ein Anbieter raten müsste.

Rechnen Sie damit, dass gute Anbieter Rückfragen stellen. Rückfragen sind kein Zeichen für ein schlechtes Lastenheft, sondern dafür, dass jemand es gründlich gelesen hat. Ein Festpreisangebot ohne eine einzige Rückfrage verdient eher Misstrauen.

Was passiert, wenn das Lastenheft fertig ist?

Mit dem Lastenheft holen Sie Angebote ein. Vergleichen Sie nicht nur den Preis, sondern auch, was jeder Anbieter aus Ihren Anforderungen gemacht hat: Welche Punkte fragt er nach, welche lässt er stillschweigend weg, welche Annahmen trifft er? Zwei Angebote mit ähnlichem Preis können sehr unterschiedliche Leistungen beschreiben.

Nach der Vergabe entsteht aus dem Lastenheft das Pflichtenheft oder Fachkonzept. Lesen Sie es gründlich und geben Sie es erst frei, wenn Sie Ihre Abläufe darin wiedererkennen. Was dort nicht steht, wird in der Regel nicht gebaut — und was dort falsch steht, wird falsch gebaut.

Rechnen Sie damit, dass sich Anforderungen im Projekt noch ändern, weil viele erst sichtbar werden, wenn man die Software ausprobiert. Wer Individualsoftware entwickeln lässt, sollte deshalb auf lauffähige Zwischenstände in kurzen Abständen achten. Dann fällt eine falsche Annahme nach wenigen Wochen auf und nicht erst bei der Abnahme.