Lastenheft für Software: Vorlage und Beispiel

Wer ein Lastenheft für Software schreibt, legt fest, was ein Softwareprojekt leisten soll, bevor der erste Anbieter ein Angebot abgibt. Das Lastenheft ist das Dokument des Auftraggebers. Es beschreibt Ziele, Abläufe und Anforderungen aus fachlicher Sicht und bleibt bewusst offen, wie die Lösung technisch gebaut wird. Je sauberer es ist, desto vergleichbarer werden die Angebote und desto weniger wird später über den Umfang gestritten.

Was ein Lastenheft für Software ist

Die Norm DIN 69901-5 definiert das Lastenheft als die „vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers innerhalb eines Auftrages“ (zitiert nach LMU München, Seminarausarbeitung, 01/2017). Die ältere DIN 69905, die oft noch genannt wird, ist seit 2009 in der Normenreihe DIN 69901 aufgegangen (DIN Media).

Für Softwareprojekte heißt das: Das Lastenheft beantwortet die Frage nach dem Was und dem Wofür. Welches Geschäftsproblem soll gelöst werden, wer arbeitet mit dem System, welche Abläufe muss es abbilden, welche Bedingungen gelten im Betrieb. Die Frage nach dem Wie, also Architektur, Technologien und Datenmodell, beantwortet der Auftragnehmer im Pflichtenheft. Wie sich beide Dokumente im Detail unterscheiden, zeigt unser Beitrag zur Pflichtenheft-Vorlage.

Die Lastenheft-Vorlage für Software: acht Kapitel

Die folgende Gliederung deckt die Punkte ab, die ein Anbieter für ein belastbares Angebot braucht. Sie funktioniert für ein internes Werkzeug ebenso wie für eine Plattform mit mehreren Standorten, nur die Tiefe ändert sich.

1. Ausgangslage und Projektziel. Welches Geschäftsproblem gelöst werden soll, warum jetzt, und woran der Auftraggeber nach der Einführung den Erfolg misst.
2. Ist-Zustand. Wie der Ablauf heute funktioniert, mit welchen Werkzeugen, Mengengerüsten und bekannten Schwachstellen. Zahlen wie Nutzer, Vorgänge pro Tag oder Standorte helfen dem Anbieter mehr als jede Beschreibung.
3. Soll-Zustand. Wer künftig mit dem System arbeitet und wie der Ablauf danach aussehen soll, beschrieben aus Sicht der Nutzer, nicht der Technik.
4. Fachliche Anforderungen. Jede Anforderung einzeln, nummeriert und mit Priorität, etwa MUSS, SOLL und KANN. Nummerierte Anforderungen machen Angebote vergleichbar (wiki.induux.de).
5. Qualitätsanforderungen. Verfügbarkeit, Antwortzeiten, Datenschutz, Barrierefreiheit, Mehrsprachigkeit. Möglichst mit Zahl, damit sie prüfbar sind.
6. Rahmenbedingungen und Schnittstellen. Vorhandene Systeme wie ERP oder Active Directory, Vorgaben der IT zum Betrieb in der Cloud oder im eigenen Rechenzentrum, rechtliche Vorgaben.
7. Abgrenzung. Was ausdrücklich nicht zum Auftrag gehört. Dieses Kapitel verhindert mehr Missverständnisse als jedes andere.
8. Lieferumfang, Abnahme und Rahmen. Was geliefert wird (Software, Dokumentation, Schulung, Betrieb), wie die Abnahme abläuft, welcher Zeit- und Budgetrahmen gilt.

Lastenheft Beispiel: ein Wartungsportal

Ein Maschinenbauer mit drei Werken dokumentiert Wartungen heute in Excel-Listen und auf Papier. Ziel ist ein Wartungsportal, in dem Techniker Aufträge am Tablet abarbeiten und die Werksleitung offene Wartungen je Anlage sieht. Ein Auszug aus Kapitel 4 könnte so aussehen:

Auffällig ist, was fehlt: keine Datenbank, keine App-Technologie, keine Architektur. Die Anforderung A-02 sagt, dass der Techniker offline arbeiten muss, nicht wie die Synchronisation gebaut wird. Das entscheidet der Anbieter im Pflichtenheft.

Wer das Lastenheft schreibt

