Anforderungsanalyse und Design trennen?

„Bitte lasst uns in Ruhe arbeiten“, „Bitte mischt euch nicht in die technischen Fragen ein“ sagen oft Entwickler*innen. „Zu technischen Fragen kann ich nichts sagen“, „Bitte klärt die technischen Fragen ohne mich“ sagen oft Anwender*innen.

„Die IT soll machen, was man ihr sagt“, so der O-Ton schon in mehreren Projekten, an denen ich in verschiedenen Rollen beteiligt war. „Die IT ist ein Dienstleister“ ist nicht zufällig eines der 12 Kapitel meines Buches „12 Halbwahrheiten über IT-Projekte„.

Im Grunde genommen sind solche Statements eine Manifestation des Wasserfallmodells, das auch in offiziell agilen Projekten immer noch das Denken vieler Stakeholder bestimmt. Aus dem großen Wasserfall werden viele kleine Wasserfälle, es ist nur deren Scope reduziert worden auf Sprints oder oft sogar auf User-Stories. Das ist kein wirklicher Fortschritt und die Ergebnisse sind dementsprechend bescheiden.

User-Stories beseitigen Barrieren, fördern aber Oberflächlichkeit

An sich ist das Konzept der User-Stories positiv zu werten. Ich habe schon erlebt, dass Entwicklerteams dafür eintraten, die Anwender*innen mögen doch UML oder BPMN lernen und damit die Anforderungen gleich in einem Format liefern, dass direkt umsetzbar ist. Im Vergleich dazu sind User-Stores ein Schritt in die gegenteilige Richtung. Die Anforderungen werden weitgehend entformalisiert. User-Stories sind daher ein guter Start in den Prozess der Anforderungsanalyse, aber sie dürfen nicht deren Endpunkt sein. Es ist bedauerlich, dass vor allem unter dem Einfluss von Scrum die existierende Vielfalt an möglichen Formen der Anforderungsdefinition in der Praxis verloren gegangen ist.

IREB etwa nennt eine bemerkenswerte Vielfalt an Formaten zur Definition von Anforderungen, darunter auch die in agilen Teams meist als veraltet angesehenen Lasten- und Pflichtenhefte:

User Stories:

• Beschreibung: User Stories sind kurze, einfache Beschreibungen einer Funktion oder eines Features aus der Sicht eines Endnutzers oder Stakeholders. Sie folgen oft der Struktur: „Als [Nutzerrolle] möchte ich [Ziel/Wunsch], um [Nutzen].“
• Verwendung: User Stories werden häufig in agilen Projekten verwendet und dienen als Grundlage für die Planung und Priorisierung von Entwicklungsaufgaben. Sie sind in der Regel bewusst kurz gehalten und werden während der Entwicklung weiter verfeinert.

Epics:

• Beschreibung: Epics sind große, grobgranulare Anforderungen oder Funktionen, die oft in mehrere User Stories unterteilt werden können. Sie dienen als eine Art Sammelpunkt für umfangreiche Features oder größere Geschäftsziele, die über einen längeren Zeitraum hinweg entwickelt werden.
• Verwendung: Epics werden genutzt, um eine übergeordnete Vision oder ein Ziel zu beschreiben, das später in kleinere, handhabbare Teile (User Stories) zerlegt wird. Sie bieten einen Überblick und helfen dabei, den Kontext für die nachfolgenden User Stories zu schaffen.

Anwendungsfälle (Use Cases):

• Beschreibung: Anwendungsfälle beschreiben detailliert, wie ein Nutzer (Akteur) mit einem System interagiert, um ein bestimmtes Ziel zu erreichen. Sie umfassen sowohl den normalen Ablauf als auch alternative Szenarien und Fehlerszenarien.
• Verwendung: Use Cases werden eingesetzt, um komplexe Interaktionen zwischen Nutzern und Systemen präzise zu erfassen und dienen als Grundlage für die Systemmodellierung und Testfallentwicklung.

Szenarien:

