Antwort.

Geschichte der Frage:

Frühe Phasen von Projekten sind oft durch unzureichende Klarheit der Geschäftsziele und Architekturentscheidungen gekennzeichnet, weshalb der Systemanalytiker mit dem Problem konfrontiert ist, das optimale Detailniveau der Anforderungen zu bestimmen. Eine falsche Wahl führt entweder zu übermäßiger Ausarbeitung (Overengineering) oder zu Unklarheiten und Missverständnissen im Team.

Problem:

Einige Stakeholder möchten Details „an Land“ sehen, während andere befürchten, dass übermäßige Detaillierung die Flexibilität beeinträchtigt. Der Übergang zwischen den Phasen (von der Konzeption zur Planung, dann zur Umsetzung) erfordert rechtzeitige Aktualisierungen der Anforderungen und die Einbindung aller Beteiligten.

Lösung:

Der Systemanalytiker verwendet einen iterativen Ansatz. In den frühen Phasen werden nur die grundlegenden Geschäftsbedürfnisse und großen Blöcke (Epics) festgelegt, dann werden die Detailniveaus im Verlauf der Entwicklung erhöht:

In der Pre-Sales-Phase — Vision und High-Level-Anforderungen;
Bei der Vorbereitung des Pflichtenhefts — Dekomposition in User Stories oder Feature-Spezifikationen;
In der Entwurfsphase und beim Übergang zur Entwicklung — Ausarbeitung von Szenarien, Fehlern, Interaktionen und Mockups bis hin zu Akzeptanzkriterien.

Wichtige Merkmale:

Die Detaillierung steigt mit der Klärung der Lösung (Prinzip der progressiven Ausarbeitung).
Der Analyst synchronisiert sich mit dem Team, um nicht zu früh ins Detail zu gehen.
Das Detailniveau wird mit dem Lebenszyklus des Projekts und den vertraglichen Verpflichtungen abgestimmt.

Fangfragen.

Wer sollte das erforderliche Detailniveau bestimmen — der Analyst, der Architekt oder der Auftraggeber?

Es wird oft fälschlicherweise gedacht, dass dies nur der Analyst oder nur der Architekt tut, jedoch ist die richtige Antwort: Das Detailniveau ist die Verantwortung der gesamten koordinierenden Gruppe (Analyst, Architekt, Product Owner, technische Leiter und Auftraggeber), die im Rahmen der Projektmethodologie abgestimmt wird.

Sind High-Level-Anforderungen für den Start der Teamarbeit ausreichend?

Nein, High-Level-Anforderungen sind für die Bildung einer gemeinsamen Vision notwendig. Für den Übergang zur Entwicklung sind präzisierte Szenarien (User Stories, Akzeptanzkriterien) unerlässlich, andernfalls besteht ein hohes Risiko von Missverständnissen und Fehlern bei der Implementierung.

Sollen alle Anforderungen bis zur Veröffentlichung gleich detailliert sein?

Nein, oft werden die Anforderungen für MVP so tief wie möglich ausgearbeitet, während weniger priorisierte Aufgaben auf Entwurfsebene gehalten werden, um Ressourcen nicht vorzeitig zu verschwenden.

Typische Fehler und Anti-Pattern

Die Detaillierung wird ohne Berücksichtigung der Projektphase weiter erhöht.
Es werden Details aller Anforderungen ausgearbeitet, selbst von weniger priorisierten, wodurch die Geschwindigkeit verloren geht.
Die Kommunikation mit dem Team über die ausreichende Detaillierung wird vernachlässigt — es fehlt an Feedback.

Beispiel aus dem Leben

Negativer Fall: CRM-Projekt in einem Startup. Das Unternehmen bestand auf vollständiger Detaillierung aller Module im Voraus. Der Analyst erstellte Hunderte von Seiten Anforderungen für alle zukünftigen Funktionen, obwohl nur der Verkauf Priorität hatte.

Vorteile:

Detaillierte Basis für zukünftige Anforderungen.

Nachteile:

Zeit- und Budgetkosten, Verzögerungen beim Start.
Die Anforderungen waren zum Zeitpunkt der Modulüberarbeitung veraltet und erforderten wesentliche Änderungen.

Positiver Fall: In einem ähnlichen Projekt hat der Analyst einen Kern von Anforderungen für das MVP (Leads- und Deal-Management) formuliert, während die anderen als Epics mit kurzer Beschreibung festgehalten wurden. Die Detaillierung fand während der Annäherung an die Implementierungssprints statt.