Das Problem: Warum Requirements Engineering entscheidend ist
Die Statistik zeigt ein düsteres Bild: Die Mehrheit der Softwareprojekte hat Probleme oder scheitert. Einer der Hauptgründe dafür sind unzureichende Anforderungen. Ein systematischer Ansatz zur Erhebung, Verwaltung und Abstimmung von Anforderungen ist daher kein Luxus, sondern eine Notwendigkeit für den Projekterfolg.
Erfolgsquote von Projekten
Nur etwa ein Drittel der Projekte ist uneingeschränkt erfolgreich. Der Rest ist verspätet, überschreitet das Budget oder wird komplett abgebrochen.
Hauptgründe für Projektprobleme
-
Unzureichende Prozesse
Fehlende oder unklare Vorgehensweisen führen zu Chaos und Ineffizienz.
-
Unklare Verantwortungen
Wenn nicht klar ist, wer wofür zuständig ist, fallen wichtige Aufgaben durchs Raster.
-
Unzureichende Anforderungen
Der wichtigste Grund: Wenn die Anforderungen fehlen, falsch oder unklar sind, wird das falsche Produkt gebaut.
Der klassische Ansatz: Die drei Dimensionen des RE
Klassisches Requirements Engineering (RE) lässt sich in drei Kernaktivitäten unterteilen, die ineinandergreifen. Ziel ist es, von vagen, individuellen Ideen zu einem vollständigen, abgestimmten und regelkonform dokumentierten Satz von Anforderungen zu gelangen.
Ein 3D-Modell zur Visualisierung der Kernaktivitäten.
1. Erhebung
Das Sammeln von Anforderungen aus verschiedenen Quellen (Stakeholder, Dokumente, bestehende Systeme) durch Techniken wie Interviews, Workshops oder Beobachtung.
2. Dokumentation
Das Festhalten der erhobenen Anforderungen in einer klaren, verständlichen und unzweideutigen Form, z.B. durch Use Cases, Modelle oder strukturierte Sprache.
3. Verhandlung & Abstimmung
Das Auflösen von Konflikten zwischen den Anforderungen verschiedener Stakeholder, die Priorisierung und das Erreichen eines Konsenses über den finalen Anforderungskatalog.
Der agile Ansatz: Gespräche, Stories & kontinuierliche Pflege
Agiles RE bricht mit der Idee eines großen, vorab erstellten Anforderungsdokuments. Stattdessen setzt es auf kontinuierliche Kommunikation, progressive Verfeinerung und einen flexiblen Anforderungs-Workflow, der oft durch User Stories und ein Product Backlog repräsentiert wird.
Card
📇
Eine User Story auf einer Karte (oder einem digitalen Ticket) dient als Platzhalter und Versprechen für ein zukünftiges Gespräch.
Conversation
💬
Das eigentliche Herzstück: Der kontinuierliche Dialog zwischen Entwicklern, Product Owner und Stakeholdern, um ein gemeinsames Verständnis zu schaffen.
Confirmation
✅
Die Akzeptanzkriterien, die definieren, wann eine Story erfolgreich umgesetzt ist. Sie machen die Anforderung konkret und testbar.
Das Product Backlog als Pipeline
Anforderungen fließen durch eine Pipeline. Große, vage Ideen (Epics) werden am Anfang eingefügt und durch kontinuierliche Pflege (Grooming) in kleinere, sprint-bereite Stories zerlegt.
Über Anforderungen hinaus: Innovation durch Verstehen
Moderne Ansätze wie Design Thinking und Lean Startup argumentieren, dass unsere Aufgabe nicht nur das Sammeln von Anforderungen ist, sondern das Verändern der Welt. Der Fokus verschiebt sich vom reinen "Was" zum tiefen Verständnis des "Warum" und "Für Wen". Es geht darum, Hypothesen aufzustellen und diese schnell mit echten Nutzern zu validieren.
🤔
1. Hineinfühlen & Definieren
Verstehe die Probleme und Bedürfnisse der Nutzer durch Beobachtung und Gespräche. Fokussiere dich auf ein Kernproblem.
💡
2. Ideenfindung & Prototyp
Entwickle viele mögliche Lösungen und baue einen einfachen Prototyp (MVP - Minimum Viable Product) für die riskanteste Annahme.
🧪
3. Testen & Lernen
Teste den Prototyp mit echten Nutzern. Miss die Ergebnisse, lerne daraus und passe deine Idee an. Wiederhole den Zyklus.
Minimiere den Output, maximiere den Outcome und den Impact!