• Beschreibung: Szenarien sind narrative Beschreibungen konkreter Nutzungssituationen. Sie skizzieren mehr oder minder formalisiert typische Abläufe und zeigen, wie das System in bestimmten Situationen genutzt wird.
• Verwendung: Szenarien eignen sich besonders gut, um Anforderungen verständlich zu machen und die User Experience zu erfassen. Sie unterstützen das Verständnis komplexer Anforderungen und deren Auswirkungen.

Lastenheft:

• Beschreibung: Ein Lastenheft dokumentiert alle Anforderungen aus Sicht des Auftraggebers. Es beschreibt, was das zu entwickelnde System leisten soll, ohne dabei eine Lösung vorzugeben.
• Verwendung: Das Lastenheft dient als Ausgangspunkt für die Erstellung des Pflichtenhefts und ist ein zentrales Dokument in der Vertragsgestaltung zwischen Auftraggeber und Auftragnehmer.

Pflichtenheft:

• Beschreibung: Im Pflichtenheft werden die Anforderungen des Lastenhefts detailliert spezifiziert und konkretisiert, um die technische Umsetzung zu beschreiben. Es enthält Lösungsvorschläge, technische Spezifikationen und beschreibt, wie die Anforderungen erfüllt werden sollen.
• Verwendung: Das Pflichtenheft dient der Abstimmung zwischen den technischen Teams und dem Auftraggeber und bildet die Grundlage für die Systementwicklung und das Projektmanagement.

Prototypen:

• Beschreibung: Prototypen sind frühe, oft vereinfachte Versionen eines Systems oder von Teilen eines Systems. Zur Klärung des User-Interface werden oft Wireframes verwendet.
• Verwendung: Prototypen werden genutzt, um Anforderungen zu validieren und Missverständnisse frühzeitig zu klären. Sie sind besonders hilfreich, um Feedback von Stakeholdern zu sammeln und die Anforderungen iterativ zu verfeinern.

Zustandsdiagramme:

• Beschreibung: Zustandsdiagramme visualisieren die Zustände eines Systems und die Übergänge zwischen diesen Zuständen in Reaktion auf Ereignisse.
• Verwendung: Sie werden verwendet, um die dynamischen Aspekte eines Systems zu modellieren, insbesondere in Systemen, bei denen Zustandsänderungen eine wichtige Rolle spielen.

Mir sind alle Formen der Informationsübermittlung willkommen, in einem ersten Schritt sollte man diese in der Art akzeptieren, die der Denkweise und Terminologie der betreffenden Stakeholder am nächsten ist, andernfalls man gleich einen problematischen Filter einbaut. Oft habe ich erlebt, dass etwas als neue Anforderung gewertet wurde, was einfach vorher nicht zur Sprache kam, weil ein bestimmtes Format der Anforderungsdefinition vorgegeben war. Und ganz allgemein hat der alte Satz „Ein Bild sagt mehr als tausend Worte“ auch in Bezug auf User-Stories Gültigkeit. Manche Informationen lassen sich nur mit Bildern und relativ komplexer Prosa nachvollziehbar beschreiben.

Dass Story-Points eine nützliche Annäherung an die Ermittlung des Aufwandes sind, bleibt unbestritten. Aber auch hier gilt, dass es nur ein Einstieg sein kann und man dabei nicht stehen bleiben darf.

Die Anforderungen müssen als verschiedenen Perspektiven betrachtet werden

Laut den UML-Standards müssen bei der Modellierung von Anforderungen fünf verschiedene Perspektiven berücksichtigt werden:

1. Anwender-Perspektive (User’s Perspective):

– Fokussiert auf die Bedürfnisse und Ziele der Endnutzer des Systems.

– Beschreibt die Funktionalitäten, die der Anwender vom System erwartet.

2. Geschäfts-Perspektive (Business Perspective):

– Betrachtet die Anforderungen aus Sicht der Geschäftsprozesse und Strategien.

– Stellt sicher, dass das System die Geschäftsziele unterstützt.

3. Aufgaben-Perspektive (Task Perspective):

– Konzentriert sich auf die Abläufe und Aktivitäten, die das System unterstützen soll.

– Beschreibt, wie Benutzer mit dem System interagieren.

