Der BABOK v3 definiert 6 Wissensgebiete für die Business Analyse. Zwei dieser Gebiete beschäftigen sich mit der Anforderungsanalyse und dem Management des Anforderungslebenszyklus.
Wenn Sie Anforderungen analysieren, dann spezifizieren und modellieren Sie die Informationen, die Sie gesammelt haben. Danach verifizieren und validieren Sie die Anforderungen und definieren die Architektur sowie die Design-Optionen. Abschließend analysieren Sie ihr Nutzenspotenzial und empfehlen Lösungen.
Eine Anforderung durchläuft verschiedene Stadien, zum Beispiel wird sie definiert oder verifiziert. Außerdem steht sie immer mit anderen Elementen in Beziehung, sei es zu ihrem Ursprung (Stakeholder) oder zu anderen Anforderungen. Daher müssen Sie zum Beispiel immer ihre Rückverfolgbarkeit sicherstellen.
Anforderungen in der Business Analyse. Analyse und Management des Lebenszyklus.
Was ist eine Anforderung in der Business Analyse? Welchen Lebenszyklus durchläuft sie und wie lassen sich Anforderungen analysieren?
“Ich weiß, dass Sie denken, Sie hätten das, was Sie glauben, ich hätte gesagt, verstanden. Aber ich bin mir nicht sicher, ob Sie realisieren, dass das, was Sie gehört haben, nicht das ist, was ich meinte.”
Robert McCloskey, amerikanischer Autor und Illustrator von Kinderbüchern
Was ist eine Anforderung?
Business Analyse umfasst viele Aufgaben und Fragestellungen, die Sie lösen müssen. Der Business Analysis Body of Knowledge (BABOK), ein Handbuch und Leitfaden des International Institute of Business Analysis (IIBA), hat diese Tätigkeiten in 6 Wissensgebiete unterteilt. Darunter finden Sie 2 Gebiete, die speziell Anforderungen betreffen: Anforderungsanalyse und Design-Definition sowie Management des Anforderungslebenszyklus.
Gut formulierte Anforderungen, die regelmäßig mit den Stakeholdern kommuniziert werden, sind essenziell, um das gewünschte Produkt liefern zu können. Betonung liegt auf “gewünscht”. Denn viele Projekte scheitern daran, die Ziele und Wünsche ihrer Kunden zu erfüllen – weil Anforderungen nicht verstanden oder gar nicht erst erfasst worden sind. Was aber genau ist eine Anforderung? Gemäß des BABOK lautet die Definition:
„Eine Anforderung ist eine brauchbare Darstellung eines Bedarfs – meistens repräsentiert durch Dokumente.“
Hier unterscheidet der BABOK in Version 3 zusätzlich zwischen Anforderung und Design: Eine Anforderung beschreibt das Was und soll den Bedarf darstellen, während das Design das Wie beschreibt und die Lösung repräsentiert.
Lesen Sie hier, um mehr über Business Analyse nach BABOK zu erfahren »
Was ist eine Anforderung nicht?
Eine Anforderung ist kein Ziel einer Organisation wie zum Beispiel:
“Gewinn soll innerhalb eines Jahres um 53 % steigen.”
Dafür definieren Sie Business-Ziele.
Eine Anforderung ist keine Projektabgrenzung wie zum Beispiel:
“Die Software muss am 31. Mai 2018 geliefert werden.”
Dafür verwenden Sie Mittel wie einen Projektplan.
Und sie beschreibt nicht das Wie:
“Die Sprache soll durch ein Drop-Down-Menü ausgewählt werden.”
Dafür ist die Design-Definition zuständig.
Stattdessen sind Anforderungen zum Beispiel:
“Anwender soll Artikel zu einem Einkaufswagen hinzufügen können.”
“Anwender soll die Artikel in seinem Einkaufswagen jederzeit einsehen können.”
Definition der Business-Analyse gemäß des International Institute of Business Analysis (IIBA):
A requirement is a “usable representation of a need. Generally represented by means of documents.”
Klassifikation von Anforderungen
Anforderungen lassen sich nach 4 Kategorien klassifizieren. Im Folgenden werden die englischen Benennungen des BABOK übernommen.
Business Requirement
Ziele und Ergebnisse, die den Grund zur Einleitung einer Änderung beschreiben
Stakeholder Requirement
Bedürfnisse der Stakeholder, die erfüllt werden müssen, um die Business Requirements zu erfüllen
Solution Requirement
Leistungsfähigkeit und Qualität einer Lösung, die Stakeholder Requirements erfüllt; lässt sich nach funktionalen Anforderungen und nicht-funktionalen Anforderungen klassifizieren
Transition Requirement
Leistungsfähigkeit, die eine Lösung bietet, um den Übergang vom Ist-Zustand zum Soll-Zustand zu erleichtern
BABOK: Anforderungsanalyse und Design-Definition
Das Wissensgebiet “Anforderungsanalyse und Design-Definition” (englisch: Requirements Analysis and Design Definition) umfasst das klassische Requirements Engineering.
Anforderungsanalyse
und Designdefinition
Aufgaben
- Anforderungen spezifizieren und modellieren
- Anforderungen verifizieren
- Anforderungen validieren
- Anforderungsarchitektur definieren
- Designoptionen definieren
- Nutzenpotential analysieren und Lösung empfehlen
Anforderungen spezifizieren und modellieren
Wenn Sie Anforderungen textlich erfassen, können Sie sich an der ISO 29148, einer Norm zum Requirements Engineering, orientieren. Sie schlägt u.a. folgende textliche Vorlage vor (Vorlage entspricht der englischen Satzstellung):
[Voraussetzung] [Subjekt] [Aktion] [Objekt] [Einschränkung]
Wenn das Signal X empfangen wird [Voraussetzung], soll das System [Subjekt] das Bit für die Erhaltung des Signal X [Objekt] innerhalb von 2 Sekunden [Einschränkung] setzen [Aktion].
Lesen Sie hier, um mehr über Use Case-Diagramme zu erfahren.
Anforderungen verifizieren und validieren
Daneben gehören die Verifizierung und Validierung zu Ihren Aufgaben.
Die Verifizierung bezieht sich auf den notwendigen Qualitätsstandard, den eine Anforderung erfüllen muss, um sie für die Business Analyse weiterzuverwenden. Für diesen Standard muss die Anforderung laut BABOK folgende Merkmale aufweisen:
- in sich geschlossen
- vollständig
- einheitlich
- richtig
- umsetzbar
- änderbar
- eindeutig
- testbar
Für die Verifizierung müssen Sie sich zum Beispiel folgende Fragen stellen: Wenn eine Anforderung eine Reihe an Informationen bearbeiten soll – gibt es eine Anforderung, die diese Informationen erstellt? Brauchen Sie eine Anforderung, die diese Informationen wieder löscht? Und verwenden Sie eine einheitliche Terminologie? Um diese Fragen zu beantworten und andere Unklarheiten zu beseitigen, sollten Anforderungen durch ein ausführliches Review und verschiedene Hände laufen.
Die Validierung bezieht sich auf den Mehrwert, die eine Anforderung für den Stakeholder schafft. Selbst wenn eine Anforderung verifiziert ist, muss sie nicht unbedingt gebraucht werden. Daher müssen Sie als Business Analyst auch stets prüfen, ob Anforderungen tatsächlich einen Mehrwert schaffen. Aber selbst wenn sie ein Stakeholder braucht – geht die Anforderung auch mit dem Business Case konform? Wenn dies nicht der Fall ist, sollte sie einem anderen Business Case zugeordnet oder ganz vom Lösungsansatz entfernt werden.
Wenn Sie die Anforderungen validiert haben, müssen Sie außerdem das Zusammenspiel der Anforderungen bzw. die Anforderungsarchitektur und die Möglichkeiten zur Umsetzung in den Design-Optionen bestimmen.
Schließlich ist der Business Analyst dafür verantwortlich, die Lösungsoptionen und ihr Mehrwert für die Organisation zu kommunizieren und Lösungen vorzuschlagen. Sie erhalten in dieser Knowledge Area also 6 Ergebnisse:
- Spezifizierte und modellierte Anforderungen
- Verifizierte Anforderungen
- Validierte Anforderungen
- Anforderungsarchitektur
- Designoptionen
- Lösungsvorschläge
Wissen zum Mitnehmen
Mit objectiF RPM Bedarf ermitteln, Lösungen vorschlagen & Mehrwert schaffen
BABOK: Management des Anforderungslebenszyklus
Dieses Wissensgebiet “Management des Anforderungslebenszyklus” (englisch: Requirements Lifecycle Management) soll sicherstellen, dass die Organisation, Stakeholder, Lösungsanforderungen und Designs aufeinander abgestimmt sind.
Management
des Anforderungs-
lebenszyklus
Aufgaben
- Anforderungen rückverfolgen
- Anforderungen pflegen
- Anforderungen priorisieren
- Anforderungsarchitektur definieren
- Änderungen von Anforderungen beurteilen
- Anforderungen genehmigen
Anforderungen verfolgen oder: die Wichtigkeit der Traceability
Sie müssen Anforderungen jederzeit zurückverfolgen können (auch Traceability genannt). Nur dadurch lässt sich u.a. bestimmen, ob Sie eine Anforderung tatsächlich brauchen. Was genau bedeutet das? Jede Anforderung besitzt Beziehungen zu anderen Elementen. So muss sie immer einen Ursprung haben. Wer braucht sie und warum? In der Business Analyse geht eine Anforderung stets auf den oder die Stakeholder und ihre Bedürfnisse zurück. Je nach Klassifizierung ist eine Anforderung außerdem mit anderen Anforderungen verbunden. Zum Beispiel ergibt sich ein Stakeholder Requirement aus einem Business Requirement. Und schließlich werden Testfälle mit ihnen verknüpft, um ihre Umsetzung zu prüfen.
Anforderungen pflegen, priorisieren, bewerten und genehmigen
Pflegen: Als Business Analyst müssen Sie Anforderungen während, aber auch nach Ihrer eingeleiteten Änderung aktuell halten. Außerdem ist es ratsam, Anforderungen in anderen Lösungen wiederverwenden zu können. Um sie aktuell zu halten, sollten Sie die Anforderungen regelmäßig durch ein Review laufen lassen. Das erfordert natürlich einen Zugriff für allen Beteiligten auf die Anforderungen und sie muss ebenfalls von allen verstanden werden. Beachten Sie: Eine Anforderung, die nicht abgenommen oder implementiert wurde, lässt sich trotzdem noch für andere Lösungen verwenden.
Priorisieren: Nicht alle Anforderungen sind von gleicher Priorität – je nach Stakeholder und Nutzen müssen Sie die Reihenfolge definieren, in denen die Anforderungen umgesetzt werden sollen. Die Priorisierung findet fortlaufend statt, um auf Änderungen reagieren zu können. Zum Beispiel ändert sich der Nutzen, die Kosten oder die Risiken im Verlauf des Projekts. In agilen Projekten würde dann der Product Owner die Einträge im Product Backlog neu sortieren. Um Anforderungen zu priorisieren, brauchen Sie Techniken wie die Risiko- oder MoSCoW-Analyse.
Bewerten: Als Business Analyst müssen Sie bewerten, wie sich vorgeschlagene Änderungen auf Anforderungen auswirkten. Diese Evaluierung erfolgt immer dann, wenn neue Bedürfnisse oder Lösungen identifiziert worden sind.
Genehmigen: Und abschließend müssen Sie Anforderungen akzeptieren bzw. abnehmen, um die Erarbeitung der Lösung fortzusetzen. Diese Abnahme darf formell oder informell geschehen.
Anforderungen mit Software verwalten
Zusammengefasst müssen Sie also die gesammelten Informationen als Anforderungen festhalten – sei es textlich oder durch Diagramme. Damit Sie die Anforderungen verifizieren können, müssen Sie die Richtigkeit bzw. Qualität sicherstellen. Das geht nur, wenn sich der Inhalt von allen beteiligten Personen einsehen und absegnen lässt – und zwar durch Reviews. Sie müssen ebenfalls die Traceability sicherstellen, um Anforderungen zu den Stakeholdern und den Bedürfnissen, aber auch zu anderen Anforderungen zurückzuverfolgen. Wie gehen Sie vor, ohne unterschiedliche Tools für die unterschiedlichen Ergebnisse zu verwenden?
Nutzen Sie eine Software, mit der Sie alles im Blick haben: Erstellen Sie Anforderungen textlich oder visualisieren Sie sie durch Diagramme, z.B. in Verbindung mit Use Case-Diagrammen. Zur Sicherstellung der Qualität lassen Sie die Anforderungen durch Reviews laufen und sind durch E-Mail-Benachrichtigungen immer auf den aktuellen Stand. Und die Beziehungen der Anforderungen zu den Stakeholdern, Bedürfnissen, anderen Anforderungen und Testfällen? Alles sowohl textlich als auch visuell ersichtlich – mit nur einer Software.