Egal ob Wasserfallmethode oder Agiles Projektmanagement: Sie brauchen zu Beginn jedes Softwareprojektes ein Lastenheft. Einziger Unterschied: Im Projekt auf Basis der Wasserfallmethode (z.B. bei einer Behörde) ist das Lastenheft der Fahrplan, bei einem agilen Projekt ist das Lastenheft eine erste Orientierung, ein Startpunkt. Niemand sollte der Illusion erliegen, in einem agilen Projekt könnte man ja „sofort loslegen“ oder „die Aufgabenstellung sei zu komplex, darum müsse mögliche Lösungsansätze mit einem IT Dienstleister erst gemeinsam entwickeln“. Wenn Sie in ihrer Organisation hören, man brauche kein Lastenheft, dann bedenken Sie dies: Niemand hat Lust auf Dokumentation von (vermeintlich!!) Selbstverständlichem, nämlich: „So funktionieren unsere Geschäftsprozesse und da wollen wir hin.“ Die Argumentation gegen ein Lastenheft könnte folglich nur vorgeschoben sein. Damit es keine Zweifel zur Relevanz des Lastenheftes gibt, nachfolgend kurz die wesentlichen Gründe.

Erstens, Sie brauchen eine inhaltliche Basis für die Auswahl eines IT Dienstleisters. Wenn Sie in einem Lastenheft nicht mindestens grob die Anforderungen, die Zielsetzung und die inhaltlichen oder technischen Herausforderungen beschreiben, wie sollen die shortlisted IT Dienstleister nachvollziehbar darlegen, welche besondere Eignung sie für ein solches Projekt mitbringen? Zweitens, selbst wenn in einem agilen Projekt der tatsächliche Entwicklungpfad von dem Lastenheft abweicht, brauchen Sie eine Grundlage in der Phase der Vertragsverhandlung zum Abstecken des Kosten-/Budgetrahmens. Ob das Vergütungsmodell am Ende als klassischer Festpreis ausgestaltet wird, Time&Material, Agiler Festpreis, Festpreis pro Sprint oder Garantierter Maximalpreis, ist dabei egal. Sie benötigen immer eine Ausgangsbasis. Drittens, gerade wenn Sie ein innovatives Softwareprojekt starten (hier ist agile Entwicklung das Mittel der Wahl), sollte unternehmensintern eine grobe Zielvision für ein Softwareprojekt bestehen, einige Leitplanken sollten also definiert werden; das erfordert erfahrungsgemäß zeitintensive Abstimmungsprozesse. Wenn Sie in einem Softwareprojekt in eine solche politische Gridlock-Phase hineinlaufen, kann das zu Frustration führen; es ist hier also empfehlenswert, diesen Prozess vorzuziehen. Das Lastenheft (wenn auch nur ein grobes Lastenheft) ist das Ergebnis.

Option Machbarkeitsstudie bei innovativen Softwareprojekten

Es gibt Fälle, wo es sich bei der Entwicklung eines Lastenheftes als sehr schwierig herausstellt, eine grobe Idee dafür zu entwickeln, was eine Software können muss. Die Ideen bleiben zu abstrakt, es herrscht Unsicherheit über technische Möglichkeiten oder zu viele konkurrierende Konzepte liegen auf dem Tisch. Dies ist nicht untypisch für innovative IT Projekte. In diesem Fall sollte erwogen werden, eine Machbarkeitsstudie im Rahmen eines 4 bis 8-wöchigen Projektes durchzuführen.

Eine solche Machbarkeitsstudie bewertet verschiedene Ideen aus technischer Sicht, ein kleiner Prototyp vermittelt eine greifbare Vorstellung für einen konkreten Lösungsansatz eines Kernprozesses und vielleicht lassen sich sogar konkurrierende Ideen technisch miteinander versöhnen. Entscheidend ist, dass alle relevanten Stakeholder für eine Machbarkeitsstudie an einen Tisch kommen, so dass sich der Softwaredienstleister ein vollständiges Bild der Erwartungen und Anforderungen machen kann. Nicht nur in dieser Phase muss der IT Dienstleister einen sehr guten Moderator, einen guten Zuhörer ins Rennen schicken; in aller Regel prallen hier verschiedene Sichten auf Geschäftsprozesse aufeinander, die nur selten ein konsistentes Gesamtbild ergeben; der Ersteller der Machbarkeitsstudie (häufig gefolgt von der Erstellung eines Lastenheftes) hat hier die herausfordernde Aufgabe, diesen Austausch und Konsolidierungsprozess zu moderieren. Das erfordert sehr viel Kommunikationsgeschick und Erfahrung.

