Lastenheft für Softwareprojekte: Wie viel Spezifikation wirklich nötig ist

Bevor ein Softwareprojekt ausgeschrieben wird, steht eine unangenehme Frage im Raum: Wie genau muss man beschreiben, was man haben will? Manche Auftraggeber verschicken drei Stichpunkte per E-Mail, andere ein Konvolut aus dem Qualitätsmanagement, das jede Bildschirmmaske vorwegnimmt. Beide Extreme führen zum gleichen Ergebnis — zu Angeboten, die sich nicht vergleichen lassen. Dieser Beitrag beschreibt, was ein Lastenheft leisten muss, welche Inhalte tatsächlich tragen und ab welcher Seitenzahl zusätzlicher Text den Nutzen wieder auffrisst.

Lastenheft und Pflichtenheft: zwei Dokumente, zwei Absender

Die Trennung ist einfacher, als das Behördendeutsch vermuten lässt. Das Lastenheft kommt vom Auftraggeber und beantwortet Was und Warum: Welches Problem soll gelöst werden, welche Ziele gelten, welche Randbedingungen sind gesetzt. Das Pflichtenheft ist die Antwort des Dienstleisters und beantwortet Wie: Architektur, Umsetzungsweg, Aufwand, ausdrückliche Abgrenzungen. In der Praxis werden die Begriffe munter vermischt, und agile Anbieter sprechen lieber von Anforderungsdokument oder Projektrahmen. Die Bezeichnung ist zweitrangig, die Rollenverteilung nicht.

Wer als Auftraggeber bereits das Wie festschreibt — Datenbanktechnologie, Menüstruktur, Feldreihenfolge —, verschenkt genau die Kompetenz, für die er bezahlt, und übernimmt die Verantwortung für Entscheidungen, deren Folgen er nicht beurteilen kann. Umgekehrt gilt: Wer die Ziele nicht benennt, erhält eine Lösung für das Problem, das ein Fremder vermutet hat. Beides ist teuer, nur an unterschiedlichen Stellen.

Die Bausteine, die wirklich tragen

Ein brauchbares Lastenheft muss neun Dinge klären. Mehr ist erlaubt, weniger führt regelmäßig zu Rückfragen oder zu Risikoaufschlägen im Angebot.

• Ausgangslage: Wie läuft es heute, mit welchen Werkzeugen, und was daran kostet Geld oder Nerven.
• Ziele mit messbaren Kriterien: nicht „effizienter“, sondern etwa „Angebotserstellung ohne doppelte Dateneingabe“.
• Rollen und Rechte: Wer darf sehen, erfassen, freigeben, auswerten — grob als Matrix.
• Kernprozesse als Ablauf: drei bis sieben Hauptabläufe in Schritten, inklusive Sonderfällen und Abbrüchen.
• Schnittstellen und Bestandssysteme: was bleibt, was verschwindet, was muss angebunden werden.
• Mengen und Nutzerzahlen: Datensätze pro Jahr, gleichzeitige Nutzer, Dateigrößen, Wachstumserwartung.
• Nicht-funktionale Anforderungen: Verfügbarkeit, akzeptable Antwortzeiten, Sprachen, Endgeräte, Datenhaltung.
• Abnahmekriterien: woran am Ende festgestellt wird, dass geliefert wurde, was bestellt war.
• Nicht-Ziele: ausdrücklich, was das System nicht tun soll.

Zwei dieser Punkte fehlen fast immer und verursachen die meisten Überraschungen: Mengen und nicht-funktionale Anforderungen. Ob ein Bericht über zweitausend oder zwei Millionen Datensätze laufen soll, entscheidet über die Architektur — und damit über den Preis. Ebenso macht es einen Unterschied, ob eine Anwendung im Bürobetrieb gelegentlich langsam sein darf oder ob sie in einer Praxis am Empfang unter Zeitdruck bedient wird.

