Analyse

Die Analysephase, oft auch Anforderungsanalyse genannt, klärt, was fachlich tatsächlich benötigt wird, und übersetzt grobe Ziele und Wünsche aus der Planung in nachvollziehbare Anforderungen. Vertreter der betroffenen Bereiche, Produktverantwortliche und analytische Rollen arbeiten gemeinsam heraus, welche Nutzergruppen im Fokus stehen, welche Prozesse unterstützt werden sollen und welche Randbedingungen gelten.

Die Ergebnisse dieser Phase sind weniger „perfekte Spezifikationen“ als ein tragfähiges, gemeinsames Verständnis. Genau dieses gemeinsame Verständnis ist der eigentliche Wert der Analyse, nicht das Dokument, das am Ende dabei entsteht.

Was in der Analysephase geklärt wird

Vier Fragenkreise strukturieren die Arbeit in dieser Phase:

• Anforderungen: Was wird fachlich und technisch tatsächlich gebraucht und in welcher Reihenfolge ist es wichtig?
• Nutzergruppen: Wer arbeitet später mit der Lösung, in welchem Kontext und mit welchen Erwartungen?
• Prozesse: Welche bestehenden Abläufe werden unterstützt, verändert oder abgelöst?
• Rahmenbedingungen: Welche rechtlichen, technischen oder organisatorischen Grenzen sind einzuhalten?

Diese vier Fragenkreise hängen eng zusammen. Eine Anforderung ohne Bezug zu einer echten Nutzergruppe bleibt beliebig, ein Prozess ohne bekannte Rahmenbedingungen lässt sich schwer sauber abbilden.

Wer typischerweise beteiligt ist

Fachexperten aus den betroffenen Bereichen bringen das eigentliche Prozesswissen ein, oft genau die Personen, die später täglich mit der Lösung arbeiten. Business Analysts oder Requirements Engineers moderieren die Analyse und machen die Ergebnisse für alle nachvollziehbar. Der Product Owner sorgt dafür, dass Anforderungen priorisiert werden, statt alles als gleich wichtig zu behandeln. Die technische Leitung ist schon hier eingebunden, um Anforderungen realistisch einzuordnen, bevor Erwartungen entstehen, die sich später nicht halten lassen.

Typische Risiken

Wenn die Analyse verkürzt wird, agiert die Entwicklung auf Annahmen und Einzelmeinungen. Das äußert sich häufig in späten, teuren Anpassungen und in Widerständen kurz vor dem Go-Live, wenn plötzlich Bedürfnisse sichtbar werden, die vorher niemand abgefragt hat.

Was am Ende vorliegen sollte: Übergabe an das Design

Übergabeartefakt	Warum es zählt
Priorisierte Anforderungsliste	Gibt vor, was zuerst gelöst werden muss
Beschreibung der Nutzergruppen und ihrer Kontexte	Verhindert ein Design am eigentlichen Bedarf vorbei
Dokumentierte Prozesse und Workflows	Zeigt, wo die Lösung in bestehende Abläufe eingreift
Nicht-funktionale Anforderungen	Wird im Design sonst leicht übersehen
Offene Fragen und Annahmen	Verhindert, dass das Design auf stillschweigenden Annahmen aufbaut

Eine unvollständige Übergabe fällt selten sofort auf. Sie zeigt sich erst, wenn im Design Fragen auftauchen, die eigentlich schon geklärt sein sollten.

Fragen, die sich alle Beteiligten stellen sollten

• Welche Nutzergruppen und betroffenen Bereiche wurden aktiv einbezogen?
• Ist transparent, welche Anforderungen priorisiert wurden und welche explizit nicht?

Gerade die zweite Frage wird oft übersehen. Eine bewusste Nicht-Entscheidung ist etwas anderes als ein vergessenes Anliegen, aber von außen sehen beide gleich aus, wenn sie nicht dokumentiert werden.

Im Beispiel: Ablösung des Ticketsystems

Bei der Ablösung des internen Ticketsystems treten in der Analysephase die unterschiedlichen Bedürfnisse von Support, Vertrieb, IT und Management zutage. Erst hier wird klar, was jeweils unter „modern“ verstanden wird, denn für den Support kann das kürzere Reaktionszeiten bedeuten, für das Management vor allem bessere Reportingmöglichkeiten.