4. Implementierungs-Perspektive (Implementation Perspective):

– Betrachtet die technischen Anforderungen und Randbedingungen der Systemarchitektur.

– Stellt sicher, dass die Anforderungen technisch umsetzbar sind.

5. Umgebungs-Perspektive (Environment Perspective):

– Berücksichtigt externe Faktoren wie Gesetze, Regulierungen, Branchenstandards usw.

– Stellt sicher, dass das System mit den relevanten Rahmenbedingungen konform ist.

User-Stories adressieren die Anwender-Perspektive und wie schon gesagt, ist es sehr begrüßenswert, dass die formalen Einstiegshürden für die Formulierung von Anforderungen dadurch niedrig gehalten werden. Aber wie sollen aus einer User-Story die anderen Perspektiven abgeleitet werden, ohne wesentlich aufwändigere Darstellungsformen (siehe IREB oben) zu nutzen?

Die INVEST-Kriterien kritisch beleuchtet

Ein weit verbreitetes Konzept zur Bewertung von User-Stories (nicht zuletzt dank SAFe) sind die Kriterien, die mit dem Akronym INVEST zusammengefasst werden:

1. Independent (Unabhängig): Eine User-Story sollte unabhängig von anderen Stories sein und für sich selbst stehen können. Dadurch wird die Priorisierung und Planung erleichtert.
2. Negotiable (Verhandelbar): Die Details einer User-Story sollten noch nicht vollständig ausgearbeitet sein. Das ermöglicht es, gemeinsam mit dem Kunden die Anforderungen zu verfeinern und anzupassen.
3. Valuable (Wertvoll): Eine User-Story sollte einen messbaren Mehrwert für den Kunden oder Endnutzer bieten. Sie sollte einen konkreten Nutzen erfüllen und nicht nur technische Umsetzung sein.
4. Estimable (Schätzbar): Der Aufwand zur Umsetzung einer User-Story sollte grob geschätzt werden können. Dies erleichtert die Planung und Priorisierung im Rahmen des Projekts.
5. Small (Klein): Eine User-Story sollte möglichst klein und in sich abgeschlossen sein. Große, komplexe Stories werden in mehrere kleinere Stories aufgeteilt. Kleine Stories sind leichter zu verstehen, zu schätzen und umzusetzen.
6. Testable (Testbar): Eine User-Story sollte so definiert sein, dass ihre Umsetzung getestet werden kann. Das erleichtert die Überprüfung, ob die Story vollständig umgesetzt wurde.

Meiner Meinung nach sind die Kriterien 1 und 4 nur beurteilbar, wenn man schon einiges an Analyseaufwand investiert hat. Abhängigkeiten zwischen Anforderungen können aufgrund jeder der 5 UML-Perspektiven bestehen und sind daher auf Grundlage der Anwender-Perspektive allein nicht erkennbar. Und was die Schätzbarkeit anbelangt, so ist es mir immer schon und immer noch ein Rätsel, wie man den Aufwand auf Grundlage von Epics und User-Stories ermitteln kann. Der tatsächliche Aufwand für die Umsetzung von funktionalen Anforderungen (diese sind in User-Stories grob beschrieben) hängt von so vielen Faktoren ab, die zu einem großen Teil völlig unabhängig vom fachlichen Inhalt wirken. Hier eine Liste ohne Anspruch auf Vollständigkeit.

INVEST ist eine sinnvolle Kriterienliste, allerdings muss man sie als perspektivischen Arbeitsauftrag verstehen, nicht als Checkliste, die man nach Vorliegen von User-Stories oder anderen Anforderungsbeschreibungen abhaken kann.

Es geht nur interaktiv und iterativ

Ich möchte an dieser Stelle und abschließend Dean Leffingwell als Autoriät heranziehen, denn er hat die Antwort auf meine Eingangsfrage in seinem Standardwerk schon 2011 auf den Punkt gebracht. Ich übernehme es 1:1.

Und damit sind wir wieder bei den Empfehlungen, die ich schon früher am Beispiel von Max Verstappen und Adrian Neweybeschrieben habe.