Unterschätzt werden außerdem die beiden letzten Punkte. Abnahmekriterien sind kein Formalismus, sondern die einzige belastbare Antwort auf die Frage, wann ein Projekt fertig ist; wer sie erst am Ende formuliert, verhandelt sie unter Druck. Und Nicht-Ziele sparen mehr Geld als jede Verhandlungsrunde: Der Satz „keine Anbindung an die Zeiterfassung in dieser Stufe“ verhindert zuverlässiger Mehrkosten als jede Preisdiskussion.

Wie viel Spezifikation genug ist

Die Grenze verläuft nicht bei einer Seitenzahl, sondern bei einer Frage: Braucht der Anbieter diese Information, um Aufwand und Lösungsweg seriös einzuschätzen? Wenn nicht, gehört sie in die spätere Detailarbeit — oder gar nicht ins Dokument.

Warum eine Wunschliste von zweihundert Seiten schlechtere Angebote erzeugt als zwölf Seiten Klarheit, hat einen nüchternen Grund: Ein Anbieter muss alles einpreisen, was er nicht priorisieren kann. Ohne Gewichtung wird jede Zeile zur Verpflichtung, Widersprüche zwischen Kapiteln werden mit Puffer beantwortet, und die eigentlichen Kernabläufe verschwinden zwischen Nebenanforderungen. Das Ergebnis ist ein hoher Preis für ein System, das trotzdem nicht das Wichtigste am besten löst. Zwölf präzise Seiten mit klarer Priorisierung erzeugen dagegen Angebote, die man argumentieren und verhandeln kann.

Unsicherheit benennen statt verstecken

Kein Auftraggeber weiß vorab alles. Der Unterschied zwischen einem professionellen und einem naiven Lastenheft liegt darin, wie es mit dieser Lücke umgeht. Professionell heißt: Annahmen ausdrücklich als Annahmen kennzeichnen — „wir gehen von etwa vierzig aktiven Nutzern aus“ —, damit der Anbieter widersprechen kann. Offene Punkte gehören in eine kurze Liste mit Verantwortlichem und Klärungstermin, statt stillschweigend übergangen zu werden.

Wo mehrere Wege denkbar sind, formulieren Sie Optionen statt Festlegungen: „Anbindung an die Warenwirtschaft entweder per Schnittstelle oder zunächst per nächtlichem Datenabgleich — bitte beide Varianten mit Aufwand bewerten.“ Zusätzlich hilft eine schlichte Priorisierung in Muss, Soll und Kann. Sie ist das wirksamste Instrument im ganzen Dokument, weil sie dem Anbieter erlaubt, ein Budget sinnvoll zu verteilen, statt es gleichmäßig über alles zu verteilen.

Wie daraus vergleichbare Angebote werden

Der wirtschaftliche Sinn des Lastenhefts ist Vergleichbarkeit. Drei Anbieter, die auf drei unterschiedliche Erzählungen antworten, liefern drei unvergleichbare Zahlen. Damit die Vergleichbarkeit wirklich entsteht, sollten Sie die Angebotsstruktur mitgeben und je Anbieter dasselbe verlangen:

• Aufwand je Kernprozess, nicht nur eine Gesamtsumme
• die getroffenen Annahmen, ausdrücklich aufgelistet
• klare Ausschlüsse: was nicht Teil des Angebots ist
• laufende Kosten für Betrieb, Wartung und Support

Nebeneffekt: Sie erkennen an den Rückfragen, mit wem Sie es zu tun haben. Ein Anbieter, der Ihren Mengenangaben widerspricht oder eine Anforderung als unnötig teuer markiert, hat gelesen und gedacht. Wer das Dokument kommentarlos in ein Angebot übersetzt, hat vermutlich nur addiert. Ebenfalls aussagekräftig: ob ein Anbieter Ihre Prioritäten aufgreift und einen kleineren ersten Schritt vorschlägt, statt den gesamten Wunschkatalog in einem Zug anzubieten. Welche Fragen Sie dabei umgekehrt stellen sollten, behandelt unser Beitrag zur Auswahl einer Software-Agentur.

Übergang ins agile Arbeiten

