Lastenheft für Software: Praxisleitfaden mit Vorlage und Beispiel

Was ist ein Lastenheft? (Definition nach DIN 69901-5)

Ein Lastenheft für Software beschreibt aus Sicht des Auftraggebers, was und wofür eine Softwarelösung benötigt wird – ohne vorwegzunehmen, wie die Lösung technisch umgesetzt werden soll. Nach DIN 69901-5 ist das Lastenheft die „Gesamtheit der Forderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers“. Es dient als strategische Basis für die Kommunikation zwischen Geschäftsführung, IT, Einkauf und später dem externen Entwicklungspartner.

In mittelständischen Unternehmen liegt der Nutzen klar auf der Hand: Ein gut geschriebenes Lastenheft stellt sicher, dass Entwicklungsaufwand, Budget und Zeit realistisch kalkuliert werden können. Gleichzeitig können Sie damit bereits früh im Prozess Erwartungen und Ziele klar definieren. Im Ablauf eines Softwareprojekts steht das Lastenheft immer am Anfang und bildet die Grundlage für die nächste Stufe: Das Pflichtenheft (Details dazu im nächsten Kapitel).

Lastenheft vs. Pflichtenheft: Unterschied im Überblick

Im Sprachgebrauch werden die Begriffe Lastenheft und Pflichtenheft oft verwechselt. Die Klarheit über den Unterschied ist für jedes Softwareprojekt entscheidend – sonst entstehen Missverständnisse, die Projekte unnötig verzögern oder verteuern.

Kriterium	Lastenheft	Pflichtenheft
Verfasser	Auftraggeber (z. B. Sie als Kunde)	Auftragnehmer (umsetzendes Entwicklungsteam)
Leitfrage	Was soll wofür erreicht werden?	Wie und womit wird es umgesetzt?
Zeitpunkt im Projekt	Zu Beginn	Nach Annahme des Lastenhefts, vor Umsetzung
Inhalt	Ziele, Anforderungen, Nutzergruppen, Rahmenbedingungen	Detailliertes Konzept der Software-Umsetzung
Abnahmebasis	Bildet Ausgangspunkt für das Angebot	Grundlage für Tests und Endabnahme

Typische Verwechslungen führen oft dazu, dass Anforderungen zu früh technisch festgelegt werden oder wichtige Geschäftsziele verloren gehen. Für den Projekterfolg ist diese Trennung aber zentral.

Welche Inhalte gehören in ein Lastenheft für Software? Aufbau & Vorlage

Ein überzeugendes Lastenheft für ein Softwareprojekt folgt einer klaren Struktur. So stellen Sie sicher, dass alle Beteiligten – von der Geschäftsleitung bis hin zur IT-Abteilung – die Anforderungen verstehen und später testbar umsetzen können.

Vorlage: 10 praxisbewährte Kapitel für ein Lastenheft (Beispiel: Kundenportal für Serviceaufträge)

1. Ausgangslage:
   • Beschreibung der aktuellen Situation. Beispiel: "Kunden müssen Serviceaufträge derzeit telefonisch oder per E-Mail melden. Die Erfassung ist fehleranfällig."
2. Projektziele:
   • Was soll durch die Software erreicht werden? Beispiel: "Bearbeitungszeit für Serviceanfragen um 30 % reduzieren."
3. Nutzergruppen/Rollen:
   • Wer nutzt das System? Beispiel: "Endkunden, Servicemitarbeiter, Innendienst, Administratoren."
4. Ist-/Soll-Ablauf:
   • Wie läuft der Prozess jetzt, wie künftig? Beispiel: "Neu: Webformular für Serviceaufträge, automatische Ticketvergabe."
5. Funktionale Anforderungen:
   • Detailliert nach Muss/Soll/Kann für das Projektziel. Beispiel: "Muss: Upload von Fotos zum Auftrag; Soll: Statusbenachrichtigungen per E-Mail; Kann: Chat-Funktion für Rückfragen."
6. Nicht-funktionale Anforderungen:
   • u. a. Performance, Zuverlässigkeit und rechtliche Vorgaben (wie DSGVO, siehe unten). Beispiel: "Alle Kundendaten ausschließlich auf Servern in Deutschland speichern."
7. Schnittstellen und Daten:
   • Zu anderen IT-Systemen, Datenflüsse. Beispiel: "Übernahme der Kundenstammdaten aus dem ERP-System."
8. Rahmenbedingungen:
   • Budget-, Zeit-, Qualitäts- und Ressourcenrahmen. Beispiel: "Inbetriebnahme bis 30.09.; maximale Ausfallzeit 1 Stunde pro Wartung."