Das Lastenheft schreibt der Auftraggeber. In der Praxis übernimmt das meist eine Person aus der Fachabteilung oder dem Projektmanagement, die den Ablauf kennt und Entscheidungen einholen kann. Die IT liefert die Rahmenbedingungen, die späteren Nutzer liefern die Abläufe. Ein externer Partner kann beim Strukturieren helfen, sollte aber nicht die Inhalte vorgeben. Wer das Lastenheft vom späteren Anbieter schreiben lässt, bekommt oft Anforderungen, die zufällig genau zu dessen Lösung passen.

Typische Fehler im Lastenheft

• Technik statt Bedarf. „Die Software soll mit React gebaut werden“ ist keine fachliche Anforderung. Vorgaben dieser Art gehören nur dann hinein, wenn die eigene IT sie tatsächlich verlangt, und dann unter Rahmenbedingungen.
• Fließtext statt Liste. Anforderungen, die in Absätzen versteckt sind, lassen sich weder priorisieren noch abnehmen.
• Keine Priorität. Wenn alles MUSS ist, schätzt jeder Anbieter den vollen Umfang und das Angebot wird teurer als nötig.
• Fehlende Mengengerüste. Ob zehn oder zehntausend Nutzer, ob ein Standort oder zwölf, ändert Architektur und Preis grundlegend.
• Keine Abgrenzung. Was nicht ausgeschlossen ist, gilt später schnell als mitbestellt. Daraus entsteht Scope Creep.

Wie das Lastenheft den Angebotsvergleich trägt

Ein Lastenheft geht in der Regel an mehrere Anbieter. Jeder antwortet mit einem Angebot oder einem ersten Lösungsentwurf. Vergleichbar werden diese Antworten erst, wenn alle auf dieselben nummerierten Anforderungen Bezug nehmen. Dann lässt sich Anforderung für Anforderung prüfen, wer was abdeckt, wo ein Anbieter Annahmen trifft und wo er Punkte stillschweigend weglässt.

Eine einfache Vergleichstabelle reicht: Anforderungsnummern als Zeilen, Anbieter als Spalten, je Zelle „abgedeckt“, „teilweise“ oder „nicht enthalten“. Große Preisunterschiede erklären sich dabei oft nicht durch Stundensätze, sondern durch unterschiedliche Annahmen zum Umfang. Welche Faktoren den Preis sonst treiben, beschreiben wir im Beitrag zu Kosten von Individualsoftware.

Häufige Fragen

Was gehört in ein Lastenheft für Software?

Ausgangslage und Ziel, Ist- und Soll-Zustand, nummerierte fachliche Anforderungen mit Priorität, Qualitätsanforderungen, Rahmenbedingungen und Schnittstellen, eine Abgrenzung sowie Lieferumfang, Abnahme und Rahmen für Zeit und Budget. Technische Lösungen gehören nicht hinein.

Wer erstellt das Lastenheft?

Der Auftraggeber. Nach DIN 69901-5 enthält es die vom Auftraggeber festgelegten Forderungen an die Leistungen des Auftragnehmers. Fachabteilung, IT und spätere Nutzer liefern die Inhalte, ein externer Partner kann beim Strukturieren helfen.

Ist das Lastenheft Teil des Vertrags?

In der Regel ja. Das Lastenheft wird vom Auftraggeber erstellt und ist üblicherweise Bestandteil des Vertrags oder der Ausschreibung (LMU München, 01/2017; wiki.induux.de). Deshalb sollten Anforderungen so formuliert sein, dass sie sich bei der Abnahme eindeutig prüfen lassen.

Braucht ein agiles Softwareprojekt ein Lastenheft?

Ja, aber ein schlankeres. Ziel, Nutzergruppen, Rahmenbedingungen, Abgrenzung und die wichtigsten MUSS-Anforderungen sollten auch in einem agilen Projekt vor dem Start feststehen. Die Details entstehen dann im Backlog. Wie sich ein erster Umfang sinnvoll zuschneiden lässt, zeigt der Beitrag zum MVP.

Der nächste Schritt

torck liest Lastenhefte aus Sicht der Entwicklung und stellt die Rückfragen, bevor sie im Angebot zu Annahmen werden. Unsere Teams in Maxhütte-Haidhof, Wien und Rabat bauen Software, Daten- und KI-Lösungen für Industrie und Handel, mit der torck GmbH als deutschem Vertragspartner. Im Erstgespräch gehen wir Ihr Lastenheft oder Ihre ersten Anforderungen gemeinsam durch.