Rollen Skill - Business Analyst

Er ermittelt, analysiert, validiert, konsolidiert, spezifiziert, kommuniziert und dokumentiert sowohl die Schwachstellen in Business Prozessen, Organisationsstrukturen sowie Informatik- und Sachmitteleinsätzen als auch Bedürfnisse, Wünsche und Erwartungen der Stakeholder an ein in Zukunft zu modifizierendes oder neues Softwaresystem.

Fokussiert auf eine Wirtschaftlichkeit und Realisierbarkeit arbeitet der Business Analyst folglich an Anforderungen, dokumentiert diese in unterschiedlichen Detaillierungsgraden und führt mit den Erwartungshaltungen der Stakeholder mit einem Abgleich durch.

Die wesentliche inhaltlichen Aufgaben führt der Business Analyst zwar oftmals mit Unterstützung von ausgewählten Fachexperten durch, er verantwortet jedoch hierbei sowohl die Ergebnisse einer Business Analyse als auch die einer Anforderungsanalyse einschließlich die Qualität der beschriebenen Anforderungen.

Des Weiteren sorgt der Business Analyst bezüglich der umzusetzenden Anforderungen zwischen den Auftraggeber und den Auftragnehmer für Konsens und für ein gemeinsames Verständnis.

Der Business Analyst stellt bei einer zu einem späteren Zeitpunkt stattfindenden Übergabe der Anforderungen zudem sicher, dass die Anforderungen - unter Berücksichtigung der geltenden Randbedingungen soweit wie möglich - im Sinne des Auftraggebers umgesetzt werden.

Der Prozess der Anforderungsanalyse führt in der Regel zu einer nach den verschiedenen Merkmalen revisionssicher zu dokumentierenden Auflistung von allen relevanten Anforderungen, welche vom Ergebnistyp her oftmals als Anforderungsliste oder (etwas umfänglicher) als Anforderungskatalog bezeichnet werden.

Im Wesentlichen geht es hier um:

Genauer beschrieben obliegt es einem Business Analysten, die fachlichen Kundenanforderungen (Kundenziele) nicht nur zu ermitteln und (z.B. in einem Anforderungskatalog) zu dokumentieren sondern auch vollumfänglich zu verstehen.

Hierbei sollte der Business Analysten möglichst nicht nur die offensichtlichen bekannten Anforderungen sondern auch die tatsächlichen (oftmals unbewusst nicht geäußerten) Anforderungen von Stakeholdern aufdecken.

Im Anschluss daran sind die initialen Kundenanforderungsbeschreibungen vom Business Analysten eindeutig und verständlich formuliert zu präzisieren und zu klassifizieren. Für den weiteren Anforderungsprozess kann im Rahmen dieser Konkretisierung ggf. eine Zerlegung der Anforderungen in Unteranforderungen sinnvoll sein.

Die Kundenanforderungen sind vom Business Analysten auch hinsichtlich der nötigen Qualität auf Fehler zu überprüfen, damit beispielsweise auf Grund von Mehrdeutigkeit, Unvollständigkeit oder Widersprüche in der Anforderungsdokumentation besonders negative Auswirkungen für die weiteren Entwicklungsschritte vermieden werden.

Da die Kundenanforderungen die Basis für ein Lastenheft bilden, sind diese vom Business Analysten nicht nur formal zu prüfen sondern auch im Hinblick auf eine Sicherstellung, dass alle vertragsrelevanten Attribute vollständig, ausreichend und genau dokumentiert sind.

Um alle Zusammenhänge und Einschränkungen (z.B. Zielkonflikte) sowie die Machbarkeit einer technischen Umsetzung genauer zu verstehen, sind alle Kundenanforderungen hinsichtlich des Nutzen (vs. Aufwand) von einem Business Analysten zu analysieren und zu bewerten. Das Ziel der Business Analyse ist eine zweifelsfreie Klärung aller Anforderungen und eventuell bestehenden Randbedingungen.

Anschließend stimmt ein Business Analyst alle erfassten Kundenanforderungen mit den relevanten Stakeholdern inhaltlich ab, um für das zu entwickelnde System ein übereinstimmendes gemeinsames Verständnis zu erzielen. Wenn dieses gelingt, sind die Kundenanforderungen vom Auftraggeber formal freizugeben, denn letztendlich entscheidet dieser welche seiner Anforderungen unter welchen Annahmen, Randbedingungen, Einschränkungen und Prioritäten umgesetzt werden sollen.

Ableitend von den Kundenanforderungen muss ein Business Analyst zudem eine grobe Vorstellung von den fachlichen anzupassenden Bausteinen (= technischer Leistungsumfang) in einem System (ggf. auch mehrerer Systeme) haben und die Kundenanforderungen in einem Lastenheft fachlich klar definieren können.

Diese funktionalen und nicht-funktionalen Systemanforderungen muss ein Business Analyst möglichst formaler und konkreter als die Kundenanforderungen beschreiben, weil nur so eine frühe Verifikation und werkzeuggestützte Ableitung der Systemanforderungen für Implementierungen oder Testfallerstellung ermöglicht wird. Die Systemanforderungen müssen zudem immer einen Bezug zu einer oder mehrerer Kundenanforderungen haben.