9. Abnahmekriterien:
   • Wie wird der Projekterfolg überprüft? Beispiel: "80 % der Kundenfeedbacks zur Bedienbarkeit müssen positiv ausfallen."
10. Glossar:

• Begriffsdefinitionen für Klarheit bei allen Beteiligten. Beispiel: "Serviceauftrag = jeder vom Kunden initiierte Vorgang zur Störungsbehebung."

Muss-, Soll- und Kann-Anforderungen sauber definieren

Im Mittelstand sind oft viele Beteiligte an der Anforderungsdefinition beteiligt, nicht alle sprechen dieselbe Sprache. Erfahrungsgemäß führen unklare Anforderungen zu Missverständnissen und Fehlentwicklungen.

Unklare Anforderung	Klare Anforderung (Beispiel Kundenportal)
"Das System soll einfach bedienbar sein."	"Kunden müssen Serviceaufträge mit max. 5 Klicks erfassen können."
"Die Software muss schnell laufen."	"Antwortzeiten im Portal dürfen max. 2 Sekunden betragen."
"Es darf keine Fehler geben."	"System soll 99,5 % Verfügbarkeit haben, Supportzeit werktags 8–17h."
"Daten sollen bestmöglich geschützt werden."	"Alle personenbezogenen Daten nach DSGVO (Art. 32) zu sichern."
"Das System soll flexibel sein."	"Neue Servicearten müssen im Admin-Bereich ohne Programmierung angelegt werden können."

Nicht-funktionale Anforderungen im Lastenheft (inkl. DSGVO)

Nicht-funktionale Anforderungen sind oft der „blinde Fleck“ im Lastenheft von Softwareprojekten. Gemeint sind alle Rahmenbedingungen, die nicht direkt das sichtbare Verhalten der Software betreffen, aber für Sicherheit, Zuverlässigkeit und Rechtssicherheit meist kritisch werden – besonders für Mittelstand und Datenschutz.

Typische Beispiele für nicht-funktionale Anforderungen:

• Datenschutz (DSGVO), IT-Sicherheit
• Performance (z. B. Antwortzeiten, Verfügbarkeit)
• Betrieb, Wartbarkeit und Benutzerfreundlichkeit
• Rechtliche Vorgaben („GoBD-Konformität“ bei Finanzdaten)
• Skalierbarkeit

Gerade die DSGVO sorgt regelmäßig für Unsicherheit: Im Lastenheft muss geregelt sein, welche personenbezogenen Daten verarbeitet werden, wie sie gespeichert und geschützt werden und wo die Server stehen.

Das Lastenheft im agilen Vorgehen

Viele Unternehmen arbeiten heute mit agilen Methoden wie Scrum und Kanban. Dennoch: Ein Lastenheft verliert auch im agilen Umfeld nicht an Bedeutung – es bildet die Orientierungsgrundlage für alle Beteiligten.

Das Lastenheft

• skizziert den unternehmerischen Rahmen (Ziele, Muss-Anforderungen, Schnittstellen, Rahmenbedingungen)
• wird in agilen Projekten bewusst schlank gehalten und regelmäßig fortgeschrieben
• kann als "Product Vision" oder „Epics“-Basis dienen

Häufige Fehler bei der Erstellung eines Lastenhefts für Software

Die wichtigsten Fehlerquellen aus 10 Jahren Projektpraxis bei RemotaTech:

1. Nutzergruppen und deren Anforderungen werden nicht einbezogen – Folge: Die Lösung ist an den Mitarbeitern oder Kunden vorbei entwickelt.
2. Unpräzise oder widersprüchliche Anforderungen – Folge: Interpretationsspielraum, Mehrarbeit, Kostensteigerung.
3. Nicht-funktionale Anforderungen vergessen (z. B. DSGVO, IT-Sicherheit) – Folge: Betriebsrisiko und Nachbesserungen.
4. Zu frühe technische Festlegungen – das Wie gehört nicht ins Lastenheft.
5. Lastenheft und Pflichtenheft werden vermischt – niemand ist wirklich verantwortlich; Abgrenzung fehlt.

Nächste Schritte: Anforderungsworkshop und Beratung

Ein strukturiertes Lastenheft für Software ist die beste Grundlage für ein erfolgreiches Softwareprojekt. Ob Anforderungsworkshop bei Ihnen vor Ort (z. B. in Wesseling, Köln, Bonn, Rhein-Erft-Kreis, Rhein-Sieg-Kreis) oder per Videokonferenz: Wir von RemotaTech unterstützen Sie gerne bei der effizienten Erarbeitung und Überprüfung Ihres Lastenhefts für individuelle Softwareprojekte.

Mehr Informationen zum Ablauf eines Workshops finden Sie auf unserer Seite zur Erstberatung oder nutzen Sie direkt unser Kontaktformular.