Antwort.

Geschichte der Frage:

In klassischen und agilen Projekten unterscheiden sich die Anforderungen an analytische Artefakte: An einigen Orten sind detaillierte Spezifikationen und Klassendiagramme erforderlich, an anderen genügen einfache Tabellen/Skizzen. Viele Organisationen haben ihre eigenen Vorlagen, aber der tatsächliche Nutzen der Dokumentation wird durch ihre Aktualität und Anwendbarkeit bestimmt.

Problem:

Das Fehlen eines standardisierten Satzes an Artefakten führt zu Verwirrung ("Was wann zeichnen?") und ein Übermaß führt zu Bürokratie und veralteter Dokumentation, die vom Team nicht genutzt wird. Oft erstellen Analytiker Artefakte „zum Schein“ ohne Rücksprache mit Entwicklern und Testern.

Lösung:

Ein kompetenter Systemanalytiker:

Führt Kick-off-Meetings mit dem Team und dem Kunden durch, um deren Schmerzpunkte und geeignete Artefaktformate herauszufinden.
Erstellt eine Verantwortungsmatrix (RACI) für die Dokumentation: wer welche Artefakte benötigt, wer sie pflegt und in welcher Phase.
Vereinbart gemeinsam mit dem Architekten und den Teamleitern, wo beispielsweise Klassendiagramme (für komplexe Logik) verwendet werden müssen und wo ein BPMN-Prozess oder ein Mockup ausreicht.
Präzisiert und überprüft ständig den Satz an Artefakten im Verlauf des Projekts — Aktualität über Vollständigkeit.

Schlüsselfunktionen:

Es gibt keinen universellen Satz von Artefakten: Für verschiedene Projekte sind unterschiedliche Dokumente erforderlich.
Kommunikation und gemeinsame Vereinbarungen sind die Grundlage des Erfolgs (shared ownership).
Jedes Artefakt sollte eine spezifische Aufgabe lösen, lebendig und gepflegt sein.

Trickfragen.

Kann man nur einen Diagrammtyp (z. B. nur BPMN) für alle Situationen verwenden?

Nein, jeder Diagramm- oder Dokumenttyp beleuchtet einen unterschiedlichen Aspekt des Systems: BPMN für Prozesse, UML für Objekte und Interaktionen, Tabellen für Verzeichnisse. Ihre Kombination ist die beste Praxis.

Braucht man immer ein detailliertes Dokument zur Spezifikation der Anforderungen?

Nicht immer. In Startups, Pilotprojekten und agilen (Agile) Projekten können leichte Dokumente, die sich auf das Backlog stützen, ausreichend sein — Hauptsache, das Team versteht die Aufgaben.

Kann ein Analyst von dem Team verlangen, seinem Dokumentationsvorlagen zu folgen?

Nein. Formate und Vorlagen für die Dokumentation sollten im Rahmen der Diskussion und Vereinbarung mit dem Team und dem Kunden entstehen und für alle Beteiligten komfortabel sein.

Typische Fehler und Anti-Patterns

Mechanisches Kopieren eines vollständigen Dokumentensets aus anderen Projekten.
Erstellung von Dokumentation „der Dokumentation wegen“.
Ignorieren des Feedbacks des Teams, Verweigerung, mit aktuellen Artefakten zu arbeiten.

Beispiel aus dem Leben

Negativer Fall: Ein Systemanalytiker führte 6 verschiedene Diagramme für jeden Prozess im Rahmen eines Unternehmensprojekts ein. Das Team ertrank in der Dokumentation, niemand las sie, und arbeitete nach mündlichen Aufgaben.

Vorteile:

Wunsch, das System auf hoher Ebene zu formalisieren.

Nachteile:

Zeitverlust, Verwirrung.
Ungenaue Dokumentation zum Zeitpunkt der Umsetzung.

Positiver Fall: In einem anderen Projekt dokumentierte der Analyst nur das BPMN-Diagramm und eine kurze Tabelle von Attributen und aktualisierte diese regelmäßig nach den Treffen mit den Entwicklern.