Eine Machbarkeitsstudie bedeutet im Übrigen keinen Zeitverlust, denn erforderliche Klärungsprozesse stehen früher oder später sowieso an. Ob diese zu Beginn eines Projektes bzw. vor der Initiierung eines Projektes stattfinden oder mittendrin macht für die Gesamtdauer des Projektes bis zum Abschluss keinen Unterschied. Im worst case könnte ja eine Machbarkeitsstudie ergeben, dass eine ursprünglich verfolgte Idee gar nicht funktioniert – in dem Fall hat man nicht nur sehr viel Zeit gespart, sondern darüber hinaus auch sehr viel Geld.

Das Lastenheft: Welche technischen Vorgaben erforderlich sind

Eine ganze zentrale Eigenschaft des Lastenheftes vorweg: Das Lastenheft gibt dem potentiellen Auftragnehmer, dem Softwarehaus bzw. Softwareentwickler, eine gut strukturierte Orientierung darüber, was die gewünschte Software können soll und unter welchen Rahmenbedingungen die Software eingesetzt wird. Was das Lastenheft nicht enthält, ist die Vorgabe, wie diese Anforderungen technisch umgesetzt werden. Jeder, der ein Lastenheft schreibt, hat zwar sicherlich Ideen, wie er selbst bestimmte Anforderungen technisch umsetzen würde, zumal wenn die interne IT Abteilung an der Erstellung des Lastenheftes beteiligt ist. Es gilt jedoch, dass der Gesamtprozess umso mehr um die Expertise und Kreativität eines Softwareentwicklers bereichert wird, je weniger eng die technischen Vorgaben formuliert sind.

Ich arbeite permanent inmitten und mit Softwareentwicklern, bin nah an technischen Trends, und dennoch ist mir immer klar, dass der technische Möglichkeitenraum so enorm groß ist und täglich weiter wächst, dass man das als Einzelperson nicht mehr überblicken kann. Betrachten wir nur einmal die Programmiersprachen: Bis Mitte der 1990er wurden gerade mal ein halbes Dutzend davon aktiv verwendet, heute gibt es bereits Dutzende, jede mit einem Stärken-Schwächen-Profil, das nur Spezialisten in der Gesamtheit noch überblicken. Dazu kommen Low-Code-Plattformen, KI Services, die Vielfalt an No-SQL Datenbanken, der Trend zu cloud-native Applikationen (Der Technology Stack für Softwareentwicklungsprojekte im Zeitalter von Cloud-Native Companies): Haben SIE hier den vollen Überblick? Meine Erfahrung ist, dass die internen IT Abteilungen mittelständischer Unternehmen (anders als in Großunternehmen) nicht so ausgerichtet sind, dieses Überblickswissen aufzubauen und aktuell zu halten. Das ist Aufgabe des potentiellen Auftragnehmers (Softwareentwicklers), die technisch unspezifischen Anforderungen konkret mit Umsetzungsideen zu unterfüttern – nämlich im Pflichtenheft. Das ist der entscheidende Unterschied zwischen diesen beiden Dokumenten.

Natürlich, die technischen Rahmenbedingungen muss der Auftraggeber vorgeben: Auf welcher Plattform soll die Anwendung laufen, Windows, Unix, Linux? Ist ein Betrieb in einer Public Cloud oder Private Cloud denkbar? Was ist das Mengengerüst (Anzahl Geschäftsvorfälle), Anzahl der Nutzer, wie soll die Software innerhalb der nächsten 10 Jahre skalieren können (mit welchem Wachstum rechnet das Unternehmen)? Welche technischen Schnittstellen sind erforderlich (z.B. zu bestehenden ERP-Anwendungen)?

Das Lastenheft: Wer macht Was Womit Wozu

Diese technischen Rahmenbedingungen kommen natürlich erst zum Schluss. Der eigentliche Startpunkt eines Lastenheftes ist ganz klar die fachliche Perspektive. Zunächst einmal geht es um die Zielsetzung für das ausgeschriebene Softwareprojekt: Welcher Zweck soll mit der Software verfolgt werden? Soll eine bestehende Software abgelöst werden (die nicht mehr den fachlichen Anforderungen genügt), soll ein Ökosystem von eigenentwickelten MS Excel Anwendungen abgelöst oder etwa eine mobile APP für ein neues Geschäftsmodell des Auftraggebers entwickelt werden? Welche (möglichst konkret zu definierenden) Kriterien müssen erfüllt sein, damit das Projekt als erfolgreich gelten kann?

