Geschichte der Frage:
Komplexe Anforderungen werden oft auf einer hohen Abstraktionsebene formuliert oder enthalten zahlreiche verborgene Bedingungen und Ausnahmen. Wenn solche Anforderungen nicht dekomponiert und präzisiert werden, können Missverständnisse zwischen dem Auftraggeber, den Entwicklern und den Testern entstehen.
Problem:
Mehrdeutige oder nicht ausreichend dekomponierte Anforderungen führen dazu, dass das Team „Details“ selbständig ausarbeitet. In der Folge bleibt der Geschäftswert unerfüllt oder verzerrt, und es wird wesentlich schwieriger und teurer, dies zu korrigieren.
Lösung:
Der Systemanalytiker führt eine detaillierte Analyse der Anforderungen mithilfe von Dekompositionstechniken (Use Case Diagramm, Aktivitätsdiagramm, User Stories nach INVEST, Event Storming, Dekompositionstafel) durch. Es ist wichtig, Szenarien (Basis-/Alternative/Ausnahmeflüsse) zu erstellen, Entscheidungstabellen und Übergangsmatrizen zu bauen und zuletzt jeden „Knoten“ durch Beispiele von Edge Cases gemeinsam mit dem Auftraggeber zu verifizieren. Nach der Dekomposition sammelt der Analyst alle Teile, analysiert die Integrationspunkte und stellt die Konsistenz sicher.
Wesentliche Merkmale:
Reicht eine textuelle Beschreibung des User Story-Szenarios aus?
Nein, nur User Stories sind nicht ausreichend: Es sind Sequenzdiagramme, Beispiele für Edge Cases, UI-Mockups und Entscheidungstabellen für komplexe Geschäftslogik notwendig.
Stellt Dekomposition automatisch sicher, dass es keine Widersprüche zwischen den Anforderungen gibt?
Nein, Dekomposition muss von der Konsolidierung widersprüchlicher Anforderungen, regelmäßigen Review-Sitzungen und der Analyse von Abhängigkeiten begleitet werden.
Kann die Dekomposition ausschließlich Entwicklern oder Testern übertragen werden?
Nein, der Analyst ist verantwortlich für die Vollständigkeit der Detaillierung. Wenn dies anderen Rollen überlassen wird, entstehen verschiedene Interpretationen und Abweichungen.
Negativer Fall:
Der Business-Außendienstmitarbeiter schrieb: "Das System muss den Rabatt für jeden Kunden individuell berechnen." Es wurde eine Implementierung mit starren Rabattmodellen umgesetzt. Bei Tests stellte sich heraus, dass es mehr als ein Dutzend verborgene Parameter gab, die in der Formalisierungsphase nicht erkannt wurden.
Vorteile:
Nachteile:
Positiver Fall:
Der Analyst führte einen Workshop zu Event Storming durch, identifizierte alle Parameter und Bedingungen der Berechnung. Er erstellte eine Entscheidungstabelle und Sequenzdiagramme, stimmte mit dem Geschäft Beispiele von Edge Cases ab. Die Anforderung wurde klar und überprüfbar, Fehler wurden vor Beginn der Entwicklung entdeckt.
Vorteile:
Nachteile: