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?

1
2
3
Business-Analyse: Wissensgebiete bezüglich der Anforderungen

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 Requirements

    Ziele und Ergebnisse, die den Grund zur Einleitung einer Änderung beschreiben

  • Stakeholder Requirements

    Bedürfnisse der Stakeholder, die erfüllt werden müssen, um die Business Requirements zu erfüllen

  • Solution Requirements

    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 Requirements

    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.

Business Analyse: Aufgaben in der Anforderungsanalyse

Anforderungen spezifizieren und modellieren

Hier müssen Sie die tatsächlichen Bedürfnisse der Stakeholder ermitteln und als Anforderungen festhalten. Das bedeutet: Alle Informationen, die Sie in der Erhebung zusammengetragen haben, müssen Sie nun organisieren, strukturieren und in Anforderungen dokumentieren. Dafür spezifizieren und modellieren Sie die Anforderungen. Zum Beispiel erfassen Sie diese textlich oder Sie verwenden Diagramme wie Use Case-Diagramme. Am besten eignet sich eine Kombination aus beidem, da Sie textlich die Details einer Anforderung erfassen und den Kontext visuell im Diagramm darstellen können.

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.

Lesen Sie, um zu erfahren, wie Reviews mit einer Software funktionieren »

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

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.

Business Analyse: Aufgaben im Management des Anforderungslebenszyklus

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.

Lesen Sie hier, um mehr über Traceability zu erfahren »

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.

Ermitteln Sie den Bedarf, schlagen Sie Lösungen vor und erzielen Sie Mehrwert.

Von den Stakeholder-Zielen, zu den Anforderungen und der Lösung – alles in einer Software. Unser objectiF RPM Whitepaper erklärt Ihnen wie.

  • Dieses Feld dient zur Validierung und sollte nicht verändert werden.
*: Pflichtfelder
Ich erkläre mich mit der Zusendung des wöchentlichen microTOOL Newsletters einverstanden. Diese Zusage kann ich natürlich jederzeit widerrufen.

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.

Sie haben weitere Fragen? Gut, wir haben weitere Antworten.

Wissen Online

Interessante Details und Erklärungen finden Sie hier  >>