# Lastenheft Software: Vorlage mit Gliederung und Beispielen

> Ein Lastenheft für Software beschreibt aus Sicht des Auftraggebers, was die Software leisten soll, nicht wie sie gebaut wird. Eine brauchbare Vorlage enthält Ausgangslage, Ziele, Nutzergruppen, funktionale und nicht-funktionale Anforderungen, Schnittstellen, Rahmenbedingungen, Abnahmekriterien und eine Abgrenzung dessen, was nicht dazugehört. Der Auftragnehmer antwortet darauf mit dem Pflichtenheft.

- URL: https://go-projects.de/projektplanung/lastenheft-software-vorlage/
- Sprache: de
- Aktualisiert: 2026-10-19
- Herausgeber: Go Projects (OnlineBuilders LLC, https://onlinebuilders.biz)

Ein Lastenheft wird selten zu kurz geschrieben. Es wird zu unpräzise geschrieben. Sätze wie „Das System soll benutzerfreundlich und performant sein“ stehen in vielen Anforderungsdokumenten, und keiner davon lässt sich prüfen. Genau das wird teuer, wenn am Projektende gestritten wird, ob die Software fertig ist.

Die Norm DIN 69901-5 definiert das Lastenheft als die vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers. Kurz: Was soll die Software können, und unter welchen Bedingungen? Das Wie bleibt offen. Das ist Sache des Pflichtenhefts.

## Lastenheft oder Pflichtenheft: wer schreibt was?

Die Verwechslung ist so alt wie die Begriffe. In der Praxis wird „Pflichtenheft“ oft für beides benutzt, selbst in Verträgen. Die Normlogik ist aber klar:

**Lastenheft und Pflichtenheft nach DIN 69901-5**

| | Lastenheft | Pflichtenheft |
|---|---|---|
| Verfasser | Auftraggeber | Auftragnehmer |
| Kernfrage | Was und wofür? | Wie und womit? |
| Lösungsneutral | ja | nein |
| Enthält Architektur, Technologien | nein | ja |
| Zeitpunkt | vor der Ausschreibung | nach Auftragsklärung |
| Grundlage für Angebote | ja | teilweise |

International entspricht dem Ganzen am ehesten die Norm ISO/IEC/IEEE 29148, die Anforderungsdokumente im Software Engineering beschreibt. Für ein mittelständisches Projekt musst du keine Norm zitieren. Es hilft aber, die Trennung einzuhalten: Wer im Lastenheft schon „mit React und PostgreSQL“ schreibt, nimmt dem Dienstleister die Chance, eine günstigere Lösung vorzuschlagen.

## Vorlage: Gliederung für ein Software-Lastenheft

Diese Gliederung funktioniert für Fachanwendungen und Portale, auch für interne Tools. Kopier sie in dein Dokument und streich, was nicht passt.

1. **Ausgangslage.** Wie läuft der Prozess heute? Welche Systeme, wie viele Nutzer, welche Probleme mit Zahlen („Rechnungsfreigabe dauert im Schnitt 9 Tage“).
2. **Ziele.** Zwei bis vier messbare Ziele mit Datum. Dazu ein Satz, was ausdrücklich kein Ziel ist.
3. **Nutzergruppen und Rollen.** Wer arbeitet mit der Software, wie oft, auf welchem Gerät, mit welchen Rechten?
4. **Funktionale Anforderungen.** Nummeriert, je Anforderung ein Satz plus Akzeptanzkriterium. Gruppiert nach Prozessschritten.
5. **Nicht-funktionale Anforderungen.** Antwortzeiten, Verfügbarkeit, gleichzeitige Nutzer, Barrierefreiheit, Sprachen, unterstützte Browser und Geräte.
6. **Daten und Schnittstellen.** Welche Daten werden übernommen? Welche Systeme sind anzubinden, mit welcher Dokumentation?
7. **Sicherheit und Datenschutz.** Personenbezogene Daten, Rollenmodell, Hosting-Standort, Löschfristen.
8. **Rahmenbedingungen.** Budgetrahmen, Termine, vorhandene Infrastruktur, Vorgaben der IT.
9. **Abnahmekriterien.** Wie wird geprüft, wer prüft, mit welchen Testdaten?
10. **Abgrenzung.** Was gehört nicht zum Auftrag, auch wenn man es vermuten könnte?
11. **Offene Punkte.** Ehrlich auflisten, was noch nicht entschieden ist.

Punkt 10 und 11 fehlen in den meisten Vorlagen, die man im Netz findet. Sie verhindern mehr Streit als alle anderen zusammen.

## Musterformulierungen: unprüfbar gegen prüfbar

Der Unterschied zwischen einem nützlichen und einem nutzlosen Lastenheft liegt in den Sätzen. Jede Anforderung sollte so formuliert sein, dass ein Tester sie mit Ja oder Nein abhaken kann.

| Unprüfbar | Prüfbar |
|---|---|
| Das System soll schnell sein. | Die Suche liefert bei 50.000 Datensätzen Ergebnisse in unter 2 Sekunden (95. Perzentil). |
| Das System soll benutzerfreundlich sein. | Eine neue Sachbearbeiterin legt nach 30 Minuten Einweisung einen Vorgang ohne Hilfe an. |
| Export in gängige Formate. | Export der Trefferliste als CSV (UTF-8, Semikolon) und XLSX. |
| Hohe Verfügbarkeit. | Verfügbarkeit 99,5 % pro Monat, Wartungsfenster sonntags 22 bis 2 Uhr ausgenommen. |
| Rollen und Rechte. | Drei Rollen: Erfasser, Prüfer, Admin. Nur Prüfer dürfen freigeben. |

Ein hilfreiches Muster für funktionale Anforderungen ist die Satzschablone: „Das System muss [wer] die Möglichkeit bieten, [Objekt] zu [Prozesswort], wenn [Bedingung].“ Sie klingt steif. Sie zwingt aber dazu, Akteur und Gegenstand samt Bedingung zu benennen.

Wer lieber mit Nutzersicht arbeitet, formuliert dieselbe Anforderung als User Story mit Akzeptanzkriterien. Wie das sauber geht, steht im Beitrag [User Stories schreiben](https://go-projects.de/projektplanung/user-stories-schreiben/).

## Warum das Lastenheft vor Gericht zählt

Ein Softwareprojekt mit festem Ergebnis ist in Deutschland meist ein Werkvertrag. Nach [§ 633 BGB](https://www.gesetze-im-internet.de/bgb/__633.html) ist ein Werk frei von Sachmängeln, wenn es die vereinbarte Beschaffenheit hat. Was vereinbart ist, steht im Idealfall im Lastenheft beziehungsweise im Pflichtenheft, das Vertragsbestandteil wird.

Das hat zwei Folgen. Erstens: Was nicht drinsteht, ist schwer einzufordern. Zweitens: Was unklar drinsteht, wird im Streitfall ausgelegt, und zwar nicht unbedingt zu deinen Gunsten. Die Abnahme nach § 640 BGB hängt an derselben Frage. Wie man sie sauber dokumentiert, erklärt der Beitrag zum [Abnahmeprotokoll für Software](https://go-projects.de/projektsteuerung/abnahme-software-abnahmeprotokoll/).

Ein kurzer Hinweis noch: Bei größeren Summen lohnt es sich, den Vertrag samt Leistungsbeschreibung einmal von einer Anwältin mit IT-Schwerpunkt lesen zu lassen.

## Die fünf teuersten Fehler im Lastenheft

### Lösungen statt Anforderungen

„Ein Dropdown mit allen Kunden“ ist eine Lösung. Die Anforderung lautet: „Die Sachbearbeiterin findet einen Kunden aus 12.000 Einträgen in unter zehn Sekunden.“ Vielleicht ist eine Suche mit Autovervollständigung die bessere Antwort.

### Nicht-funktionale Anforderungen fehlen

Wie viele Nutzer gleichzeitig? Welche Browser? Wer das nicht festlegt, bekommt eine Anwendung, die beim Testen mit drei Personen gut läuft und am Montagmorgen mit 200 zusammenbricht.

### Altdaten werden vergessen

Die Migration von Daten aus einem Altsystem kann einen erheblichen Teil des Aufwands ausmachen. Steht sie nicht im Lastenheft, steht sie auch in keinem Angebot.

### Alles ist gleich wichtig

Ohne Priorität wird alles gebaut oder gar nichts. Kennzeichne jede Anforderung mit Muss, Soll oder Kann, wie im Beitrag zur [MoSCoW-Priorisierung](https://go-projects.de/projektplanung/moscow-priorisierung/) beschrieben.

### Die Fachseite schreibt nicht mit

Wenn die IT das Lastenheft allein verfasst, beschreibt es, wie die IT sich den Prozess vorstellt. Die Leute, die täglich damit arbeiten, merken die Lücken erst bei der Abnahme.

## Wie viel Lastenheft braucht ein kleines Projekt?

Für eine Web-Anwendung mit einem Budget von 30.000 bis 80.000 Euro reicht oft ein Dokument von zehn bis fünfzehn Seiten. Wichtiger als der Umfang ist, dass Ziele und Abgrenzung drinstehen, dazu die Abnahmekriterien. Den Rest kann man im Projekt verfeinern, wenn die Zusammenarbeit agil angelegt ist.

Ein Lastenheft ist auch die beste Grundlage für eine ehrliche Kostenschätzung. Ohne liefert jeder Anbieter eine Zahl für ein anderes Projekt, und die Angebote sind nicht vergleichbar. Was realistische Preise sind, steht im Beitrag [Was kostet es, Software entwickeln zu lassen?](https://go-projects.de/schaetzung-und-budget/software-entwickeln-lassen-kosten/).

Wer das Lastenheft gemeinsam mit einem Entwicklungspartner erarbeiten möchte, findet bei einem Studio für [individuelle Softwareentwicklung wie OnlineBuilders](https://onlinebuilders.biz/solutions/software-development) eine kostenlose technische Erstberatung, in der sich vor allem Schnittstellen und nicht-funktionale Anforderungen gut klären lassen.

Nächster Schritt: Nimm die Gliederung oben, füll zuerst nur die Punkte 2, 10 und 11 aus und zeig sie zwei Leuten aus der Fachabteilung. Ihre Rückfragen sind dein Inhaltsverzeichnis für den Rest.

## Häufige Fragen

### Wer schreibt das Lastenheft, wer das Pflichtenheft?

Das Lastenheft schreibt der Auftraggeber, also das Unternehmen, das die Software haben will. Das Pflichtenheft erstellt der Auftragnehmer als Antwort darauf und beschreibt, wie er die Anforderungen umsetzt. Oft hilft der Dienstleister schon beim Lastenheft, das sollte dann aber bezahlt und offen benannt sein.

### Wie lang sollte ein Lastenheft sein?

So kurz wie möglich, so lang wie nötig. Für eine Fachanwendung mittlerer Größe sind 10 bis 30 Seiten realistisch. Ein 100-seitiges Dokument liest niemand vollständig, und dann ist es als Vertragsgrundlage wertlos.

### Ist ein Lastenheft rechtlich bindend?

Für sich allein nicht. Wird es aber Bestandteil des Vertrags, beschreibt es die vereinbarte Beschaffenheit des Werks. Daran misst sich nach § 633 BGB, ob ein Mangel vorliegt, und nach § 640 BGB, ob abgenommen werden muss.

### Brauche ich ein Lastenheft, wenn wir agil arbeiten?

Ein schlankes schon. Ziele, Nutzergruppen, Rahmenbedingungen und nicht-funktionale Anforderungen ändern sich selten und gehören schriftlich fixiert. Die Detailfunktionen wandern dann als User Stories ins Backlog.

Foto: Jules Bilmeyer Joseph Van Riel, CC0 (https://commons.wikimedia.org/wiki/File:Architectural_drawing_from_the_Engetrim_archive,_ref._obj-0000187.jpg)