Lastenheft
Ein Lastenheft beschreibt, was eine geplante Software aus Sicht des Auftraggebers leisten soll – Ziele, Funktionen, Rahmenbedingungen. Es dient als Vertrags- und Prüfgrundlage; die Umsetzungsplanung des Auftragnehmers folgt darauf im Pflichtenheft.
Das Lastenheft steht am Anfang der Anforderungsphase eines Software-Projekts; wie viel vom tatsächlichen Fachwissen es transportiert, hängt von der Erhebungsmethode ab – hier greift das Konzept des [[implizites-wissen|impliziten Wissens]].
In einfachen Worten
Im Lastenheft formuliert der Auftraggeber seine Anforderungen: welche Aufgaben das System übernehmen soll, für welche Nutzergruppen, unter welchen technischen und organisatorischen Bedingungen. Der Auftragnehmer antwortet mit dem Pflichtenheft, das beschreibt, wie er diese Anforderungen umsetzen will. Beide Dokumente sichern das Projekt vertraglich ab und machen Leistungen prüfbar. Als Wissensquelle für die Entwicklung hat das Lastenheft jedoch systematische Lücken: Fachleute erwähnen vieles nicht, was ihnen selbstverständlich erscheint; beschrieben wird der Ablauf, wie er gedacht ist, während die täglichen Behelfe daneben unerwähnt bleiben; und die Kosten dieser Behelfe kennt niemand, weil sie nie erhoben wurden. Ein erheblicher Teil des Fachwissens – implizites Wissen im Sinne Polanyis – erreicht das Dokument deshalb gar nicht erst.
Wozu brauche ich das?
Für Auftraggeber bleibt das Lastenheft unverzichtbar: Es definiert den Leistungsumfang, macht Angebote vergleichbar und liefert die Grundlage für die Abnahme. Wer es zusätzlich als Erhebungsinstrument ernst nimmt, ergänzt die Workshop-Termine um Beobachtung am Arbeitsplatz – dort zeigen sich die Nebenlisten, Zurufe und Ausnahmen, die im Besprechungsraum niemand erwähnt. Je vollständiger diese Realität ins Dokument einfließt, desto kleiner der Anteil der Anforderungen, die erst nach dem Produktivstart entdeckt werden. Das gilt für die Auswahl von Standardsoftware ebenso wie für die Entwicklung von Individualsoftware.
Beispiel aus der Praxis
Eine Spedition schreibt eine Software für die Tourenplanung aus. Das Lastenheft entsteht in drei Workshops mit der Disposition und umfasst alle regulären Abläufe. Nach der Einführung zeigt sich, was fehlte: Fahrer tauschen Touren untereinander, bevor die Disposition davon erfährt; Stammkunden haben mündlich zugesagte Zeitfenster; und für zwei Ladestellen existieren Zufahrtsbeschränkungen, die nur die erfahrenen Disponenten im Kopf haben. Keine dieser Regeln stand im Dokument, weil sie im Workshop niemand für erwähnenswert hielt. Zwei Tage Hospitation in der Disposition hätten alle drei zutage gefördert – die Nachrüstung im laufenden System kostete ein Vielfaches.
Wirtschaftlicher Nutzen
Ein belastbares Lastenheft senkt das teuerste Risiko eines Software-Projekts: Anforderungen, die erst im Betrieb entdeckt werden. Nachträge sind regelmäßig deutlich teurer als von Beginn an eingeplante Funktionen, verzögern die Einführung und beschädigen die Akzeptanz im Team – besonders, wenn sie das Datenmodell betreffen. Der zusätzliche Aufwand für Beobachtung am Arbeitsplatz und die Prüfung auf Sonderfälle ist im Verhältnis dazu gering und zahlt direkt auf die Qualität von Angebot, Zeitplan und Abnahme ein.
Typische Fehler
- Das Lastenheft als vollständige Wissensquelle behandelt – es enthält, was Befragte für erwähnenswert hielten, und genau daran scheitern Projekte.
- Anforderungen nur in Workshop-Terminen erhoben – die Behelfe des Alltags zeigen sich nur am Arbeitsplatz.
- Sonderfälle weggelassen, weil sie selten wirken – gerade Teillieferungen, Stornos und Ausnahmen erzeugen später die meisten Änderungswünsche.
- Lastenheft und Pflichtenheft gleichgesetzt – das eine formuliert die Anforderung, das andere die geplante Umsetzung; für die Abnahme braucht es beide.
- Das Dokument nach Vertragsschluss nie wieder angefasst – Änderungen im Projektverlauf gehören nachgeführt, sonst prüft die Abnahme gegen einen veralteten Stand.
Worauf achten?
- Vorgänge am Arbeitsplatz beobachten und die Befunde ins Lastenheft übernehmen, bevor es in die Ausschreibung geht.
- Gezielt nach Ausnahmen fragen: Was passiert bei Storno, Teillieferung, Reklamation, Vertretung?
- Mengengerüste erheben – wie oft ein Vorgang vorkommt, entscheidet über seine Priorität im System.
- Die Abnahmekriterien schon im Lastenheft festlegen, messbar und mit realen Beispieldaten.
- Bei der Anbieterauswahl beachten, welche Fragen der Anbieter selbst stellt – Rückfragen nach Sonderfällen zeigen fachliches Verständnis.
Häufig gestellte Fragen
Was ist ein Lastenheft?
Ein Dokument, in dem der Auftraggeber die Anforderungen an eine geplante Software festhält: Ziele, Funktionen, Nutzergruppen und Rahmenbedingungen. Es bildet die Grundlage für Angebote, Verträge und die spätere Abnahme.
Worin unterscheiden sich Lastenheft und Pflichtenheft?
Das Lastenheft formuliert, was der Auftraggeber verlangt. Das Pflichtenheft ist die Antwort des Auftragnehmers und beschreibt, wie die Anforderungen umgesetzt werden sollen. In Projekten gehören beide zusammen: das eine als Anforderungs-, das andere als Umsetzungsdokument.
Warum reicht ein Lastenheft für die Entwicklung nicht aus?
Weil ein Teil des Fachwissens den Weg ins Dokument nie findet: Selbstverständliches wird ausgelassen, Abläufe werden beschrieben, wie sie gedacht sind, und die täglichen Behelfe tauchen nirgends auf. Beobachtung am Arbeitsplatz und fachkundige Rückfragen schließen diese Lücke.
Wie detailliert sollte ein Lastenheft sein?
So detailliert, dass Angebote vergleichbar und Abnahmen prüfbar werden – einschließlich Sonderfällen und Mengengerüsten. Übertrieben enge technische Vorgaben schränken dagegen die Lösungsfindung des Anbieters unnötig ein; das Wie gehört ins Pflichtenheft.