Antwort.

Geschichte der Frage:

Mit der zunehmenden Komplexität von IT-Projekten und der Anzahl involvierter Fachleute entstand das Problem: Business-Stakeholder verlangen ein verständliches Beschreiben, das technische Team — eine detaillierte und technisch präzise Beschreibung. Es gibt keinen universellen Standard, und historisch gesehen wurde der Systemanalytiker zum "Übersetzer" zwischen den Welten, indem er den Formalisierungsgrad der Anforderungen an die Zielgruppe anpasste.

Problem:

Die Fachabteilungen können Diagramme und Spezifikationen schlecht lesen, und sie sind nicht mit den Begriffen von UML/BPMN vertraut. Die Entwickler hingegen benötigen nicht nur Benutzeranforderungen und eine allgemeine Sichtweise — sie brauchen klare Kriterien, Diagramme, API-Schemas und Datenformate. Wenn der Analytiker das falsche Format für die Anforderungen wählt, besteht das Risiko von Missverständnissen, nicht übereinstimmenden Funktionen und Verzögerungen.

Lösung:

Bestimmen Sie die Schlüsselrollen/Personen unter den Interessengruppen und führen Sie mit ihnen eine Reihe von Interviews oder Umfragen durch, um ihre Erfahrungen, Erwartungen und Bedürfnisse zu erkunden.
Für den Geschäftskunden — Verwendung von Szenarien (User Stories), BPMN-Diagrammen, Glossaren von Begriffen, interaktiven Mockups und Wireframes. Übermäßige Detaillierung möglichst vermeiden.
Für die Entwicklung — Vorbereitung strukturierter technischer Spezifikationen (SRS, Klassendiagramme, ER-Diagramme, API-Beschreibungen, Akzeptanzkriterien), um eine eindeutige Interpretation zu gewährleisten.
Für Implementierer und Tester — separate Checklisten, Abnahmekriterien, Testfälle und Interaktionsdiagramme.

Schlüssel: Das gleiche Anforderungsset in einem geeigneten Format für jede Zielgruppe zu formalisieren, ohne Mehrdeutigkeiten zuzulassen.

Wichtige Merkmale:

Anpassung des Anforderungsformats an die Kompetenzen und Erwartungen der Zielgruppe
Verwendung mehrerer konsensbasierter Darstellungen für die gleichen Anforderungen
Auswahl der "goldenen Mitte" zwischen Vollständigkeit und übermäßiger Detaillierung

Fragen mit einem Haken.

Kann man eine SRS-Vorlage (Software Requirements Specification) nehmen und sie unverändert an alle Projektteilnehmer weitergeben?

Nein. Ein und dasselbe Dokument ist für verschiedene Rollen ineffektiv — für den Geschäftskunden wird die SRS schwer verständlich sein, und dem Implementierungsteam können wichtige Details fehlen. Die Anforderungen müssen für jede Zielgruppe angepasst werden.

Oft hört man: "BPMN- und UML-Diagramme ersetzen vollständig die schriftliche Beschreibung von Anforderungen — ist das so?"

Nein. Diagramme sind eine mächtige visuelle Ergänzung, aber sie müssen immer mit Erklärungen begleitet werden, da viele Stakeholder (besonders im Geschäft) die Notationen nicht kennen. Ohne einen erläuternden Abschnitt bleiben viele Nuancen unverständlich.

Kann man geschäftliche und technische Anforderungen in einem Abschnitt mischen?

Nicht empfohlen. Dies erschwert das Finden und Verstehen von Informationen für verschiedene Rollen und führt zu Fehlern in der Umsetzungsphase. Es ist notwendig, die Dokumentation klar zu strukturieren und geschäftliche Anforderungen, technische Spezifikationen, nicht-funktionale Erwartungen und Abnahmekriterien zu unterscheiden.

Typische Fehler und Anti-Patterns

Verwendung nur eines Anforderungsformats für alle Rollen
Übermäßige Detaillierung, wo sie nicht nötig ist ("Tonnen von Diagrammen" für das Geschäft)
Übermäßige Verwendung von Fachjargon
Fehlen eines Glossars von Begriffen, was zu Missverständnissen führt

Beispiel aus dem Leben

Negativer Fall

Der Analyst hat ein riesiges mehrseitiges Dokument SRS in Englisch erstellt, das komplexe UML-Diagramme enthielt. Die Business-Stakeholder haben es nicht einmal geöffnet, und das Implementierungsteam hat aufgrund von Schätzungen Schlussfolgerungen gezogen, was zu Mängeln an den Schnittstellen führte.

Vorteile:

Formal war die gesamte Dokumentation vorhanden

Nachteile:

Die Fachabteilung verstand die Funktionen nicht
Zahlreiche Rückgaben und Nachbesserungen
Entwickler ignorierten Teile der Anforderungen

Positiver Fall

Für das Geschäft wurde eine Präsentation mit interaktiven Prototypen und den wichtigsten Geschäftstermen erstellt, für das technische Team — eine separate technische Spezifikation und API-Pipeline. Die Dokumentation wurde in Confluence verwaltet, mit Statusupdates für die Diskussion.