Was ist ein Lastenheft?

Ein Lastenheft (englisch: Requirements Specification) ist gemäß DIN 69901-5 die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrags.“ Es beschreibt aus der Sicht des Kunden präzise, was das System leisten soll und warum es benötigt wird, ohne die technische Lösung vorzugeben. Damit bildet es die verbindliche Grundlage für Ausschreibungen, Angebote und die spätere Abnahme.

Wer ist am Lastenheft beteiligt?

Federführend bei der Erstellung eines Lastenhefts ist der Auftraggeber (Kunde). Er muss definieren, was er benötigt. In der Praxis wird die Erstellung zu einer Gemeinschaftsleistung mehrerer Beteiligter:

Auftraggeber: Trägt die Gesamtverantwortung.
Stakeholder: Fachabteilungen, Management, IT-Sicherheit.
Anwender/User: Liefern die funktionalen Bedarfe aus der Praxis.
Requirements Engineer/Business Analyst: Moderiert die Ermittlung und strukturiert die Ergebnisse.

Ein Lastenheft definiert nicht nur die gewünschte Leistung. Es definiert auch, wann diese als erfolgreich erbracht gilt.

Um Vollständigkeit zu garantieren, empfiehlt sich die Strukturierung nach einem gängigen Standard.

Hier sind Beispiele dafür.

Gliederung nach Balzert

Die von Balzert vorgeschlagene, sehr griffige Struktur wird oft in der Ausbildung und in mittelständischen deutschen Projekten genutzt. Sie stellt sicher, dass sowohl fachliche als auch qualitative Aspekte abgedeckt sind:

1. Zielbestimmung

Beschreibt die Geschäftsziele und den angestrebten Nutzen. Was soll durch das System erreicht werden? Was sind die wichtigsten Erfolgskriterien?

2. Produkteinsatz

Definiert den Systemkontext, den Anwendungsbereich und die Zielgruppen. In welcher Umgebung wird das Produkt eingesetzt? Wer sind die Benutzer? Mit welchen anderen Systemen muss kommuniziert werden?

3. Produktfunktionen

Die funktionalen Anforderungen aus Sicht des Auftraggebers. Welche Aufgaben muss das System aktiv unterstützen? (Oft als Use Cases formuliert).

4. Produktdaten

Legt fest, welche Daten das System langfristig speichern und verwalten muss (aus fachlicher Sicht, noch ohne Datenbank-Design).

5. Produktleistungen

Anforderungen an Zeit und Kapazität. Wie schnell müssen Reaktionen erfolgen? Wie viele Nutzer müssen gleichzeitig arbeiten können?

6. Qualitätsanforderungen

Definition von Merkmalen wie Zuverlässigkeit, Benutzbarkeit (Usability), Effizienz und Änderbarkeit (nach ISO/IEC 25010).

7. Ergänzungen

Besondere Anforderungen, die in keine andere Kategorie passen (z. B. Schulungen, Dokumentationspflichten oder einzuhaltende Normen).

Die Software Requirements Specification (SRS) nach IEEE

Für international ausgerichtete Projekte oder die Entwicklung komplexer Softwaresysteme ist die Struktur nach dem IEEE-Standard (ISO/IEC/IEEE 29148) weltweit anerkannt. Die Software Requirements Specification (IEEE/SRS) gliedert sich in drei Hauptbereiche:

1. Einleitung

In diesem Teil wird der Rahmen abgesteckt. Er dient dazu, allen Projektbeteiligten den Kontext zu vermitteln.

Zweck (Purpose): Für wen ist dieses Dokument? Was ist sein Ziel?
Geltungsbereich (Scope): Welches Produkt wird beschrieben? Was ist explizit nicht Teil der Software?
Definitionen & Abkürzungen: Ein Glossar, um terminologische Missverständnisse zu vermeiden.
Referenzen: Verweise auf andere Dokumente (z. B. Business Case oder übergeordnete System-Spezifikationen).

