Ein Business Analyst verwendet verschiedene Methoden zur Erfassung und Dokumentation von Anforderungen, abhängig von der Spezifität des Projekts, der Zusammensetzung der Stakeholder und den gewünschten Ergebnissen. Zu den Methoden gehören Interviews, Workshops, Beobachtungen, Umfragen, Dokumentationsanalysen, Prototyping und Datenanalyse. Die Wahl der Methode hängt von Faktoren wie der Komplexität der Anforderungen, der Verfügbarkeit von Experten und Stakeholdern, der Reife der Geschäftsprozesse und den Zeitbudgets ab.
Die Dokumentation der Anforderungen erfolgt durch formalisierte (SRS, BRD, User Stories) und informalisierte (Mind Map, Diagramme, Grafiken) Werkzeuge. Es ist wichtig, die Eindeutigkeit, Vollständigkeit, Rückverfolgbarkeit und Aktualität der Anforderungen in allen Phasen des Projekts sicherzustellen. Der Business Analyst wählt das Format basierend auf der Zielgruppe, der Unterstützungskomplexität und der Produktspezifik.
Wesentliche Merkmale:
Welche Methode zur Anforderungserfassung passt immer für IT-Projekte?
Keine Methode ist universell. Beispielsweise sind Interviews in einigen Fällen nützlich, während in einem großen verteilten Team Umfragen oder Dokumentationsanalysen effektiver sind. Es hängt alles von der Situation ab.
Kann man sich für alle Arten von Anforderungen nur auf User Stories beschränken?
Nein, User Stories sind gut für agile Projekte, aber für komplexe IT-Systeme sind technische Spezifikationen, nicht-funktionale Anforderungen und andere Formate unbedingt erforderlich.
Muss der Business Analyst nur die gesammelten Wünsche des Auftraggebers dokumentieren?
Nein, der Analyst ist verpflichtet, versteckte und widersprüchliche Anforderungen zu identifizieren, die Bedürfnisse des Unternehmens zu analysieren und die Zweckmäßigkeit der Implementierung bestimmter Funktionen zu begründen.
Negativer Fall: Der Analyst hat Anforderungen ausschließlich über eine Umfrage gesammelt, ohne die Details mit dem Team und dem Auftraggeber zu besprechen. Infolgedessen waren viele Anforderungen nicht mehr relevant. Vorteile: Schnell gesammelte Anforderungen, Nachteile: Anforderungen wurden veraltet, kritische Aufgaben und Nuancen wurden nicht identifiziert.
Positiver Fall: Der Analyst verwendete eine Kombination aus Workshops, Interviews und Prototyping und stellte die Validierung der Anforderungen sowohl aus technischer als auch aus geschäftlicher Sicht sicher. Vorteile: Zuverlässige und vereinbarte Anforderungen, schnelle Anpassungen während des Projekts. Nachteile: Es wurden mehr Ressourcen und Zeit für die Synchronisation benötigt.