Was ist ein Lastenheft?

Ein Lastenheft ist ein Dokument, in dem ein Auftraggeber festhält, was eine Software, Anlage oder Dienstleistung leisten soll und unter welchen Bedingungen – bevor ein Anbieter beauftragt wird. Es beschreibt das Was und Wofür aus Sicht der Nutzer, nicht das Wie. Die Norm DIN 69901-5 definiert es als Gesamtheit der Forderungen des Auftraggebers.

Ein gutes Lastenheft ist die Grundlage für vergleichbare Angebote, einen belastbaren Vertrag und eine Abnahme, bei der beide Seiten wissen, woran sie gemessen werden. Ein schlechtes erkennt man daran, dass nach drei Monaten Projektlaufzeit alle von etwas anderem gesprochen haben.

Wozu ein Lastenheft dient

Das Lastenheft zwingt dazu, ein Vorhaben zu Ende zu denken, bevor Geld fließt. Es erfüllt drei Aufgaben:

• Klärung nach innen: Vertrieb, Buchhaltung und Lager einigen sich, welches Problem die neue Software eigentlich lösen soll. Oft zeigt sich erst hier, dass jede Abteilung etwas anderes erwartet.
• Grundlage für Angebote: Mehrere Anbieter kalkulieren auf derselben Basis. Ohne Lastenheft vergleichen Sie Äpfel mit Birnen.
• Maßstab für die Abnahme: Am Ende wird geprüft, ob die Anforderungen erfüllt sind. Was nicht drinsteht, lässt sich schwer einfordern.

Bei öffentlichen Auftraggebern übernimmt diese Rolle die Leistungsbeschreibung, oft ergänzt durch ein Leistungsverzeichnis. Der Gedanke ist derselbe.

Was in ein Lastenheft gehört

1. Ausgangslage: Wie läuft der Vorgang heute, welche Systeme sind im Einsatz, wo hakt es? Zahlen helfen: Anzahl Aufträge pro Woche, Zahl der Nutzer, Datenmengen.
2. Ziele: Was soll nach der Einführung besser sein – messbar formuliert, etwa „Angebote in zwei statt fünf Tagen“.
3. Nutzer und Rollen: Wer arbeitet mit der Software, wer darf was sehen und ändern?
4. Funktionale Anforderungen: Was muss das System können? Am verständlichsten als kurze Szenarien oder User Stories.
5. Nicht-funktionale Anforderungen: Antwortzeiten, Verfügbarkeit, Datenschutz, Barrierefreiheit, Serverstandort, Sprachen.
6. Schnittstellen: An welche Systeme muss angebunden werden – ERP, Buchhaltung, Shop, CRM?
7. Rahmenbedingungen: Budgetrahmen, Termine, Abnahmekriterien, Betrieb und Wartung nach dem Start.
8. Priorisierung: Was ist Pflicht, was wäre schön? Die Einteilung in Muss, Soll und Kann bewahrt vor dem Alles-oder-nichts.

Lastenheft und Pflichtenheft

Das Pflichtenheft antwortet also auf das Lastenheft. In der Praxis werden beide Begriffe oft verwechselt oder gleichgesetzt. Klären Sie deshalb mit Ihrem Anbieter, welches Dokument wer schreibt und was es verbindlich regelt.

Beispiel: Lastenheft für ein Kundenportal

Ein Hersteller von Industrietoren möchte, dass Händler Ersatzteile selbst bestellen können, statt per Fax und Telefon. Ein Auszug aus dem Lastenheft könnte so aussehen:

• Ziel: Mindestens die Hälfte der Ersatzteilbestellungen läuft nach sechs Monaten über das Portal.
• Muss: Händler melden sich an, sehen ihre Preise und ihren Bestellverlauf, suchen Teile über Tornummer oder Artikelnummer.
• Muss: Bestellungen landen ohne Abtippen im ERP.
• Soll: Explosionszeichnungen je Tortyp, aus denen Teile direkt bestellt werden.
• Kann: Rechnungen und Lieferscheine zum Download.
• Rahmen: Deutsch und Englisch, Hosting in Deutschland, Anmeldung über vorhandene Händlerkonten.

Eine ausführliche Gliederung mit Vorlage finden Sie im Beitrag Lastenheft für Software: Vorlage und Beispiele.

Lastenheft in agilen Projekten

Gegen das Lastenheft wird oft eingewendet, es passe nicht zu agiler Entwicklung. Das stimmt nur für die Variante mit dreihundert Seiten, die jede Maske vorab festlegt – ein Erbe des Wasserfallmodells. Ein schlankes Lastenheft mit Zielen, Rollen, Muss-Anforderungen und Rahmenbedingungen verträgt sich gut mit agilem Vorgehen. Details werden dann gemeinsam und schrittweise ausgearbeitet. Wichtig ist, dass der Vertrag dazu passt: Ob ein fester Leistungsumfang oder laufende Mitarbeit vereinbart ist, macht einen erheblichen Unterschied, wie der Beitrag Werkvertrag oder Dienstvertrag in IT-Projekten zeigt.

Typische Fehler

• Lösung statt Problem: „Wir brauchen eine App“ statt „Außendienstler sollen Aufmaße vor Ort erfassen können“. Die Lösung sollte der Anbieter vorschlagen dürfen.
• Unscharfe Begriffe: „benutzerfreundlich“, „schnell“, „modern“. Was nicht prüfbar ist, hilft bei der Abnahme nicht.
• Alles ist Pflicht: Ohne Priorisierung wird das Projekt teuer und spät.
• Betrieb vergessen: Wer wartet die Software, wer macht Updates, wo läuft sie? Diese Fragen gehören vor die Beauftragung.
• Ohne die Nutzer geschrieben: Die Menschen, die später täglich damit arbeiten, wissen am besten, wo es heute klemmt.

In der Praxis: vom Lastenheft zum ersten Release

Viele Unternehmen kommen mit einer Idee und ohne Lastenheft zu uns, und das ist in Ordnung. Im Rahmen der Softwareentwicklung erarbeiten wir die Anforderungen gemeinsam mit Ihrem Team, trennen Muss von Kann und schlagen einen ersten Umfang vor, der schnell im Alltag nutzbar ist. Wer vorab klären möchte, wo sich Individualsoftware überhaupt lohnt, beginnt mit dem Digitalisierungs-Check oder einer Expertenberatung.

Häufige Fragen

Wer schreibt das Lastenheft?

Der Auftraggeber, also das Unternehmen, das die Software haben möchte. Es kann sich dabei von einem Berater unterstützen lassen, die fachlichen Entscheidungen bleiben aber bei ihm.

Wie lang sollte ein Lastenheft sein?

So kurz wie möglich, so genau wie nötig. Für ein mittelgroßes Softwareprojekt reichen oft zehn bis zwanzig Seiten, wenn Ziele, Rollen, Muss-Anforderungen und Schnittstellen klar beschrieben sind.

Ist ein Lastenheft rechtlich bindend?

Für sich allein nicht. Verbindlich wird es, wenn es Bestandteil des Vertrags wird. Dann bildet es den Maßstab, an dem die vereinbarte Leistung gemessen wird.

Brauche ich ein Lastenheft auch für ein MVP?

Eine Kurzfassung ja: Ziel, Zielgruppe, die wenigen Muss-Funktionen und was bewusst weggelassen wird. Gerade beim MVP schützt das vor schleichender Erweiterung.