2. Gesamtbeschreibung

Hier wird das „Big Picture“ gezeichnet, ohne zu tief ins Detail zu gehen.

Produktperspektive: Ist die Software ein eigenständiges Produkt oder Teil eines größeren Systems?
Produktfunktionen: Eine Zusammenfassung der Hauptfunktionen (oft grafisch als Use-Case-Diagramm).
Benutzermerkmale: Wer sind die Anwender? Welche Vorkenntnisse bringen sie mit?
Einschränkungen (Constraints): Gesetzliche Vorgaben, Hardware-Limits oder einzuhaltende Protokolle.
Annahmen und Abhängigkeiten: Von welchen externen Faktoren (z. B. Drittanbieter-APIs) hängt der Erfolg ab?

3. Spezifische Anforderungen

Dies ist der wichtigste Teil für Entwicklung und Qualitätssicherung. Er muss so präzise sein, dass daraus Testfälle abgeleitet werden können. Zentrale Unterpunkte sind:

Externe Schnittstellen: Genaue Beschreibung der User Interfaces (UI), Hardware-Schnittstellen und Software-Schnittstellen (APIs).
Funktionale Anforderungen: Detaillierte Beschreibung der Logik, Eingabeprüfungen und Datenverarbeitung für jede Funktion.
Leistungsanforderungen: Statische und dynamische Anforderungen (z. B. Anzahl gleichzeitiger Nutzer, Antwortzeiten unter Last).
Software-Attribute: Anforderungen an die Zuverlässigkeit (Reliability), Verfügbarkeit (Availability), Sicherheit (Security) und Wartbarkeit.

Logische Datenbankanforderungen: Welche Informationseinheiten müssen persistent gespeichert werden? (ER-Modell oder Klassendiagramme).

Standards und Normen im Vergleich

Um ein Lastenheft rechtssicher und fachlich fundiert zu erstellen, bieten sich weitere Standards an. Die nachfolgende Tabelle zeigt die gängigsten im Vergleich:
	Charakteristische Merkmale	Eignung
Balzert (Klassiker)	Didaktisch klar strukturiert, Fokus auf Vollständigkeit der Kapitel	Standard für Software-Engineering im D-A-CH Raum
IEEE 29148	Fokus auf präzise Sprache („Shall“-Statements) und logische Hierarchie	International agierende IT-Projekte
V-Modell XT	Sehr formalisiertes Produktmuster (Lastenheft als „Anforderungen (AG)“)	Öffentlicher Sektor / Behörden in Deutschland
IREB Standard	Fokus auf Qualitätskriterien von Anforderungen (Atomarität, Prüfbarkeit)	Methoden-orientierte Unternehmen
ISO/IEC 25010	Fokus auf Software-Qualitätsmerkmale (nicht-funktionale Anforderungen)	Hochkritische Systeme (Sicherheit, Usability)

Lastenheft vs. Pflichtenheft

Häufig werden die Begriffe „Lastenheft“ und „Pflichtenheft“ miteinander vermischt. Die Abgrenzung ist jedoch essenziell für die rechtliche und fachliche Klarheit. Die Unterschiede sind:

Abgrenzung zwischen Lastenheft und Pflichtenheft auf einen Blick.
	Lastenheft (Requirements Spec)	Pflichtenheft (System Spec)
Verantwortung	Auftraggeber (Kunde)	Auftragnehmer (Lieferant)
Fragestellung	WAS wird benötigt? (Problemraum)	WIE wird es gelöst? (Lösungsraum)
Rechtlicher Status	Grundlage für die Ausschreibung	Grundlage für den Vertrag/Realisierung

In der Praxis kommt es häufig zu einer Vermischung des Lasten- und Pflichtenhefts.

Anforderungen richtig dokumentieren