Bei den Systemanforderungen muss ein Business Analyst durch eine geeignete Prüfung sicher stellen können, dass die Beschreibung zu jeder einzelnen Systemanforderung sowie auch in der Gesamtmenge in einer ausreichender Detaillierung (z.B. alle Pflichtattribute dokumentiert) und in hoher Qualität (z.B. Konformität, Konsistenz, Verständlichkeit, Eindeutigkeit, Abdeckung aller Kundenanforderungen) erfolgte.

Die Umsetzbarkeit der spezifizierten Systemanforderungen prüft ein Business Analyst abschließend in der Regel durch ein Hinzuzuziehen von IT Architekten und Entwicklern.

Für die umsetzbaren Systemanforderungen muss dieser dann noch den Umsetzungsaufwand schätzen, das Umsetzungsrisiko zu besprechen, den Umsetzungstermin grob planen sowie die Umsetzung der einzelnen Systemanforderungen so priorisieren, dass daraus die Festlegung eines Releases abgeleitet werden kann.

Analog zu den Kundenanforderungen muss der Business Analyst auch die Systemanforderungen mit allen betroffenen Stakeholdern abstimmen und sich diese von den Stakeholdern im Falle eines positiven Ergebnisses freigeben lassen.

Im Zuge der formalen Freigabe sind die Systemanforderungen je nach dem vereinbarten Vorgehensmodell aus dem Anforderungsmanagement an das Test- und Umsetzungsmanagement zu übergeben.

In der implementierten Softwarelösung sollen sich alle Systemanforderungen widerspiegeln. Zwecks effizienter Überprüfung auf Vollständigkeit, aber auch zur Rückverfolgbarkeit oder Fortschrittskontrolle von Anforderungen sollte der Business Analyst die Systemanforderungen mit den - durch die implementierten Softwarebausteine umgesetzten - Kundenanforderungen verknüpft haben, denn eine Verfolgbarkeit von Anforderungen unterstützt die Verwaltung von Anforderungen und die Ermittlung der Auswirkungen von Änderungsanforderungen.

Von Änderungsanforderungen spricht ein Business Analyst, wenn sich im Projektverlauf die Anforderungen an ein System im Vergleich zu dem freigegebenen Lastenheft (Fachkonzept) oder Pflichtenheft (DV Konzept) ändern.

Da Änderungsanforderungen auf den Projekterfolg große Auswirkung haben können, müssen die Änderungswünsche vom Business Analysten hinsichtlich möglicher Auswirkungen auf andere Anforderungen analysiert werden.

Im Rahmen einer systematischen Auswirkungsanalyse (Impact Analyse) hat der Business Analyst auf Basis von Beziehungsinformationen (Traceability) auch die Machbarkeit, einen zusätzlichen Aufwand, das Bestehen möglicher Abhängigkeiten und/ oder Seiteneffekte und die von diesen Änderungen betroffen Bereiche/ Personen mit abklären.

Der Business Analyst verfolgt das Ziel die gewünschten Änderungen nicht nur transparent zu machen sondern nur dann kontrolliert zuzulassen, wenn eine zwingende Notwendigkeit (Priorität) besteht.

Sofern die Änderungsanforderungen auch Auswirkungen auf Zeit, Funktionen und Budget (z.B. Termin- und Kostenüberschreitung) haben, muss zur Entscheidungsfindung ein CR-Verfahren eingeleitet werden.

Freigegebene Änderungsanforderungen sind vom Business Analysten nachvollziehbar zu dokumentieren. Zugleich sind die von der Änderung betroffenen Stakeholder zu informieren.

Exkurs Lastenheft (Fachkonzept) 

Die Gesamtheit der gewünschten Eigenschaften von Anforderungen an ein Vorhaben mündet in einem vom Business Analysten präzise und vollständig zu formulierenden Lastenheftes (Fachkonzept).

Ein Lastenheft wird aus fachlicher Sicht lösungsorientiert beschrieben und definiert verbindlich den zwischen den Auftraggeber und den Auftragnehmer zu vereinbarenden Lieferumfang. Im Prinzip kann ein belastbares Pflichtenheftes (DV Konzept) erst auf der Grundlage eines abgenommenen Lastenheftes erstellt werden.

Inhaltlich muss jede in einem Lastenheft beschriebene Anforderung in Beziehung zu der zu Grunde liegenden Anforderungsliste (Anforderungskatalog) eindeutig und nachvollziehbar mit einer Verfolgbarkeit bis zum Entstehungsursprung der Anforderung identifiziert werden können.

In der Rolle des Business Analysten übernehmen wir u.a. auch die Analyse von IST Prozessen, dokumentieren die künftigen SOLL Prozesse und beschreiben den hierfür notwendigen Anpassungsbedarf. Des Weiteren fungieren wir als Bindeglied zwischen den am Prozess beteiligten Bereichen (z.B. Fachbereich, Business Architekt, Projektleiter).

Zugleich tragen wir gern Verantwortung für die Entwicklung moderner Geschäftsprozesse, die ihre strategische Grundausrichtung im Zusammenspiel von Produkten, Prozessen und Funktionen unterstützen.