Antwort.

Geschichte der Frage: In den frühen Phasen eines Projekts formuliert der Auftraggeber oft vage oder widersprüchliche Anforderungen, die der Analyst in klare und überprüfbare verwandeln muss, um sie später umzusetzen.

Problem: Vage Anforderungen führen zu Missverständnissen zwischen dem Geschäft und dem Entwicklungsteam, was die Anzahl der Rückgaben von Aufgaben, Bugs und unzufriedenen Nutzern erhöht.

Lösung:

Durchführung von Workshops und Klärungssitzungen: Der Analyst moderiert ein Treffen mit dem Auftraggeber, nutzt Klärungstechniken (Example Mapping, Event Storming, Story Mapping).
Verwendung von Prototypen und Wireframes: Visuelle Modellierung hilft dem Geschäft, Erwartungen präziser auszudrücken.
Schrittweise Klärung bis zu den Abnahmekriterien (Definition of Ready): Unterteilung in Teilaufgaben, Formalisierung von Szenarien, Sammlung von Edge-Cases.

Schlüsselfeatures:

Schrittweise Klärung ist ein kontinuierlicher Prozess, der Zyklen von Fragen und schnellen Überprüfungen (Feedback-Schleifen) umfasst.
Einbeziehung mehrerer Teilnehmer, um unterschiedliche Perspektiven zu berücksichtigen.
Der Analyst dokumentiert Optionen und Einschränkungen, auch wenn sie zusammen mit "rohen" Anforderungen auftreten.

Fangfragen.

"Kann man sich bei der Erfassung vager Anforderungen nur auf die Worte des Auftraggebers verlassen?"

Nein, es ist wichtig, Beispiele, Diagramme, Entwürfe zu verwenden und weitere Fragen zu stellen, um die tatsächlichen Bedürfnisse herauszufinden.

"Reicht es aus, Anforderungen einmal zu klären?"

Nein, Klärung ist ein iterativer Prozess: Mit dem Auftauchen von Details müssen die Anforderungen erneut abgestimmt werden.

"Kann man immer Anforderungen klären, ohne die Endnutzer einzubeziehen?"

Nein, die Beteiligung echter Nutzer ist manchmal entscheidend, um Edge-Cases und Nutzungsszenarien zu identifizieren, die für das Geschäft und die IT nicht offensichtlich sind.

Typische Fehler und Anti-Patterns

Versuch, vage Anforderungen ohne Formalisierung umzusetzen.
Ignorieren von Klärungssitzungen.
Dokumentation von Anforderungen nur in Textform, ohne Visualisierung und Beispiele.

Beispiel aus dem Leben

Negativer Fall: Der Auftraggeber bat um einen "benutzerfreundlichen Suchmechanismus" – dies wurde festgehalten, und man begann, es "wie gewohnt" umzusetzen.

Vorteile:

Schneller Beginn der Aufgabe.

Nachteile:

Das Ergebnis entsprach nicht den Erwartungen des Nutzers; eine andere Suche und Filterung war erforderlich.

Positiver Fall: Bei einer ähnlichen Aufgabe führte der Analyst einen Workshop durch, sammelte Nutzungsszenarien und zeichnete Prototypen.