Antwort.

Geschichte der Frage

Zu Beginn eines großen Projekts bestand oft die Aufgabe, die Anforderungen möglichst schnell zu sammeln und zu strukturieren, da das Geschäft eine schnelle Markteinführung verlangte. Das führte häufig zu Formalismus und dem Verlust von Details, was die technische Schuld und die Anzahl der Nachbesserungen nach dem MVP erhöhte.

Problem

Die Hauptherausforderung ist der Ausgleich zwischen Geschwindigkeit und Qualität der Anforderungsbearbeitung. Eine oberflächliche Erhebung führt zu Fragmentierung und einer Zunahme von Änderungen in der Umsetzungsphase, während eine zu gründliche Erhebung die Arbeit verlangsamt und Marktchancen verlieren kann.

Lösung

• Bildung einer Hierarchie von Anforderungen: schnelle Erhebung von High-Level-Anforderungen mit anschließender schrittweiser Detaillierung (Rolling Wave Planning).
• Durchführung von Facilitation-Sitzungen und Workshops mit verschiedenen Stakeholdern (Design Sprint, Event Storming).
• Anwendung von Vorlagen wie User Story Mapping und Priorization Matrix, um das "Kern"-Produkt schnell zu identifizieren.
• Einführung eines transparenten Pre-Grooming-Prozesses: Bearbeitung nur der Schlüssel-Szenarien mit Kennzeichnung von Risiken und Unsicherheiten.
• Betonung von Visualisierungen (Prozesskarten, Prototypen), um Verzerrungen der Anforderungen zu minimieren.

Wesentliche Merkmale:

• Verwendung von agilen Ansätzen zur Priorisierung und schrittweisen Detaillierung von Anforderungen.
• Formalisierung von Unsicherheitsbereichen anstelle der Ignorierung unbearbeiteter Anforderungen.
• Regelmäßige Überprüfungen und Einbindung des Entwicklungsteams zur rechtzeitigen Identifizierung technischer Einschränkungen.

Trickfragen.

Kann man den Beginn der Anforderungserhebung durch den Verzicht auf die Dokumentation von nebensächlichen Szenarien beschleunigen?

Nein. Sie müssen als Risikobereiche oder unberücksichtigte Punkte festgehalten werden, sonst tauchen sie in späteren Phasen auf und führen zu Nacharbeiten.

Müssen alle gefundenen Anforderungen bereits zu Beginn validiert werden?

Nur die Schlüsselanforderungen. Die anderen sollten als "weiter zu klärende" markiert werden, und man sollte in den nächsten Iterationen zu ihnen zurückkehren.

Können nur Geschäftsvertreter mit den Anforderungen arbeiten?

Nein, es müssen auch technische Fachkräfte einbezogen werden, da viele Einschränkungen und architektonische Entscheidungen nur gemeinsam erarbeitet werden können.

Typische Fehler und Anti-Patterns

• "Vergraben" nur im Happy Path, ohne Fokus auf Ausnahmeszenarien.
• Formale Zustimmung zu unzureichend detaillierten Anforderungen.
• Fehlende Re-Review-Phase zu Beginn.

Beispiel aus dem Leben

Negativer Fall: In einem großen Projekt wurden zur Beschleunigung des Starts nur die Hauptgeschäftsprozesse bearbeitet, während die Nuancen der nebensächlichen Szenarien ignoriert wurden. Vorteile: Schnelles Prototyping und Markteinführung des MVP. Nachteile: Viele Rückläufe zur Nachbearbeitung, Verzögerung der Releases und Konflikte mit dem QA-Team.

Positiver Fall: Der Analyst teilte den Prozess in Phasen auf, hielt Risikobereiche fest, führte wöchentliche Klarstellungsverfahren und Prototypenerstellung ein. Vorteile: Verringerung der Rückläufe, Transparenz der Unsicherheitsbereiche für das Team. Nachteile: Höhere Belastung für die Analysten in den ersten Wochen.