Lastenheft für Software: So schreiben Sie es, damit Angebote vergleichbar werden

Sie schicken dieselbe Idee in einer E-Mail mit zwei Absätzen an drei Anbieter. Zurück kommen 25.000 €, 70.000 € und 140.000 €. Keiner liegt falsch. Jeder hat ein anderes System kalkuliert: das, das er sich beim Lesen Ihrer E-Mail vorgestellt hat.

Ein Lastenheft löst das. Es ist keine Bürokratie. Es ist der günstigste Weg, damit alle dasselbe anbieten und Sie das System bekommen, das Sie im Kopf hatten.

Die Zahlen bestätigen das. In einer Studie des Project Management Institute war unzureichendes Anforderungsmanagement fast in der Hälfte der Fälle (47 %) die Hauptursache, wenn Projekte ihre Ziele verfehlten, und 5,1 % jedes in Projekte investierten Dollars gingen dadurch verloren.

Was ein Lastenheft ist und was nicht

Es beschreibt, was das System leisten muss und wofür. Nicht wie. Das Wie ist die Aufgabe des Anbieters, und ihm Raum für einen eigenen Lösungsvorschlag zu lassen, ist einer der Gründe, warum Sie ihn bezahlen.

Nach DIN 69901-5 ist das Lastenheft die vom Auftraggeber festgelegte Gesamtheit der Forderungen an die Lieferungen und Leistungen des Auftragnehmers. Der Auftragnehmer antwortet mit dem Pflichtenheft: wie und womit er die Anforderungen umsetzt. International beschreibt ISO/IEC/IEEE 29148 das Anforderungsmanagement im Detail.

Für ein mittelständisches Unternehmen brauchen Sie keine hundert Seiten. Fünf bis fünfzehn Seiten, die die richtigen Fragen beantworten, reichen.

Was in das Lastenheft gehört

Abschnitt	Welche Frage er beantwortet	Beispiel
Ziel	Wozu das System, und woran Sie den Erfolg messen	“Drei Personen tippen täglich zwei Stunden Bestellungen aus E-Mails ab. Ziel: unter 30 Minuten.”
Ist-Zustand	Wie es heute läuft, mit welchen Werkzeugen	“Bestellungen kommen per E-Mail und Excel und werden von Hand ins ERP übertragen.”
Benutzer und Rollen	Wer es nutzt und was er darf	“Der Vertrieb legt Bestellungen an, das Lager bestätigt sie, Admins sehen alles.”
Prozesse	Die Hauptabläufe, Schritt für Schritt	“Bestellung kommt an, Bestand wird geprüft, Bestellung wird bestätigt, Rechnung geht raus.”
Daten	Welche Daten, woher, wie viele	“Rund 300 Bestellungen am Tag und 5.000 Kunden, aus dem ERP importiert.”
Schnittstellen	Mit welchen Systemen es sprechen muss	“ERP über die REST-API, E-Mail, Buchhaltung.”
Nichtfunktionale Anforderungen	Geschwindigkeit, Sicherheit, Verfügbarkeit, Datenschutz, Geräte	“Anmeldung über Microsoft 365, Daten in der EU, läuft auf dem Tablet im Lager.”
Abnahmekriterien	Woran Sie prüfen, dass es fertig ist	“Eine Bestellung aus einer E-Mail ist innerhalb von fünf Minuten ohne manuelle Eingabe im ERP.”
Lieferumfang	Was außer dem Code dazugehört	“Schulung, Dokumentation, Übergabe, die ersten drei Monate Support.”
Prioritäten	Was in die erste Version muss	Muss, Soll, Kann

Prüfbare Anforderungen formulieren

Die häufigste Schwäche ist eine Anforderung, die niemand prüfen kann. “Schnell” bedeutet für Sie etwas anderes als für den Anbieter oder für einen Anwender mit langsamer Verbindung. Jede Anforderung sollte bei der Abnahme testbar sein:

