Lastenheft für Software - was gehört wirklich hinein?
Problemstellung bei der Erstellung von Lastenheften
Bevor eine Software eingeführt wird, entsteht in den meisten Projekten ein Dokument, das den weiteren Verlauf entscheidend prägt: das Lastenheft.
In der Praxis sehen wir dabei immer wieder zwei Extreme: Entweder enthält das Lastenheft mehrere hundert Einzelanforderungen aus alten Excel-Listen und dem bisherigen System. Oder es bleibt so allgemein formuliert, dass sich jeder Anbieter beliebig hineininterpretieren lässt.
Beide Varianten führen später zu denselben Problemen: schwer vergleichbare Angebote, unklare Abnahmekriterien und endlose Diskussionen darüber, was eigentlich gemeint war.
Welche Fragen beantwortet ein Lastenheft?
Ein tragfähiges Lastenheft beantwortet drei Fragen:
1. Was soll die Software fachlich erreichen?
2. Wie konkret müssen die Anforderungen formuliert sein?
3. Welche Anforderungen haben tatsächlich Priorität?
Bei der dritten Frage entstehen in Projekten erfahrungsgemäß die größten Konflikte. Dazu später mehr.
Zentrale These:
Ein gutes Lastenheft beschreibt nicht möglichst viele Anforderungen. Es schafft eine belastbare Grundlage für Entscheidungen, Umsetzung und Abnahme.
Dieser Beitrag ist Teil 4 unserer Reihe „Software erfolgreich einführen". Er richtet sich an CIOs, CTOs, CISOs, Programmleiter und Transformationsverantwortliche, die vor der Definition von Software-Anforderungen stehen – insbesondere in regulierten Branchen wie Banken, Börsenbetreibern und Unternehmen der kritischen Infrastruktur.
Was ist ein Lastenheft, was ist ein Pflichtenheft?
Ein beschreibt aus Sicht des Auftraggebers, was erreicht werden soll.
Wie ein Anbieter das technisch umsetzt, gehört in ein Pflichtenheft.
Lastenheft:
-Perspektive: Auftraggeber
-Inhalt: Fachliche Anforderungen, Ziele, Scope
-Zeitpunkt: Vor Anbieterauswahl
-Zweck: Bewertungs- und Entscheidungsgrundlage
Pflichtenheft:
-Perspektive: Anbieter
-Inhalt: Technischer Lösungsweg
-Zeitpunkt: Nach Zuschlag
-Zweck: Schaffung Umsetzungsgrundlage
Wenn bereits Bildschirmmasken, Datenfelder oder konkrete Workflow-Schritte im Lastenheft stehen, wird eine Lösung vor Ausschreibung der Software vorweggenommen, bevor die eigentliche fachliche Anforderung geklärt ist. Der Anbieter verliert damit genau den Spielraum, den er bräuchte, um die beste technische Lösung für das fachliche Ziel vorzuschlagen.
Ein Lastenheft ist damit kein technisches Dokument. Es ist ein Entscheidungsdokument – für die Bewertung von Anbietern, für die Umsetzung im Projekt und für die spätere Abnahme.
Was gehört in ein Lastenheft?
Leitfrage 1: Was soll die Software fachlich erreichen?
Die erste Frage betrifft das eigentliche Ziel: Was soll die Software fachlich erreichen? Dazu gehören:
1) das angestrebte Business Outcome
2) der fachliche Scope
3) die wichtigsten Use Cases
4) regulatorische und fachliche Anforderungen, die zwingend erfüllt sein müssen
5) Mögliche Deadlines für die Umsetzung der regulatorischen Anforderungen (in Vorbereitung auf Leitfrage 3)
Bei einer GRC-Einführung kann dieses Ziel zum Beispiel lauten: kritische Geschäftsprozesse inklusive Verantwortlichkeiten, Risiken und Kontrollen zentral steuerbar machen. Aus diesem Ziel lassen sich Scope und konkrete Anforderungen ableiten – nicht umgekehrt. Wird stattdessen direkt mit einer Funktionsliste begonnen, fehlt später die Grundlage, um zu bewerten, ob eine einzelne Anforderung überhaupt zum Ziel beiträgt. Zu einem klaren Scope gehört ebenso, was bewusst nicht Teil der Lösung ist. Ein vorhandenes System zur Kritikalitätsbewertung etwa muss nicht nachgebaut werden, wenn es sich sauber über eine Schnittstelle anbinden lässt.
Wie solche Scope-Entscheidungen zwischen Standard und Customizing getroffen werden, haben wir in Teil 2 dieser Reihe vertieft.
Leitfrage 2: Wie konkret müssen Anforderungen sein?
Die zweite Frage betrifft den Konkretisierungsgrad – und ist in der Praxis eine der häufigsten Fehlerquellen bei der Softwareauswahl.
Eine Anforderung muss präzise genug sein, um von einem Anbieter bewertet, im Projekt umgesetzt und später abgenommen zu werden. Gleichzeitig sollte sie die technische Lösung nicht bereits vorwegnehmen.
Beispiel für eine zu unpräzise Anforderung:„Das System soll Risiken verwalten können." Damit kann praktisch jeder Anbieter zustimmen – und trotzdem am eigentlichen Bedarf vorbeigehen. Konkreter formuliert:„Risiken oberhalb eines definierten Schwellenwerts müssen automatisiert an eine zusätzliche Freigabeinstanz eskaliert werden, inklusive Nachweisführung." Diese Formulierung ist bewertbar, umsetzbar und später überprüfbar – ohne bereits festzulegen, wie die Eskalation technisch gelöst wird. Bei komplexeren Anforderungen bedeutet ausreichende Präzision häufig, die fachlichen Objekte und ihre Pflichtinformationen zu benennen. Dass ein Dienstleister durchgängig mit seinen Unterauftragnehmern verknüpft sein muss, auch über mehrere Ebenen hinweg, ist eine fachliche Anforderung.
Wie diese Verknüpfung technisch in Datenbank und Bildschirmmaske umgesetzt wird, bleibt Sache des Anbieters.
Der Praxistest: Können zwei unabhängige Anbieter dieselbe Anforderung lesen und zu einer vergleichbaren Lösung kommen? Wenn ja, ist der Konkretisierungsgrad richtig gewählt.
Leitfrage 3: Wie priorisiert man Anforderungen?
Die dritte Frage entscheidet in der Praxis am häufigsten über den späteren Projekterfolg, und sorgt erfahrungsgemäß für die größten Konflikte im Projektteam.
Bei der Priorisierung im Anforderungsmanagement unterscheiden wir mehrere Kategorien:
- Must-have-Anforderungen – ohne die die Lösung ihr Ziel nicht erreicht
- Regulatorisch zwingend erforderliche Anforderungen
- Anforderungen mit Standard Fit – bereits über Plattformstandard abgedeckt
- Differenzierende Anforderungen – die tatsächlich einen Unterschied machen
- Lifecycle-Kosten – der Betriebs- und Wartungsaufwand, den eine Anforderung über Jahre erzeugt
Der letzte Punkt wird regelmäßig unterschätzt. Eine Anforderung, die im Projekt sinnvoll wirkt, kann über Jahre erheblichen Wartungs- und Betriebsaufwand erzeugen. Diese Build-und-Run-Betrachtung haben wir in Teil 3 dieser Reihe ausführlich behandelt. Priorisierung heißt deshalb nicht, möglichst viele Anforderungen als wichtig einzustufen. Priorisierung heißt, für jede Anforderung eine begründete Antwort auf die Frage zu haben: Warum genau diese Kategorie?
Praxisbeispiel: Vom Excel-Katalog zum Lastenheft (im IKT Drittdienstleistermanagement nach DORA [Digital Operational Resilience Act])
Ein Beispiel aus einem Themenfeld, das aktuell viele regulierte Unternehmen beschäftigt: das Management von IKT-Drittdienstleistern nach DORA (Third Party Risk Management, TPRM).
Solche Prozesse laufen in vielen Häusern noch über eine Vielzahl einzelner Excel-Arbeitsmappen – eine für die Risikobewertung, eine für den Status je Dienstleister, eine für den Abgleich mit der Kritikalität aus der Business Impact Analyse, sowie teilweise noch flankiert via diverse Word-Dokumente.
Das Ergebnis: Medienbrüche, hoher manueller Pflegeaufwand und Risiken bei der Datenkonsistenz – und das, obwohl die Daten am Ende in ein aufsichtliches Register (DORA-Informationsregister, "Register of Information") münden müssen. Die entscheidende Aufgabe im Lastenheft ist dann nicht, jede bestehende Excel-Spalte eins zu eins in ein neues System zu übertragen.
->Die Aufgabe ist, daraus ein fachliches Zielbild zu entwickeln:
Welche Objekte – Dienstleister, Vertrag, Risikobewertung, Registereintrag – gehören zusammen, und welche Informationen sind für die aufsichtliche Meldung tatsächlich Pflicht? Das ist derselbe Grundsatz, den wir in Teil 3 zu Standard und Customizing besprochen haben: Historische Strukturen sind eine Informationsquelle. Sie sind noch keine Zielarchitektur.
Aus dieser Analyse entsteht ein Anforderungskatalog, der jede Anforderung einer Kategorie zuordnet – etwa nach dem verbreiteten MoSCoW-Prinzip: Muss, Soll, Kann. Die eigentliche Arbeit steckt dabei nicht in der Kategorisierung selbst, sondern in der Begründung dahinter: Ist eine Anforderung Pflicht, weil die Aufsicht sie verlangt? Oder nur, weil sie sich bislang so eingespielt hat?
Bei ACONO greifen wir für solche Anforderungsanalysen – ob im Kontext von DORA-Third-Party-Risk-Management oder im breiteren Anforderungsmanagement für GRC-Software wie TopEase – auf standardisierte Lastenheftstrukturen und Reference Assets aus unserer internen GRC Content Zone zurück. Das beschleunigt die Strukturierung und macht Projekterfahrung aus früheren Einführungen wiederverwendbar.
Das Lastenheft im Gesamtprozess
Bei ACONO strukturieren wir Anforderungsanalysen mit unserem RegRISE Framework – von der Regulatory Intelligence über die Nutzung vorhandener Reference Assets bis zur Übersetzung in Architektur und Delivery.
Das Lastenheft ist dabei kein isoliertes Dokument. Es ist die Schnittstelle zwischen dem Solution Design (siehe Teil 3) und der eigentlichen Softwareauswahl.
Häufige Fragen zu Lastenheften
Was ist der Unterschied zwischen Lastenheft und Pflichtenheft?
Das Lastenheft beschreibt aus Sicht des Auftraggebers, was eine Software erreichen soll. Das Pflichtenheft beschreibt aus Sicht des Anbieters, wie diese Anforderungen technisch umgesetzt werden. Das Lastenheft entsteht vor der Anbieterauswahl, das Pflichtenheft danach.
Was gehört in ein Lastenheft für Software?
Ein belastbares Lastenheft beantwortet drei Fragen: das angestrebte Business Outcome und den fachlichen Scope, den notwendigen Konkretisierungsgrad der einzelnen Anforderungen sowie deren Priorisierung – etwa nach Must-have, regulatorischer Notwendigkeit, Standard Fit, Differenzierung und Lifecycle-Kosten.
Wie priorisiert man Anforderungen im Lastenheft?
Verbreitet ist das MoSCoW-Prinzip (Must, Should, Could, Won't).
Entscheidend ist dabei nicht die Kategorisierung selbst, sondern die Begründung: Warum ist eine Anforderung tatsächlich „Must-have" – regulatorisch, fachlich oder nur historisch gewachsen?
Bildquelle des Beitrages: Unsplash.com