Ist dieser übergeordnete Zielrahmen abgesteckt, müssen die Anforderungen im Detail ausspezifiziert werden. Der Aufbau des Dokumentes (in der Regel: WORD-Dokument mit Anlagen) sollte so gestaltet sein, dass (a) auch ein fachfremder Leser die Anforderungen verstehen kann und (b) die Anforderungen logisch aufeinander aufgebaut werden: Die fachlichen Grundlagen werden vorangestellt, die Anforderungen werden so angeordnet, dass eine Anforderung nur die Erläuterungen und Spezifikationen aus vorangegangenen Abschnitten voraussetzt, nicht aber auf spätere Kapitel verweist (oder dies zumindest vermeidet). Das klingt selbstverständlich, in der Praxis finden sich allerdings auch immer wieder schwer lesbarer Dokumente, wo beispielsweise zunächst umfangreiche Admin-Konfigurationsoptionen spezifiziert werden, ohne vorher die fachliche Relevanz hierzu einzuführen.

Anforderungen / Spezifikationen sollten gleich nach dem MUSCOW-Prinzip kategorisiert werden, heißt: Was sind MUST-HAVE-Anforderungen, was sind SHOULD-Anforderungen, COULD und WOULD. Das ist insbesondere im Hinblick auf das Thema Ausrichtung an einem Budget-Korridor wichtig. Bisweilen ist es im Übrigen hilfreich zu formulieren, was die Software nicht können muss, oder wo Schnittstellen zu bestehenden Anwendungen erforderlich sind, die solche Funktionen bereits erfüllen. Wenn die Software beispielsweise mit einer branchenüblichen Dritt-Parteien-Bibliothek oder Webservices arbeiten soll, dann sollte dies ebenfalls formuliert werden. Ein Beispiel hierfür: Eine Dokumenten-Management-Software soll etwa das OCR-Modul von ABBYY integrieren, da dies eine besonders hohe Kundenakzeptanz genießt, ein attraktives Pricing-Modell bietet oder qualitativ führend ist.

Das Lastenheft sollte im Übrigen auch aufführen, welche Punkte noch nicht geklärt sind, gegebenenfalls unter Angaben der Gründe, so dass ein potentieller Auftragnehmer die Implikationen für den Zeitplan oder eine gegebenenfalls erforderliche Moderationsleistung abschätzen kann. Vor allem muss das Lastenheft auch angeben, welche Erweiterungen für die Zukunft möglicherweise erforderlich werden könnten oder mitgedacht sind, denn solche zukünftigen Anforderungen müssen von Anfang an in der Software-Architektur einer Anwendung berücksichtigt werden.

Der Auftraggeber sollte auch projektorganisatorische Angaben machen, sofern es hierzu spezifische Vorstellungen gibt. Welchen Zeitrahmen stellt er sich etwa vor, welche Meilensteine? Diese Erwartungshaltung erlaubt dem möglichen Auftragnehmer (Softwareentwickler), seine Kapazitätsplanung zeitplangerecht auszurichten – bei unrealistischen Erwartungen wiederum kann sich der Softwareentwickler auf die Gespräche dazu adäquat vorbereiten. Falls der Auftraggeber bereits Erwartungen zum Vergütungsmodell hat (z.B. Festpreis, Agiler Festpreis, Festpreis pro Sprint oder Garantierter Maximalpreis), dann kann dies ebenfalls formuliert werden. Gleichermaßen sollte formuliert werden, wenn Präferenzen zur Projektmanagementmethode bestehen: Möglicherweise arbeitet die Unternehmensorganisation des Auftraggebers typischerweise nach PRINCE2-Standards.

Last but not least: Insbesondere für Software, die in der Cloud bzw. im Web laufen soll, müssen Vorgaben zur Anwendungssicherheit gemacht werden; etwa das Bestehen eines vorgegebenen PEN-Tests. Mehr dazu in diesem Artikel: Erfolgsrezept für die Entwicklung Sicherer Software

Lastenheft für die Agile Softwareentwicklung

Braucht man nun wirklich ein Lastenheft für ein agiles Softwareprojekte? – Ich finde diese Frage erstaunlich. Natürlich! Das Lastenheft (ich wiederhole mich) gibt dem potentiellen Auftragnehmer eine gut strukturierte Orientierung darüber, was die gewünschte Software können soll und unter welchen Rahmenbedingungen die Software eingesetzt wird. Kurz: Die Antwort auf die Frage „Was will ich von Dir?“. Wieso sollte das in einem Agilen Softwareprojekt wegfallen?

Natürlich, in einem Agilen Softwareprojekt ist im späteren Verlauf die Rolle des Lastenheftes (bzw. dann Pflichtenheftes) eine andere: Im Wasserfallprojekt ist das Pflichtenheft das Regiebuch, an das sich der Softwareentwickler zu halten hat. In einem agilen Projekt ist das Lastenheft nur die erste Version des Backlogs, der sich im Verlauf eines Lastenheftes verändern wird, mit neuen oder angepassten Anforderungen, mit anderen Priorisierungen.

Fazit: Wir brauchen immer ein Lastenheft. Und zwar ein Gutes!