Ein verbreitetes Missverständnis lautet, ein Lastenheft und agile Umsetzung passten nicht zusammen. Sie passen sehr gut, wenn man die Ebenen trennt: Das Lastenheft ist der Rahmen — Ziele, Grenzen, Nicht-Ziele, Abnahmekriterien —, das Backlog ist die Detailebene, die während der Umsetzung wächst. Der Rahmen bleibt stabil, die Details dürfen sich ändern; jede Änderung wird bewusst am Ziel gemessen, nicht am Wortlaut eines Kapitels.

Praktisch bedeutet das: Verwenden Sie das Lastenheft nicht als Vertragskeule, sondern als Prüfmaßstab in den Zwischenabnahmen. Wie sich daraus eine belastbare Umsetzungsplanung ergibt, zeigt unser Artikel zum Planen eines Softwareprojekts; wie wir die Phasen im Projekt schneiden, steht auf der Prozessseite.

Wann zwei Seiten und ein Gespräch genügen

Ehrlich gesagt: Für viele Vorhaben ist ein Lastenheft unnötiger Aufwand. Bei einem digitalen Formular, einem Auswertungsbericht oder einer einzelnen Automatisierung genügt ein zweiseitiges Zielpapier plus ein Gespräch — Problem, Ziel, Nutzer, drei Muss-Funktionen, Budgetrahmen, Wunschtermin. Alles darüber hinaus verzögert nur den Punkt, an dem man etwas Lauffähiges sehen kann. Gleiches gilt, wenn erkennbar Standardsoftware oder eine No-Code-Lösung reicht: Dann ist die Anforderungsarbeit eine Auswahlfrage, keine Spezifikationsfrage.

Und ein Warnsignal in die andere Richtung: Wenn Sie beim Schreiben merken, dass Sie Ihren eigenen Kernprozess nicht in Schritten beschreiben können, ist das kein Dokumentenproblem. Dann steht vor dem Lastenheft eine Prozessaufnahme oder ein kleines Vorprojekt — sonst spezifizieren Sie ein Missverständnis, nur sehr gründlich.

Fazit: Klarheit schlägt Vollständigkeit

Ein gutes Lastenheft ist kurz, priorisiert und ehrlich über das, was noch offen ist. Es beschreibt Ausgangslage, Ziele mit messbaren Kriterien, Kernprozesse, Schnittstellen, Mengen, nicht-funktionale Anforderungen, Abnahmekriterien und Nicht-Ziele — und überlässt den Lösungsweg denen, die ihn verantworten. Wenn Sie unsicher sind, ob Ihr Vorhaben zwei oder zwanzig Seiten braucht, sehen wir uns die Ausgangslage gerne einmal gemeinsam an: Der kürzeste Weg dorthin führt über die Kontaktseite.

Häufige Fragen

Wer schreibt das Lastenheft — wir oder der Dienstleister?

Das Lastenheft gehört dem Auftraggeber, weil nur er Ziele, Prozesse und Randbedingungen kennt. Bei der Strukturierung darf ein Dienstleister moderieren; wer es aber vollständig für Sie schreibt, spezifiziert am Ende seine eigene Lösung.

Wie lang sollte ein Lastenheft sein?

Für mittelständische Vorhaben reichen meist zehn bis zwanzig Seiten, wenn sie priorisiert sind. Entscheidend ist nicht der Umfang, sondern ob ein Anbieter daraus Aufwand und Lösungsweg seriös ableiten kann.

Was ist der häufigste Fehler in Lastenheften?

Fehlende Priorisierung und fehlende Mengenangaben. Ohne Muss-Soll-Kann wird jede Zeile zur Verpflichtung, und ohne Datenmengen sowie Nutzerzahlen kalkuliert jeder Anbieter mit Risikopuffer statt mit Fakten.

Brauchen wir ein Lastenheft, wenn wir agil arbeiten wollen?

Ja, aber als Rahmen: Ziele, Grenzen, Nicht-Ziele und Abnahmekriterien. Die Detailebene entsteht danach laufend im Backlog — das Dokument ersetzt sie nicht, sondern gibt ihr die Richtung.