Antwort.

Geschichte der Frage:

Mit dem Wachstum und der Komplexität von IT-Projekten trat mehrfach die Situation auf, dass die Anforderungen des Geschäftskunden in Form von abstrakten Wünschen eintrafen, die beim Übertragen an das Entwicklungsteam in etwas anderes verwandelt wurden. Die Ursache ist die Kluft in der Terminologie, den Erwartungen und dem Abstraktionsniveau zwischen dem Geschäft und IT.

Problem:

Wenn die Dekompensationsphase nicht durchdacht wird, werden die Anforderungen entweder unvollständig (kritische Details fehlen), oder übermäßig vage (kann nicht bewertet und umgesetzt werden), oder sie werden aufgrund lexikalischer Fallen, nicht berücksichtigter Terminologie und Missverständnisse ganz verzerrt.

Lösung:

Der Systemanalytiker dekomponiert jede Anforderung systematisch: er formalisiert Geschäftstermine, übersetzt Geschäftsziele in Funktionen und Aufgaben, beschreibt Benutzerszenarien und Systemverhalten, verknüpft sie mit Abnahmekriterien/Testfällen. Es ist wichtig, Modelle (UML, BPMN), Glossare, Checklisten und direkte Reviews zwischen den Teams zu verwenden.

Schlüsselfeatures:

Erstellung eines Glossars von Begriffen zusammen mit dem Kunden
Verwendung von Diagrammen und atomaren Formulierungen von Anforderungen
Übersetzung von Anforderungen in die Sprache von Abnahmekriterien und Testfällen

Tricks in Fragen.

Kann man die Geschäftswünsche in freier Form belassen und während der Entwicklungsphase weiter verarbeiten?

Nein, das Risiko von Missverständnissen und Implementierungsfehlern ist hoch.

Muss man bis zu den Implementierungsdetails (z. B. wie man Daten speichert) in der Analyse vordringen?

Nein, die Analyse betrifft das "Was" und "Warum", nicht das "Wie". Technische Details sind die Verantwortung der Architektur und Entwicklung.

Entspricht immer eine Anforderungsaufzeichnung = ein Modul/Funktion?

Nein, häufig ist eine Dekompensation erforderlich — große Anforderungen werden in Unterfunktionen und User Stories mit separaten Abnahmekriterien unterteilt.

Typische Fehler und Anti-Pattern

Vermischung von Geschäftssprache und technischen Begriffen ohne Glossar
Beschreibung von Anforderungen als "vage Wünsche"
Verletzung der Atomarität — eine Anforderung enthält viele verschiedene Entitäten

Beispiel aus dem Leben

Negativer Fall: Der Kunde übermittelt eine Liste von Wünschen "Der Benutzer sollte alle Verkaufsanalysen sehen", eins zu eins in das Pflichtenheft kopiert.

Vorteile:

Schnelligkeit der Dokumentenerstellung

Nachteile:

Unklar, welche spezifischen Metriken und in welchem Umfang benötigt werden
Ständige Nachbesserungen

Positiver Fall: Der Analyst befragte den Kunden, erstellte eine Liste der erforderlichen Metriken, definierte Benutzerrollen, entwickelte Prototypen von Berichten und stimmte das Glossar der Begriffe ab.