Ein statisches, mit Word erstelltes Lastenheft veraltet schnell und verliert den Bezug zur Realität. Damit kann es zu einem wahren Projektkiller werden. Denn Änderungen in ein solches Dokument einzupflegen, ist sehr aufwendig. Dabei geht die Traceability leicht verloren und die Qualität der Anforderungen (z.B. Testbarkeit) ist nur noch schwer nachprüfbar. Am Ende wird möglicherweise ein Produkt geliefert, das zwar einem veralteten Stand des Dokuments entspricht, aber nicht den aktuellen Bedürfnissen der Stakeholder.

Mit objectiF RPM wird das Lastenheft von einem „toten Papier“ zu einer dynamischen Datenbasis. Anstatt ein umfangreiches Dokument zu schreiben, verwalten Sie Anforderungen als Datenbank-Objekte, aus denen Sie jederzeit ein aktuelles Lastenheft generieren. Ihre Vorteile:

Struktur per Mausklick: Nutzen Sie eine fertige, standard-konforme Vorlage, die Sie entweder unverändert einsetzen oder an Ihre Bedürfnisse anpassen können.
Grafische Modellierung: Integrieren Sie Diagramme (z.B. Ziele, Systemkontext, Anwendungsfälle) direkt in die Spezifikation.
Echtzeit-Dokumentation: Generieren Sie das Lastenheft als MS Word- oder PDF-Dokument immer aktuell aus dem Tool.

Lastenheft aus einer Vorlage in objectiF RPM generieren

Wissen online: objectiF RPM und objectiF RM

objectiF RPM testen

Testen Sie objectiF RPM 30 Tage in vollem Umfang – inklusive Vorlagen für Requirements Engineering und Projektmanagement.

Jetzt kostenlos testen

Häufige Fragen

Passt das Lastenheft auch in die agile Entwicklung?

Ja, absolut. Es ist ein Missverständnis, dass Agilität Dokumentationsfreiheit bedeutet. In der agilen Welt fungiert das Lastenheft oft als „Vision Document“ oder als Basis für das Product Backlog. Während es im klassischen Projekt die Basis für den Vertrag ist, liefert es im agilen Kontext den Scope und die Geschäftsziele. Anstatt jedes Detail vorab festzuschreiben, definiert man im Lastenheft die Epics und High-Level-Requirements. Die detaillierte Ausarbeitung erfolgt dann „Just-in-Time“ in den Sprints. Ohne diese initiale Leitplanke riskiert auch ein agiles Projekt, den Fokus auf den Business-Value zu verlieren.

Was ist das größte Risiko bei einem Lastenheft?

Das größte Risiko ist die Unvollständigkeit oder Vagheit. Begriffe wie „benutzerfreundlich“ oder „schnell“ sind ohne messbare Kriterien nicht prüfbar. Dies führt unweigerlich zu Konflikten bei der Abnahme. Ein zweites großes Risiko ist die Vermischung mit dem Pflichtenheft (Lösungsvorgaben statt Problembeschreibung).

Ist ein Lastenheft rechtlich bindend?

Das Lastenheft selbst ist zunächst die Grundlage für die Einholung von Angeboten. Erst wenn es Teil des Vertragsgegenstandes wird – meist in Verbindung mit dem darauf basierenden Pflichtenheft des Auftragnehmers – erlangt es rechtliche Bindungswirkung für die Abnahme der Leistungen.

Wie detailliert muss ein Lastenheft sein?

So detailliert wie nötig, um ein verbindliches Angebot kalkulieren zu können. Es gilt der Grundsatz: So viel wie möglich über das WAS (Ziele/Funktionen) und so wenig wie möglich über das WIE (technische Umsetzung), um dem Auftragnehmer Raum für die beste technische Lösung zu lassen.

Mehr Wissen

Entdecken Sie weitere Wissensbeiträge online oder laden Sie unsere Whitepaper herunter.

Was ist ein Lastenheft?