Unklar	Prüfbar
Das System muss schnell sein	Die Bestellliste lädt mit 10.000 Bestellungen in unter zwei Sekunden
Benutzerfreundlich	Ein neuer Lagermitarbeiter bestätigt eine Bestellung ohne Schulung in unter einer Minute
Sicher	Anmeldung über Microsoft 365 mit Zwei-Faktor-Authentifizierung; jede Änderung an einer Bestellung wird mit Benutzer und Zeit protokolliert
Anbindung an das ERP	Neue Bestellungen sind innerhalb von fünf Minuten im ERP; ist das ERP nicht erreichbar, wird erneut gesendet und ein Admin benachrichtigt

Was nicht hineingehört

• Masken bis aufs Pixel, außer es kommt wirklich darauf an. Beschreiben Sie, was der Anwender tun muss, nicht wo der Button sitzt.
• Technologievorgaben ohne Grund. Wenn es einen gibt, schreiben Sie ihn auf: “muss auf unserem SQL Server laufen”, “unser Team betreut .NET”. Sonst lassen Sie die Anbieter vorschlagen.
• Jede Ausnahme im ersten Entwurf. Markieren Sie stattdessen offene Fragen. Ein guter Anbieter fragt nach, und die Antworten machen das Dokument besser.

Muss, Soll, Kann

Versehen Sie jede Anforderung mit einer Priorität. Muss: ohne das ist das System nutzlos. Soll: wichtig, aber es gibt einen Umweg. Kann: schön zu haben.

Das bewirkt zweierlei. Die Angebote werden vergleichbar, weil alle dieselbe erste Version kalkulieren. Und Sie bekommen ein natürliches erstes Release: nur die Muss-Anforderungen, schnell in Produktion, der Rest folgt, wenn die Anwender es gesehen haben.

Wie detailliert das Lastenheft sein muss, hängt auch vom Vertrag ab. Beim Festpreis wird es Teil des Vertrags und braucht deutlich mehr Details. Mehr dazu im Artikel Festpreis oder nach Aufwand?

Lassen Sie KI den ersten Entwurf schreiben

Das Schreiben des Lastenhefts ist oft das, was ein Projekt monatelang aufhält. KI verkürzt das deutlich. Nehmen Sie ein Gespräch mit den Mitarbeitern auf, die die Arbeit heute machen, oder beschreiben Sie den Prozess in eigenen Worten, und geben Sie das zusammen mit der Tabelle oben einem KI-Assistenten. Bitten Sie um einen Entwurf und eine Liste offener Fragen.

Sie lesen und korrigieren trotzdem jede Zeile, denn nur Sie kennen Ihr Geschäft. Aber einen Entwurf zu korrigieren dauert Stunden, ein leeres Blatt zu füllen Wochen. Eine Regel: Kopieren Sie keine vertraulichen Daten in ein öffentliches Chat-Tool. Nutzen Sie die Version, die Ihr Unternehmen freigegeben hat, mit Ihren Datenschutzeinstellungen.

Wie es weitergeht

Schicken Sie dasselbe Lastenheft an drei Anbieter und bitten Sie jeden, Anforderung für Anforderung zu antworten: wie er sie lösen würde, was es kostet und was unklar ist. Diese Antwort ist das Pflichtenheft.

Vergleichen Sie dann die Antworten, nicht nur die Summen. Ein Anbieter, der gute Fragen stellt, hat das Dokument gelesen. Einer, der keine stellt, hat eine Vermutung kalkuliert. Realistische Preisspannen finden Sie in unserem Artikel Was kostet Individualsoftware?

Wie wir arbeiten

Genau hier beginnen wir oft. ProCoding ist ein .NET-Studio aus Split in Kroatien: Wir entwickeln Geschäftsanwendungen in .NET und Blazor und bringen KI in Geschäftsprozesse. In einer kurzen Analyse gehen wir Ihre Prozesse mit den Menschen durch, die sie kennen, schreiben das Lastenheft gemeinsam mit Ihnen und geben eine Schätzung in Spannen ab. Das Dokument gehört Ihnen, und Sie können es auch anderen Anbietern zur Angebotsabgabe schicken. Der erste Schritt ist ein kostenloses 30-minütiges Gespräch.

Quellen

• Requirements Management: A Core Competency for Project and Program Success, PMI’s Pulse of the Profession, Project Management Institute, August 2014
• Lastenheft, Wikipedia (Definitionen nach DIN 69901-5)
• ISO/IEC/IEEE 29148:2018, Requirements engineering, ISO