BABOK® v3 E-Book
54,99 €
Mehr erfahren.
- Herausgeber: Schmidt, Götz
- Kategorie: Fachliteratur
- Sprache: Deutsch
Business-Analyse besteht aus einer Reihe von Aufgaben und Techniken, die dazu dienen, Strategien, Strukturen, Ziele, Aufgaben und Prozesse einer Organisation zu verstehen. Das Zusammenspiel aller beteiligten internen und externen Stakeholder ist darauf auszurichten, dass die Unternehmen den Anforderungen des Marktes gerecht werden und dabei ihre betrieblichen Ziele erreichen. Dazu müssen die benötigten Ressourcen, Verfahren und Prozesse bereitgestellt werden. Die Ermittlung und Umsetzung der Anforderungen der unterschiedlichen internen und externen Stakeholder ist der Schlüssel für die erfolgreiche Arbeit des Business-Analysten. Der Leitfaden zur Business-Analyse BABOK® Guide 3.0 (BABOK® v3) umfasst eine Beschreibung von allgemein anerkannten Praktiken und Vorgehensweisen, die nun schon in der dritten Auflage gemeinsam mit einer Vielzahl von weltweit tätigen Praktikern und ausgewiesenen Experten des IIBA® International Institute of Business Analysis erarbeitet wurden. Die zweite Auflage wurde in Englisch, Deutsch, Französisch, Spanisch und Portugiesisch veröffentlicht und gilt heute weltweit als Standardwerk zur Business-Analyse. Diese dritte Auflage wurde grundlegend überarbeitet, neu gegliedert und erweitert. Neu ist das Kernkonzeptmodell als Rahmenmodell der Business-Analyse. Mehrere Kapitel wurden vertieft, zentrale Begriffe teilweise neu definiert, viele weitere Techniken wurden integriert. Im Anhang findet sich eine detaillierte Auflistung der Neuerungen im Vergleich zu den Auflagen 1 und 2. Das Werk eignet sich hervorragend zur Vorbereitung auf die Prüfung zum Certified Business Analysis Professional™ (CBAP®) und zur Certification of Competency in Business Analysis™ (CCBA®) des International Institute of Business Analysis (IIBA®).
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 692
Veröffentlichungsjahr: 2017
Ähnliche
International Institute of Business Analysis, Toronto, Ontario, Canada.
©2005, 2006, 2008, 2009, 2015 International Institute of Business Analysis. All rights reserved.
Version 1.0 and 1.4 published 2005. Version 1.6 Draft published 2006. Version 1.6 Final published 2008. Version 2.0 published 2009. Version 3.0 published 2015.
This document is provided to the business analysis community for educational purposes. IBA® does not warrant that it is suitable for any other purpose and makes no expressed or implied warranty of any kind and assumes no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information contained herein.
IIBA®, the IIBA® logo, BABOK® and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis. CBAP® is a registered certification mark owned by International Institute of Business Analysis. Certified Business Analysis Professional, EEP and the EEP logo are trademarks owned by International Institute of Business Analysis.
Archimate® is a registered trademark of The Open Group in the US and other countries.
Business Model Canvas is copyrighted by BusinessModelGeneration.com and released under Creative Commons license.
CMMI® is a registered trademark of Carnegie Mellon University.
COBIT® is a trademark of the Information Systems Audit and Control Association and the IT Governance Institute.
Mind Map® is a registered trademark of the Buzan Organization.
Scaled Agile Framework® and SAFe™ are trademarks of Scaled Agile, Inc.
TOGAF® is a registered trademark of The Open Group in the US and other countries.
Unified Modelling Language™ and UML® are trademarks of the Object Management Group.
Zachman Framework for Enterprise Architecture is a trademark of the Zachman Institute for Framework Advancement.
No challenge to the status or ownership of these or any other trademarked terms contained herein is intended by the International Institute of Business Analysis.
Dieses Werk ist die deutsche Übersetzung von BABOK® v3
A GUIDE TO THE BUSINESS ANALYSIS BODY OF KNOWLEDGE®
des IIBA® International Institute of Business AnalysisTM
Übersetzt und bearbeitet durch:
EABA European Association of Business Analysis
IIBA® Chapter Österreich
IIBA® Chapter Schweiz
Österreichische Vereinigung für Organisation und Management
Schweizerische Gesellschaft für Organisation
Verantwortliche Übersetzer:
Gerd Nanz, Götz Schmidt
Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung von IIBA®, vertreten durch EABA, unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen und die Speicherung und Verarbeitung in elektronischen Systemen.
Die in dieser Arbeit wiedergegebenen Gebrauchsnamen, Warennamen usw. sind auch ohne besondere Kennzeichnung nach der Warenzeichen- und Markenschutzgesetzgebung als geschützt zu betrachten.
Amerikanische Fassung
BABOK® V3 A GUIDE TO THE BUSINESS ANALYSIS BODY OF KNOWLEDGE®
ISBN-13: 978-1-927584-02-6
Deutsche Fassung
Das Copyright der deutschen Übersetzung liegt bei
© International Institute of Business Analysis 2017
Deutsche Übersetzung als E-Book im Format epub
ISBN: 978-3-945997-05-5
E-Book-Herstellung: Zeilenwert GmbH 2017
Inhaltsverzeichnis
Cover
Titel
Impressum
Vorwort
Kapitel 1: Einleitung
1.1 Zweck des BABOK®-Leitfadens
1.2 Was ist Business-Analyse?
1.3 Wer ist ein Business-Analyst?
1.4 Aufbau des BABOK®-Leitfadens
1.4.1 Kernbegriffe
1.4.2 Wissensgebiete
1.4.3 Aufgaben
.1 Zweck
.2 Beschreibung
.3 Inputs
.4 Elemente
.5 Leitfäden und Werkzeuge
.6 Techniken
.7 Stakeholder
.8 Outputs
1.4.4 Basiskompetenzen
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
1.4.5 Techniken
.1 Zweck
.2 Beschreibung
.3 Elemente
.4 Bewertung
1.4.6 Perspektiven
.1 Scope des Change-Vorhabens
.2 Scope der Business-Analyse
.3 Methoden, Herangehensweisen und Techniken
.4 Basiskompetenzen
.5 Auswirkungen auf die Wissensgebiete
Kapitel 2: Schlüsselkonzepte der Business-Analyse
2.1 Kernkonzept-Modell der Business-Analyse
2.2 Kernbegriffe
Business-Analyse
Information der Business-Analyse
Design
Unternehmen
Organisation
Plan
Anforderung
Risiko
2.3 Klassifikationsschema von Anforderungen
2.4 Stakeholder
2.4.1 Business-Analyst
2.4.2 Kunde
2.4.3 Fachexperte
2.4.4 Anwender
2.4.5 Umsetzungsexperte
2.4.6 Support (Operational Support)
2.4.7 Projektmanager
2.4.8 Regulierer
2.4.9 Sponsor/Auftraggeber
2.4.10 Lieferant
2.4.11 Tester
2.5 Anforderungen und Designs
Kapitel 3: Planung und Überwachung der Business-Analyse
Das Kernkonzept-Modell in der „Planung und Überwachung der Business-Analyse“
3.1 Ansatz der Business-Analyse planen
3.1.1 Zweck
3.1.2 Beschreibung
3.1.3 Inputs
3.1.4 Elemente
.1 Planungsansatz
.2 Formalität und Detaillierungsgrad der Ergebnisse der Business-Analyse
.3 Aktivitäten der Business-Analyse
.4 Zeitliche Koordination der Arbeit der Business-Analyse
.5 Komplexität und Risiken
.6 Akzeptanz
3.1.5 Leitfäden und Werkzeuge
3.1.6 Techniken
3.1.7 Stakeholder
3.1.8 Outputs
3.2 Einbindung der Stakeholder planen
3.2.1 Zweck
3.2.2 Beschreibung
3.2.3 Inputs
3.2.4 Elemente
.1 Stakeholder-Analyse durchführen
.2 Zusammenarbeit mit Stakeholdern festlegen
.3 Kommunikationsbedarf der Stakeholder
3.2.5 Leitfäden und Werkzeuge
3.2.6 Techniken
3.2.7 Stakeholder
3.2.8 Outputs
3.3 Steuerung der Business-Analyse planen
3.3.1 Zweck
3.3.2 Beschreibung
3.3.3 Inputs
3.3.4 Elemente
.1 Entscheidungsfindung
.2 Steuerungsprozess des Change
.3 Planen des Ansatzes der Priorisierung
.4 Planen der Genehmigungen
3.3.5 Leitfäden und Werkzeuge
3.3.6 Techniken
3.3.7 Stakeholder
3.3.8 Outputs
3.4 Informationsmanagement der Business-Analyse planen
3.4.1 Zweck
3.4.2 Beschreibung
3.4.3 Inputs
3.4.4 Elemente
.1 Organisation von Informationen der Business-Analyse
.2 Abstraktionsebene
.3 Planen des Ansatzes der Traceability
.4 Planen der Wiederverwendbarkeit von Anforderungen
.5 Speicherung und Zugriff
.6 Attribute der Anforderungen
3.4.5 Leitfäden und Werkzeuge
3.4.6 Techniken
3.4.7 Stakeholder
3.4.8 Outputs
3.5 Leistungsverbesserungen der Business-Analyse ermitteln
3.5.1 Zweck
3.5.2 Beschreibung
3.5.3 Inputs
3.5.4 Elemente
.1 Leistungsanalyse
.2 Maßstäbe der Evaluierung
.3 Analyse der Ergebnisse
.4 Empfohlene Aktivitäten für Verbesserungen
3.5.5 Leitfäden und Werkzeuge
3.5.6 Techniken
3.5.7 Stakeholder
3.5.8 Outputs
Kapitel 4: Erhebung und Zusammenarbeit
Das Kernkonzept-Modell in der „Erhebung und Zusammenarbeit“
4.1 Erhebung vorbereiten
4.1.1 Zweck
4.1.2 Beschreibung
4.1.3 Inputs
4.1.4 Elemente
.1 Den Umfang der Erhebung verstehen
.2 Erhebungstechniken auswählen
.3 Organisation der Erhebung planen
.4 Unterstützendes Material besorgen
.5 Stakeholder vorbereiten
4.1.5 Leitfäden und Werkzeuge
4.1.6 Techniken
4.1.7 Stakeholder
4.1.8 Outputs
4.2 Erhebung durchführen
4.2.1 Zweck
4.2.2 Beschreibung
4.2.3 Inputs
4.2.4 Elemente
.1 Erhebung lenken
.2 Erhebungsergebnisse festhalten
4.2.5 Leitfäden und Werkzeuge
4.2.6 Techniken
4.2.7 Stakeholder
4.2.8 Outputs
4.3 Erhebungsergebnisse bestätigen
4.3.1 Zweck
4.3.2 Beschreibung
4.3.3 Inputs
4.3.4 Elemente
.1 Erhebungsergebnisse mit Informationsquellen vergleichen
.2 Erhebungsergebnisse mit anderen Erhebungsergebnissen vergleichen
4.3.5 Leitfäden und Werkzeuge
4.3.6 Techniken
4.3.7 Stakeholder
4.3.8 Outputs
4.4 Business-Analyse-Informationen kommunizieren
4.4.1 Zweck
4.4.2 Beschreibung
4.4.3 Inputs
4.4.4 Elemente
.1 Ziele und Format der Kommunikation festlegen
.2 Zusammenstellung der Business-Analyse kommunizieren
4.4.5 Leitfäden und Werkzeuge
4.4.6 Techniken
4.4.7 Stakeholder
4.4.8 Outputs
4.5 Zusammenarbeit mit Stakeholdern managen
4.5.1 Zweck
4.5.2 Beschreibung
4.5.3 Inputs
4.5.4 Elemente
.1 Bekenntnis zu Verpflichtungen erreichen
.2 Stakeholder Engagement verfolgen
.3 Zusammenarbeit
4.5.5 Leitfäden und Werkzeuge
4.5.6 Techniken
4.5.7 Stakeholder
4.5.8 Outputs
Kapitel 5: Management des Anforderungs-Lebenszyklus
Das Kernkonzept-Modell im „Management des Anforderungs-Lebenszyklus“
5.1 Anforderungen rückverfolgen
5.1.1 Zweck
5.1.2 Beschreibung
5.1.3 Inputs
5.1.4 Elemente
.1 Formalisierungsgrad
.2 Beziehungstypen
.3 Rückverfolgungs-Repository
5.1.5 Leitfäden und Werkzeuge
5.1.6 Techniken
5.1.7 Stakeholder
5.1.8 Outputs
5.2 Anforderungen pflegen
5.2.1 Zweck
5.2.2 Beschreibung
5.2.3 Inputs
5.2.4 Elemente
.1 Pflege der Anforderungen
.2 Pflege der Attribute
.3 Wiederverwendung von Anforderungen
5.2.5 Leitfäden und Werkzeuge
5.2.6 Techniken
5.2.7 Stakeholder
5.2.8 Outputs
5.3 Anforderungen priorisieren
5.3.1 Zweck
5.3.2 Beschreibung
5.3.3 Inputs
5.3.4 Elemente
.1 Grundlagen der Priorisierung
.2 Herausforderungen bei der Priorisierung
.3 Fortwährende Priorisierung
5.3.5 Leitfäden und Werkzeuge
5.3.6 Techniken
5.3.7 Stakeholder
5.3.8 Outputs
5.4 Änderungen von Anforderungen beurteilen
5.4.1 Zweck
5.4.2 Beschreibung
5.4.3 Inputs
5.4.4 Elemente
.1 Formalisierung der Beurteilung
.2 Wirkungsanalyse
.3 Entscheidungsfindung
5.4.5 Leitfäden und Werkzeuge
5.4.6 Techniken
5.4.7 Stakeholder
5.4.8 Outputs
5.5 Anforderungen genehmigen
5.5.1 Zweck
5.5.2 Beschreibung
5.5.3 Inputs
5.5.4 Elemente
.1 Verstehe die Rollen der Stakeholder
.2 Management von Konflikten und Problemen
.3 Zustimmung gewinnen
.4 Verfolge und kommuniziere Genehmigungen
5.5.5 Leitfäden und Werkzeuge
5.5.6 Techniken
5.5.7 Stakeholder
5.5.8 Outputs
Kapitel 6: Strategische Analyse
Das Kernkonzept-Modell in der strategischen Analyse
6.1 Ist-Zustand analysieren
6.1.1 Zweck
6.1.2 Beschreibung
6.1.3 Inputs
6.1.4 Elemente
.1 Betrieblicher Bedarf
.2 Organisationsstruktur und Kultur
.3 Fähigkeiten und Prozesse
.4 Technologie und Infrastruktur
.5 Richtlinien
.6 Unternehmensarchitektur
.7 Interne Vermögenswerte
.8 Externe Beeinflusser
6.1.5 Leitfäden und Werkzeuge
6.1.6 Techniken
6.1.7 Stakeholder
6.1.8 Outputs
6.2 Soll-Zustand definieren
6.2.1 Zweck
6.2.2 Beschreibung
6.2.3 Inputs
6.2.4 Elemente
.1 Betriebliche Ziele und Leitlinien
.2 Scope des Lösungsraumes
.3 Restriktionen
.4 Organisationsstruktur und -kultur
.5 Fähigkeiten und Prozesse
.6 Technologie und Infrastruktur
.7 Unternehmenspolitische Vorgaben
.8 Unternehmensarchitektur
.9 Interne Ressourcen
.10 Annahmen identifizieren
.11 Potentieller Wert
6.2.5 Leitfäden und Werkzeuge
6.2.6 Techniken
6.2.7 Stakeholder
6.2.8 Outputs
6.3 Risiken bewerten
6.3.1 Zweck
6.3.2 Beschreibung
6.3.3 Inputs
6.3.4 Elemente
.1 Ungewissheiten
.2 Einschränkungen, Annahmen und Abhängigkeiten
.3 Negative Auswirkungen auf den Wert
.4 Risikobereitschaft
.5 Empfehlung
6.3.5 Leitfäden und Werkzeuge
6.3.6 Techniken
6.3.7 Stakeholder
6.3.8 Outputs
6.4 Change-Strategie definieren
6.4.1 Zweck
6.4.2 Beschreibung
6.4.3 Inputs
6.4.4 Elemente
.1 Scope der Lösung
.2 Gap-Analyse
.3 Bewertung der Bereitschaft des Unternehmens
.4 Die Change-Strategie
.5 Übergangszustände und Release-Planung
6.4.5 Leitfäden und Werkzeuge
6.4.6 Techniken
6.4.7 Stakeholder
6.4.8 Outputs
Kapitel 7: Anforderungsanalyse und Design-Definition
Das Kernkonzept-Modell in der „Anforderungsanalyse und Design-Definition
7.1 Anforderungen spezifizieren und modellieren
7.1.1 Zweck
7.1.2 Beschreibung
7.1.3 Inputs
7.1.4 Elemente
.1 Anforderungen modellieren
.2 Anforderungen analysieren
.3 Anforderungen und Attribute darstellen
.4 Einen geeigneten Abstraktionsgrad umsetzen
7.1.5 Leitfäden und Werkzeuge
7.1.6 Techniken
7.1.7 Stakeholder
7.1.8 Outputs
7.2 Anforderungen verifizieren
7.2.1 Zweck
7.2.2 Beschreibung
7.2.3 Inputs
7.2.4 Elemente
.1 Eigenschaften der Anforderungs- und Design-Qualität
.2 Aktivitäten zur Verifikation
.3 Checklisten
7.2.5 Leitfäden und Werkzeuge
7.2.6 Techniken
7.2.7 Stakeholder
7.2.8 Outputs
7.3 Anforderungen validieren
7.3.1 Zweck
7.3.2 Beschreibung
7.3.3 Inputs
7.3.4 Elemente
.1 Annahmen identifizieren
.2 Messbare Bewertungskriterien definieren
.3 Die Ausrichtung auf den Scope der Lösung bewerten
7.3.5 Leitfäden und Werkzeuge
7.3.6 Techniken
7.3.7 Stakeholder
7.3.8 Outputs
7.4 Anforderungsarchitektur definieren
7.4.1 Zweck
7.4.2 Beschreibung
7.4.3 Inputs
7.4.4 Elemente
.1 Anforderungs-Viewpoint und Sichten
.2 Architekturen von Vorlagen
.3 Vollständigkeit
.4 Beziehungen zwischen Anforderungen herstellen und verifizieren
.5 Informationsarchitektur der Business-Analyse
7.4.5 Leitfäden und Werkzeuge
7.4.6 Techniken
7.4.7 Stakeholder
7.4.8 Outputs
7.5 Design-Optionen definieren
7.5.1 Zweck
7.5.2 Beschreibung
7.5.3 Inputs
7.5.4 Elemente
.1 Lösungsansätze beschreiben
.2 Verbesserungsmöglichkeiten identifizieren
.3 Anforderungen zuordnen
.4 Design-Optionen beschreiben
7.5.5 Leitfäden und Werkzeuge
7.5.6 Techniken
7.5.7 Stakeholder
7.5.8 Outputs
7.6 Nutzenpotential analysieren und Lösung empfehlen
7.6.1 Zweck
7.6.2 Beschreibung
7.6.3 Inputs
7.6.4 Elemente
.1 Erwarteter Nutzen
.2 Erwartete Kosten
.3 Nutzen bestimmen
.4 Design-Optionen beurteilen und eine Lösung empfehlen
7.6.5 Leitfäden und Werkzeuge
7.6.6 Techniken
7.6.7 Stakeholder
7.6.8 Outputs
Kapitel 8: Lösungsbewertung
Das Kernkonzept-Modell in der Lösungsbewertung
8.1 Lösungs-Performance
8.1.1 Zweck
8.1.2 Beschreibung
8.1.3 Inputs
8.1.4 Elemente
.1 Kennzahlen für die Lösungs-Performance definieren
.2 Kennzahlen der Lösungs-Performance validieren
.3 Kennzahldaten der Lösungs-Performance sammeln
8.1.5 Leitfäden und Werkzeuge
8.1.6 Techniken
8.1.7 Stakeholder
8.1.8 Outputs
8.2 Leistungskennzahlen analysieren
8.2.1 Zweck
8.2.2 Beschreibung
8.2.3 Inputs
8.2.4 Elemente
.1 Performance von Lösungen vs. Zielwert
.2 Risiken
.3 Trends
.4 Exaktheit
.5 Performance-Variation
8.2.5 Leitfäden und Werkzeuge
8.2.6 Techniken
8.2.7 Stakeholder
8.2.8 Outputs
8.3 Einschränkungen der Lösung beurteilen
8.3.1 Zweck
8.3.2 Beschreibung
8.3.3 Inputs
8.3.4 Elemente
.1 Abhängigkeiten unter den internen Lösungskomponenten identifizieren
.2 Probleme der Lösung untersuchen
.3 Wirkungsanalyse durchführen
8.3.5 Leitfäden und Werkzeuge
8.3.6 Techniken
8.3.7 Stakeholder
8.3.8 Outputs
8.4 Einschränkungen des Unternehmens beurteilen
8.4.1 Zweck
8.4.2 Beschreibung
8.4.3 Inputs
8.4.4 Elemente
.1 Bewertung der Unternehmenskultur
.2 Analyse der Auswirkung auf die Stakeholder
.3 Veränderungen an der Organisationsstruktur
.4 Bewertung der betrieblichen Fähigkeiten
8.4.5 Leitfäden und Werkzeuge
8.4.6 Techniken
8.4.7 Stakeholder
8.4.8 Outputs
8.5 Maßnahmen zur Steigerung des Nutzens der Lösung empfehlen
8.5.1 Zweck
8.5.2 Beschreibung
8.5.3 Inputs
8.5.4 Elemente
.1 Anpassung der Kennzahlen zur Messung der Lösungs-Performance
.2 Empfehlungen
8.5.5 Leitfäden und Werkzeuge
8.5.6 Techniken
8.5.7 Stakeholder
8.5.8 Outputs
Kapitel 9: Basiskompetenzen
9.1 Analytisches Denken und Problemlösung
9.1.1 Kreatives Denken
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.1.2 Entscheidungsfindung
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.1.3 Lernen
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.1.4 Problemlösung
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.1.5 Systemdenken
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.1.6 Konzeptionelles Denken
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.1.7 Visuelles Denken
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.2 Verhalten
9.2.1 Ethik
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.2.2 Persönliche Verantwortlichkeit
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.2.3 Vertrauenswürdigkeit
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.2.4 Selbstorganisation und Zeitmanagement
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.2.5 Anpassungsfähigkeit
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.3 Geschäftsverständnis
9.3.1 Unternehmerisches Verständnis
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.3.2 Branchenkenntnis
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.3.3 Unternehmenskenntnis
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.3.4 Kenntnis bestehender Lösungen
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.3.5 Methodenkenntnis
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.4 Kommunikationsfähigkeit
9.4.1 Verbale Kommunikation
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.4.2 Nonverbale Kommunikation
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.4.3 Schriftliche Kommunikation
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.4.4 Zuhören
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.5 Interaktionsfähigkeit
9.5.1 Moderation
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.5.2 Leadership und Einflussnahme
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.5.3 Zusammenarbeit
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.5.4 Verhandlung und Konfliktlösung
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.5.5 Wissensvermittlung
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.6 Werkzeuge und Technologie
9.6.1 Office-Anwendungen und -Technologie
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.6.2 Business-Analyse-Werkzeuge und -Technologie
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
9.6.3 Kommunikationswerkzeuge und -Technologie
.1 Zweck
.2 Beschreibung
.3 Erfolgsmaßstäbe
Kapitel 10: Techniken
10.1 Akzeptanz- und Bewertungskriterien
10.1.1 Zweck
10.1.2 Beschreibung
10.1.3 Elemente
.1 Wertattribute
.2 Beurteilung
10.1.4 Bewertung
.1 Stärken
.2 Grenzen
10.2 Backlog Management
10.2.1 Zweck
10.2.2 Beschreibung
10.2.3 Elemente
.1 Sachverhalte
.2 Priorisierung
.3 Einschätzung
.4 Veränderungen im Auftragsbestand
10.2.4 Bewertung
.1 Stärken
.2 Grenzen
10.3 Balanced Scorecard
10.3.1 Zweck
10.3.2 Beschreibung
10.3.3 Elemente
.1 Lernen und Entwicklung
.2 Geschäftsprozess
.3 Kunde
.4 Finanzen
.5 Messgrößen oder Indikatoren
10.3.4 Bewertung
.1 Stärken
.2 Grenzen
10.4 Benchmarking und Marktanalyse
10.4.1 Zweck
10.4.2 Beschreibung
10.4.3 Elemente
.1 Benchmarking
.2 Marktanalysen
10.4.4 Bewertung
.1 Stärken
.2 Grenzen
10.5 Brainstorming
10.5.1 Zweck
10.5.2 Beschreibung
10.5.3 Elemente
.1 Vorbereitung
.2 Durchführung
.3 Auswertung
10.5.4 Bewertung
.1 Stärken
.2 Grenzen
10.6 Betriebliche Fähigkeitsanalyse
10.6.1 Zweck
10.6.2 Beschreibung
10.6.3 Elemente
.1 Fähigkeiten
.2 Nutzung der Fähigkeiten
.3 Performance-Erwartungen
.4 Risikomodell
.5 Strategische Planung
.6 Fähigkeitskarten
10.6.4 Bewertung
.1 Stärken
.2 Grenzen
10.7 Business Case
10.7.1 Zweck
10.7.2 Beschreibung
10.7.3 Elemente
.1 Bedarfsprüfung
.2 Gewünschte Ergebnisse
.3 Bewertung von Alternativen
.4 Vorgeschlagene Lösung
10.7.4 Bewertung
.1 Stärken
.2 Grenzen
10.8 Darstellung des Geschäftsmodells
10.8.1 Zweck
10.8.2 Beschreibung
10.8.3 Elemente
.1 Zentrale Partnerschaften
.2 Kernaktivitäten
.3 Kernressourcen
.4 Nutzenversprechen
.5 Beziehungen zu Kunden
.6 Kanäle
.7 Kundensegmente
.8 Kostenstruktur
10.8.4 Bewertung
.1 Stärken
.2 Grenzen
10.9 Analyse der Geschäftsregeln
10.9.1 Zweck
10.9.2 Beschreibung
10.9.3 Elemente
.1 Definitorische Regeln
.2 Verhaltensregeln
10.9.4 Bewertung
.1 Stärken
.2 Grenzen
10.10 Gemeinschaftliche Spiele
10.10.1 Zweck
10.10.2 Beschreibung
10.10.3 Elemente
.1 Zweck eines Spiels
.2 Prozess
.3 Ergebnis
.4 Beispiele für gemeinschaftliche Spiele
10.10.4 Bewertung
.1 Stärken
.2 Grenzen
10.11 Begriffsmodellierung
10.11.1 Zweck
10.11.2 Beschreibung
10.11.3 Elemente
.1 Definition von Substantiven
.2 Definition von Verben
.3 Andere Verbindungen
10.11.4 Bewertung
.1 Stärken
.2 Grenzen
10.12 Data Dictionary
10.12.1 Zweck
10.12.2 Beschreibung
10.12.3 Elemente
.1 Datenelemente
.2 Primitive Datenelemente
.3 Zusammengesetzte Datenelemente
10.12.4 Bewertung
.1 Vorteile
.2 Grenzen
10.13 Datenflussdiagramme
10.13.1 Zweck
10.13.2 Beschreibung
10.13.3 Elemente
.1 Externe (Entität, Quelle, Senke)
.2 Datenspeicher
.3 Prozess
.4 Datenfluss
10.13.4 Bewertung
.1 Vorteile
.2 Grenzen
10.14 Data Mining
10.14.1 Zweck
10.14.2 Beschreibung
10.14.3 Elemente
.1 Anforderungsermittlung
.2 Datenvorbereitung: Datenbestand zur Analyse
.3 Datenanalyse
.4 Modellierungstechniken
.5 Einsatz
10.14.4 Bewertung
.1 Stärken
.2 Grenzen
10.15 Datenmodellierung
10.15.1 Zweck
10.15.2 Beschreibung
10.15.3 Elemente
.1 Entität oder Klasse
.2 Attribute
.3 Beziehung oder Zuordnung
.4 Diagramme
.5 Metadaten
10.15.4 Bewertung
.1 Stärken
.2 Grenzen
10.16 Entscheidungsanalyse
10.16.1 Zweck
10.16.2 Beschreibung
10.16.2 Elemente
.1 Komponenten der Entscheidungsanalyse
.2 Entscheidungsmatrix
.3 Entscheidungsbäume
.4 Abwägung
10.16.4 Bewertung
.1 Stärken
.2 Grenzen
10.17 Entscheidungsmodellierung
10.17.1 Zweck
10.17.2 Beschreibung
10.17.3 Elemente
.1 Modelltypen und Notationen
10.17.4 Bewertung
.1 Stärken
.2 Grenzen
10.18 Dokumentenanalyse
10.18.1 Zweck
10.18.2 Beschreibung
10.18.3 Elemente
.1 Vorbereitung
.2 Überprüfung der Dokumente und Analyse
.3 Dokumentation der Ergebnisse
10.18.4 Bewertung
.1 Stärken
.2 Grenzen
10.19 Schätzung
10.19.1 Zweck
10.19.2 Beschreibung
10.19.3 Elemente
.1 Methoden
.2 Zuverlässigkeit der Schätzung
.3 Informationsquellen
.4 Präzision und Vertrauenswürdigkeit der Schätzung
.5 Lieferanten für Schätzwerte
10.19.4 Bewertung
.1 Stärken
.2 Grenzen
10.20 Finanzanalyse
10.20.1 Zweck
10.20.2 Beschreibung
10.20.3 Elemente
.1 Kosten des Veränderungsvorhabens
.2 Total Cost of Ownership (TCO)
.3 Erzielung von Nutzen
.4 Kosten-Nutzen-Analyse
.5 Finanzielle Kalkulationen
10.20.4 Bewertung
.1 Stärken
.2 Grenzen
10.21 Fokusgruppen
10.21.1 Zweck
10.21.2 Beschreibung
10.21.2 Elemente
.1 Ziel der Fokusgruppe
.2 Planung der Fokusgruppe
.3 Teilnehmer
.4 Diskussionsleitfaden
.5 Ernennung eines Moderators und eines Protokollanten
.6 Steuerung der Fokusgruppe
.7 Nachbereitung
10.21.4 Bewertung
.1 Stärken
.2 Grenzen
10.22 Funktionale Gliederung
10.22.1 Zweck
10.22.2 Beschreibung
10.22.3 Elemente
.1 Ziele der Gliederung
.2 Gegenstände der Zerlegung
.3 Tiefe der Gliederung
.4 Darstellung der Gliederungsergebnisse
10.22.4 Bewertung
.1 Stärken
.2 Grenzen
10.23 Glossar
10.23.1 Zweck
10.23.2 Beschreibung
10.23.3 Elemente
10.23.4 Bewertung
.1 Stärken
.2 Grenzen
10.24 Schnittstellenanalyse
10.24.1 Schnittstellenanalyse
10.24.2 Beschreibung
10.24.3 Elemente
.1 Vorbereitung der Identifikation
.2 Identifikation der Schnittstelle
.3 Definition der Schnittstellen
10.24.4 Bewertung
.1 Stärken
.2 Grenzen
10.25 Interview
10.25.1 Zweck
10.25.2 Beschreibung
10.25.3 Elemente
.1 Ziel des Interviews
.2 Auswahl der Befragten
.3 Interviewfragen
.4 Logistik der Interviews
.5 Ablauf des Interviews
.6 Interview-Nachbereitung
10.25.4 Bewertung
.1 Stärken
.2 Grenzen
10.26 Item Tracking
10.26.1 Zweck
10.26.2 Beschreibung
10.26.3 Elemente
.1 Verzeichnis der Items
.2 Item Management
.3 Kennzahlen
10.26.4 Bewertung
.1 Stärken
.2 Grenzen
10.27 Lessons Learned
10.27.1 Zweck
10.27.2 Beschreibung
10.27.3 Elemente
10.27.4 Bewertung
.1 Stärken
.2 Grenzen
10.28 Kennzahlen und Key-Performance-Indikatoren
10.28.1 Zweck
10.28.2 Beschreibung
10.28.3 Elemente
.1 Indikatoren
.2 Kennzahlen
.3 Struktur
.4 Berichterstattung
10.28.4 Bewertung
.1 Stärken
.2 Grenzen
10.29 Mind Mapping
10.29.1 Zweck
10.29.2 Beschreibung
10.29.3 Elemente
.1 Ausgangsthema
.2 Themen
.3 Teilthemen
.4 Äste
.5 Schlüsselbegriffe
.6 Farbe
.7 Bilder
10.29.4 Bewertung
.1 Stärken
.2 Grenzen
10.30 Analyse nicht-funktionaler Anforderungen
10.30.1 Zweck
10.30.2 Beschreibung
10.30.3 Elemente
.1 Arten nicht-funktionaler Anforderungen
.2 Messung nicht-funktionaler Anforderungen
.3 Kontextabhängigkeit nicht-funktionaler Anforderungen
10.30.4 Bewertung
.1 Stärken
.2 Grenzen
10.31 Beobachtung
10.31.1 Zweck
10.31.2 Beschreibung
10.31.3 Elemente
.1 Ziele der Beobachtung
.2 Vorbereitung der Beobachtung
.3 Durchführung der Beobachtung
.4 Bestätigung und Abstimmung der Beobachtungsergebnisse
10.31.4 Bewertung
.1 Stärken
.2 Grenzen
10.32 Organisationsmodellierung
10.32.1 Zweck
10.32.2 Beschreibung
10.32.3 Elemente
.1 Typen organisatorischer Modelle
.2 Rollen
.3 Schnittstellen
.4 Organigramme
.5 Einflüsse
10.32.4 Bewertung
.1 Stärken
.2 Grenzen
10.33 Priorisierung
10.33.1 Zweck
10.33.2 Beschreibung
10.33.3 Elemente
.1 Gruppierung
.2 Rangfolge
.3 Time Boxing/Budgetierung
.4 Verhandlung
10.33.4 Bewertung
.1 Stärken
.2 Schwächen
10.34 Prozessanalyse
10.34.1 Zweck
10.34.2 Beschreibung
10.34.3 Elemente
.1 Ermittlung von Abweichungen und möglichen Verbesserungen
.2 Ursachenanalyse
.3 Erarbeiten und Bewerten von Lösungsvarianten
.4 Verbreitete Methoden
10.34.4 Bewertung
.1 Stärken
.2 Grenzen
10.35 Prozessmodellierung
10.35.1 Zweck
10.35.2 Beschreibung
10.35.3 Elemente
.1 Arten von Prozessmodellen und Notationen
10.35.4 Bewertung
.1 Stärken
.2 Grenzen
10.36 Prototyping
10.36.1 Zweck
10.36.2 Beschreibung
10.36.3 Elemente
.1 Ansätze des Prototyping
.2 Beispiele für Prototyping
.3 Methoden des Prototyping
10.36.4 Bewertung
.1 Stärken
.2 Grenzen
10.37 Reviews
10.37.1 Zweck
10.37.2 Beschreibung
10.37.3 Elemente
.1 Ziele
.2 Techniken
.3 Beteiligte
10.37.4 Bewertung
.1 Stärken
.2 Grenzen
10.38 Risikoanalyse und -management
10.38.1 Zweck
10.38.2 Beschreibung
10.38.3 Elemente
.1 Risikoidentifikation
.2 Analyse
.3 Bewertung von Risiken
.4 Umgang mit Risiken
10.38.4 Bewertung
.1 Stärken
.2 Grenzen
10.39 Rollen- und Zuständigkeitsmatrix
10.39.1 Zweck
10.39.2 Beschreibung
10.39.3 Elemente
.1 Identifikation von Rollen
.2 Identifikation von Aktivitäten
.3 Identifikation von Rechten
.4 Erweiterungen
10.39.4 Bewertung
.1 Stärken
.2 Grenzen
10.40 Ursachenanalyse
10.40.1 Zweck
10.40.2 Beschreibung
10.40.3 Elemente
.1 Ursache-Wirkungs-Diagramm (Fishbone Diagram)
.2 Die „Fünf Warum-Fragen“
10.40.4 Bewertung
.1 Stärken
.2 Grenzen
10.41 Scope-Modellierung (Modellierung der Systemgrenzen)
10.41.1 Zweck
10.41.2 Beschreibung
10.41.3 Elemente
.1 Ziele
.2 Grenzen der Veränderung und Kontext
.3 Detaillierungsgrad
.4 Beziehungen
.5 Annahmen
.6 Ergebnis des Scope-Modellierung
10.41.4 Bewertung
.1 Stärken
.2 Grenzen
10.42 Sequenz-Diagramme
10.42.1 Zweck
10.42.2 Beschreibung
10.42.3 Elemente
.1 Lifeline
.2 Aktivierungs-Box
.3 Nachricht
10.42.4 Bewertung
.1 Stärken
.2 Grenzen
10.43 Stakeholder-Listen, -Karten oder Personas
10.43.1 Zweck
10.43.2 Beschreibung
10.43.3 Elemente
.1 Stakeholder-Listen
.2 Stakeholder-Karten
.3 RACI-Matrix
.4 Personas
10.43.4 Bewertung
.1 Stärken
.2 Grenzen
10.44 Statusmodellierung
10.44.1 Zweck
10.44.2 Beschreibung
10.44.3 Elemente
.1 Status
.2 Statusübergang
.3 Statusdiagramm
.4 Statustabelle
10.44.4 Bewertung
.1 Stärken
.2 Grenzen
10.45 Umfrage oder Fragebogen
10.45.1 Zweck
10.45.2 Beschreibung
10.45.3 Elemente
.1 Vorbereitung
.2 Verteilung des Fragebogens
.3 Dokumentation der Ergebnisse
10.45.4 Bewertung
.1 Stärken
.2 Grenzen
10.46 SWOT-Analyse
10.46.1 Zweck
10.46.2 Beschreibung
10.46.3 Elemente
10.46.4 Bewertung
.1 Stärken
.2 Grenzen
10.47 Use Cases und Szenarien
10.47.1 Zweck
10.47.2 Beschreibung
10.47.3 Elemente
.1 Use-Case-Diagramm
.2 Beschreibung eines Use Case
10.47.4 Bewertung
.1 Stärken
.2 Grenzen
10.48 User Stories
10.48.1 Zweck
10.48.2 Beschreibung
10.48.3 Elemente
.1 Titel (optional)
.2 Statement of Value
.3 Vertiefung
.4 Akzeptanzkriterien
10.48.4 Bewertung
.1 Stärken
.2 Grenzen
10.49 Anbieter-Assessment
10.49.1 Zweck
10.49.2 Beschreibung
10.49.3 Elemente
.1 Wissen und Erfahrung
.2 Lizenzierung und Preismodelle
.3 Stellung des Anbieters im Markt
.4 Vertragsbedingungen
.5 Erfahrungen, Reputation und Stabilität des Anbieters
10.49.4 Bewertung
.1 Stärken
.2 Grenzen
10.50 Workshops
10.50.1 Zweck
10.50.2 Beschreibung
10.50.3 Elemente
.1 Vorbereitung des Workshops
.2 Rollen im Workshop
.3 Durchführung des Workshops
.4 Nachbereitung des Workshops
10.50.4 Bewertung
.1 Stärken
.2 Grenzen
Kapitel 11: Perspektiven
11.1 Die agile Perspektive
11.1.1 Scope des Change-Vorhabens
.1 Breite des Change
.2 Tiefe des Change
.3 Nutzen und umgesetzte Lösungen
.4 Umsetzungsansatz
.5 Zentrale Annahmen
11.1.2 Scope der Business-Analyse
.1 Auftraggeber des Change
.2 Ziele und Akteure des Change
.3 Die Rolle des Business-Analysten
.4 Ergebnisse der Business-Analyse
11.1.3 Ansätze und Techniken
.1 Ansätze
.2 Techniken
11.1.4 Basiskompetenzen
11.1.5 Auswirkungen auf die Wissensgebiete
.1 Planung und Überwachung der Business-Analyse
.2 Erhebung und Zusammenarbeit
.3 Management des Anforderungs-Lebenszyklus
.4 Strategische Analyse
.5 Anforderungsanalyse und Design-Definition
.6 Lösungsbewertung
11.2 Die Business-Intelligence-Perspektive
11.2.1 Scope des Change-Vorhabens
.1 Breite des Change
.2 Tiefe des Change
.3 Nutzen und umgesetzte Lösungen
.4 Umsetzungsansatz
.5 Zentrale Annahmen
11.2.2 Scope der Business-Analyse
.1 Auftraggeber des Change
.2 Ziele des Change
.3 Die Rolle des Business-Analysten
.4 Ergebnisse der Business-Analyse
11.2.3 Methoden und Ansätze
.1 Methoden
.2 Ansätze
11.2.4 Basiskompetenzen
11.2.5 Auswirkungen auf die Wissensgebiete
.1 Planung und Überwachung der Business-Analyse
.2 Erhebung und Zusammenarbeit
.3 Management des Anforderungs-Lebenszyklus
.4 Strategische Analyse
.5 Anforderungsanalyse und Design-Definition
.6 Lösungsbewertung
11.3 Die Informationstechnologie-Perspektive
11.3.1 Scope des Change-Vorhabens
.1 Breite des Change
.2 Tiefe des Change
.3 Nutzen und umgesetzte Lösungen
.4 Umsetzungsansatz
.5 Zentrale Annahmen
11.3.2 Scope der Business-Analyse
.1 Auftraggeber des Change
.2 Ziele des Change
.3 Die Rolle des Business-Analysten
.4 Ergebnisse der Business-Analyse
11.3.3 Methoden
11.3.4 Basiskompetenzen
11.3.5 Auswirkungen auf die Wissensgebiete
.1 Planung und Überwachung der Business-Analyse
.2 Erhebung und Zusammenarbeit
.3 Management des Anforderungs-Lebenszyklus
.4 Strategische Analyse
.5 Anforderungsanalyse und Design-Definition
.6 Lösungsbewertung
11.4 Die Geschäftsarchitektur-Perspektive
11.4.1 Scope des Change-Vorhabens
.1 Breite des Change
.2 Tiefe des Change
.3 Nutzen und umgesetzte Lösungen
.4 Umsetzungsansatz
.5 Zentrale Annahmen
11.4.2 Scope der Business-Analyse
.1 Auftraggeber des Change
.2 Zielobjekte des Change
.3 Die Rolle des Business-Analysten
.4 Ergebnisse der Business-Analyse
11.4.3 Referenzmodelle und Techniken
.1 Referenzmodelle
.2 Techniken
11.4.4 Basiskompetenzen
11.4.5 Auswirkungen auf die Wissensgebiete
.1 Planung und Überwachung der Business-Analyse
.2 Erhebung und Zusammenarbeit
.3 Management des Anforderungs-Lebenszyklus
.4 Strategische Analyse
.5 Anforderungsanalyse und Design-Definition
.6 Lösungsbewertung
11.5 Die Business-Process-Management-Perspektive
11.5.1 Scope des Change-Vorhabens
.1 Breite des Change
.2 Tiefe des Change
.3 Nutzen und umgesetzte Lösungen
.4 Umsetzungsansatz
.5 Zentrale Annahmen
11.5.2 Scope der Business-Analyse
.1 Auftraggeber des Change
.2 Ziele und Akteure des Change
.3 Die Rolle des Business-Analysten
.4 Ergebnisse der Business-Analyse
11.5.3 Frameworks, Methoden und Techniken
.1 Frameworks
.2 Methoden
.3 Techniken
11.5.4 Basiskompetenzen
11.5.5 Auswirkungen auf die Wissensgebiete
.1 Planung und Überwachung der Business-Analyse
.2 Erhebung und Zusammenarbeit
.3 Management des Anforderungs-Lebenszyklus
.5 Anforderungsanalyse und Design-Definition
.4 Strategische Analyse
.6 Lösungsbewertung
Anhang A: Glossar
Anhang B: Techniken mit Aufgabenzuordnung
Anhang C: Contributors
Body of Knowledge Committee
Body of Knowledge Operations Team
Content Contributors
Expert Advisory and Review Group
Practitioner Reviewers
Agile Extension
Enterprise Business Analysis Extension Draft
Other Significant Contributors
Additional Thanks
Version 2.0
Body of Knowledge Committee
Content Contributors
Expert Advisory and Review Group
Practitioner Reviewers
Version 1.6
Body of Knowledge Committee
Contributors to Version 1.6
Reviewers of Version 1.6
Anhang D: Summary of Changes from BABOK® Guide v 2.0
Overview
Introduction
Business Analysis
Business Analysis Key Concepts
Business Analysis Core Concept Model™ (BACCM™) (NEW)
Requirements and Design (NEW)
Knowledge Areas
Business Analysis Planning and Monitoring
Elicitation (Version 2.0 name) is now Elicitation and Collaboration (Version 3 name)
Requirements Management and Communication (Version 2.0 name) is now Requirements Life Cycle Management (Version 3 name)
Enterprise Analysis (Version 2.0 name) is now Strategy Analysis (Version 3 name)
Requirements Analysis (Version 2.0 name) is now Requirements Analysis and Design Definition (Version 3 name)
Solution Assessment and Validation (Version 2.0 name) is now Solution Evaluation (Version 3 name)
Underlying Competencies
Vorwort
Das im Oktober 2003 in Toronto, Kanada, gegründete IIBA® (International Institute of Business Analysis TM) unterstützt die Community der Business-Analysten dabei,
den Wert und die Arbeit der Business-Analysten bewusst zu machen und deren Leistung anzuerkennen
einen „Business Analysis Body of Knowledge
®
(BABOK
®
)“ zu erarbeiten
ein Forum zur Weiterentwicklung und zum Wissensaustausch für den Beruf des Business-Analysten zu schaffen
fachlich qualifizierte Experten der Business-Analyse anzuerkennen und diese Anerkennung durch ein international etabliertes Zertifikat zu
bescheinigen.
Das Body of Knowledge Committee wurde im Januar 2004 gebildet, um einen globalen Standard für den Beruf des Business-Analysten zu entwerfen. Im Januar 2005 hat das IIBA® die Version 1.0 des „A Guide to the Business Analysis Body of Knowledge®“ mit einem Gliederungsvorschlag und zentralen Definitionen veröffentlicht und dazu Feedback und Kommentare eingeholt. Die im Oktober 2005 veröffentlichte Version 1.4 enthielt bereits vorläufige Inhalte zu einzelnen Wissensgebieten. Die im Juni 2006 als Entwurf veröffentlichte Version 1.6 (aktualisiert im Oktober 2008) beinhaltete detaillierte Informationen zu den meisten Wissensgebieten.
Die Version 2.0 entstand mithilfe von Arbeitsgruppen, Experten der Business-Analyse und Feedback aus öffentlichen Reviews. Version 2.0 führte neue Konzepte ein wie zum Beispiel das Klassifikationsschema von Anforderungen und Input-Output-Modelle. Version 2.0 wurde 2009 veröffentlicht und entwickelte sich zu einem global anerkannten Standard für die praktische Arbeit der Business-Analyse.
Auf der Grundlage der Version 2.0 hat das IIBA® erneut umfangreiches Feedback von Fachexperten und angrenzenden Berufsgruppen eingeholt. Das Body of Knowledge Committee arbeitete mit Expertenteams daran, die Inhalte zu überprüfen und zu aktualisieren. Dieser überarbeitete Entwurf des „A Guide to the Business Analysis Body of Knowledge® (BABOK®)“ wurde für ein umfassendes Review freigegeben. Tausende Rückmeldungen flossen in die hier vorliegende Version 3.0 ein.
Ziele der Revision des BABOK® waren es,
neue Konzepte und Praktiken zu berücksichtigen, die seit der letzten Version entstanden waren
dabei die größere Reichweite der Business-Analyse und die Weiterent wicklung des Fachgebietes zu berücksichtigen
Lessons Learned der Nutzer der vorhergehenden Version zu berücksichtigen
die Lesbarkeit und Anwendbarkeit zu steigern
die Konsistenz und Qualität von Text und Abbildungen zu verbessern
die Wissensgebiete besser zu integrieren und Überschneidungen zu beseitigen
Konsistenz mit anderen Standards zu verbessern, die im Zusammenhang mit der Business-Analyse stehen.
Die wichtigsten Änderungen dieser Version sind:
die Berücksichtigung des Business Analysis
Core Concept
Model
TM
(BACCM
TM
)
der größere Einfluss der Rolle der Business-Analyse bei der Schaffung besserer Ergebnisse
die Integration von Perspektiven, in denen spezialisierte Wege beschrieben werden, auf denen der Business-Analyst für ein Unternehmen Werte schaffen kann
neue und erweiterte grundlegende Kompetenzen, aus denen die unterschiedlichen Sets von Fähigkeiten des Business-Analysten deutlich werden
neue Techniken, die sich in der Praxis der Business-Analyse entwickelt haben oder in sie übernommen wurden.
Diese Publikation ersetzt die Version 2.0 des „A Guide to the Business Analysis Body of Knowledge® (BABOK®)“.
Der BABOK®-Leitfaden enthält die Beschreibung allgemein akzeptierter Praktiken in Bereich der Business-Analyse. Der Inhalt dieser Version wurde durch Reviews von Praktikern, Erhebungen in der Community der Business-Analyse und durch Beratungen mit Experten des Fachgebietes überprüft und verifiziert. IIBA® verfügt über Daten, mit denen sich zeigen lässt, dass die hier beschriebenen Aufgaben und Techniken von der Mehrheit der praktizierenden Business-Analysten genutzt werden. So ist die Behauptung berechtigt, dass die hier beschriebenen Aufgaben und Techniken in nahezu allen Kontexten, in denen Business-Analysen stattfinden, genutzt werden können.
Der BABOK®-Leitfaden soll aber nicht den Eindruck erwecken, als wenn die hier beschriebenen Praktiken immer und unter allen Umständen auch umgesetzt werden müssen. Immer müssen die konkreten Bedingungen beachtet werden, unter denen Business-Analyse stattfindet. Auch können derzeit noch nicht allgemein akzeptierte Praktiken ebenso nützlich oder sogar nützlicher sein als die hier beschriebenen. Wenn solche Praktiken sich weiter verbreiten, werden sie in spätere Auflagen des BABOK®-Leitfadens aufgenommen. Das IIBA® ermutigt alle Praktiker der Business-Analyse, für neue Entwicklungen und Ideen offen zu sein, und ermuntert zu Innovation in diesem Gebiet.
Das IIBA® und die Community der Business-Analyse möchten allen danken, die für die Entwicklung dieser Version Zeit und Mühen aufgewendet haben, aber auch jenen, die auf anderen Wegen informelles Feedback gegeben haben.
Die deutsche Fassung des IIBA® BABOK® wurde von den Österreichischen und Schweizer Chaptern des IIBA® ‚ der „Österreichische Vereinigung für Organisation und Management“ (ÖVO) und „Schweizerische Gesellschaft für Organisation und Management“ (SGO) übersetzt. Federführend verantwortlich für die Übersetzung sind Gerd Nanz und Götz Schmidt. Folgende Personen haben Teile der Version 3.0 übersetzt: Jean-Claude Brunner, Wolfgang Lachkovics, Frederik Muth, Gerd Nanz, Axel-Bruno Naumann, Götz Schmidt, David Steinmetz. An den fachlichen Reviews waren neben den oben genannten Übersetzern folgende Personen beteiligt: Peter Gerstbach, Linda Perkal, Jörg Rainer, Michael Reiter, Sonja Schuster, Michael Zambiasi.
Dieser BABOK® ist die Basis für die individuelle Zertifizierung von Business-Analysten in den deutschsprachigen Ländern. Die Zertifizierung wird gemeinsam mit dem IIBA® vorgenommen, so dass es weltweit einen Standard und eine global akzeptierte individuelle Zertifizierung zum Business-Analysten gibt.
Hinweis: In diesem Leitfaden wird immer nur die männliche Form verwendet (z.B. Experte, Analytiker, Projektmanager). Dies geschieht ausschließlich aus Gründen der sprachlichen Qualität des Textes. Selbstverständlich sind in all diesen Fällen auch die weiblichen Adressaten oder Rollen gemeint.
Hier wird der Begriff „Organization“ mit Organisation übersetzt. Organisation steht für jedes System, in dem Business-Analyse stattfindet oder stattfinden kann. Zu dem Begriff Organisation gehören in dieser Publikation neben Unternehmen auch Behörden, Verwaltungen, Vereine, gemeinnützige Einrichtungen usw. Damit können allerdings Verwechslungen mit dem strukturellen Begriff Organisation (gleichbedeutend mit Struktur, Aufbau, Prozessorganisation) entstehen.
1 Einleitung
Der Leitfaden zur Business-Analyse(Guide to the Business Analysis Body of Knowledge®, BABOK® Guide) ist der weltweit anerkannte Standard für die Praxis der Business-Analyse. Der BABOK®-Leitfaden beschreibt die Wissensgebiete der Business-Analyse (knowledge areas), Aufgaben (tasks), zugrunde liegende Basiskompetenzen (underlying competencies), Techniken (techniques) und Perspektiven (perspectives), die dazu dienen, die Business-Analyse zu bewältigen.
1.1 Zweck des BABOK®-Leitfadens
Der wesentliche Zweck dieses Leitfadens ist es, die Berufspraxis der Business-Analyse zu definieren und eine Zusammenstellung allgemein akzeptierter Praktiken anzubieten. Der Leitfaden hilft Praktikern, die Fähigkeiten zu diskutieren und zu definieren, die notwendig sind, um Business-Analyse effektiv durchzuführen. Er hilft ebenfalls allen, die mit Business-Analysten zusammenarbeiten oder diese beschäftigen, zu verstehen, welche Fähigkeiten und welches Wissen sie von einem erfahrenen Business-Analysten erwarten können.
Business-Analyse ist ein weit gefasstes Berufsbild, in dem Business-Analysten für verschiedene Vorhaben in Unternehmen tätig werden können. Praktiker können dabei unterschiedliche Kompetenzen, Fähigkeiten, Begrifflichkeiten, Eigenschaften sowie unterschiedliches Wissen einsetzen, wenn sie Aufgaben der Business-Analyse ausüben. Der BABOK®-Leitfaden enthält einen allgemeinen Bezugsrahmen (framework) für alle relevanten Perspektiven. Er beschreibt dazu die Aufgaben der Business-Analyse, die ausgeübt werden, um eine Veränderung angemessen zu analysieren oder die Notwendigkeit einer Veränderung zu bewerten. Die konkrete Ausprägung dieser Aufgaben, ihre Reihenfolge und ihre relative Wichtigkeit mögen dabei durchaus variieren, je nachdem, wer ein Vorhaben übernimmt oder um welches Vorhaben es sich im einzelnen Fall handelt.
Die sechs Wissensgebiete des BABOK®-Leitfadens (Planung und Überwachung der Business-Analyse, Erhebung und Zusammenarbeit, Management des Anforderungs-Lebenszyklus, Strategische Analyse, Anforderungsanalyse und Design-Definition, Lösungsbewertung) beschreiben die Ausübung der Business-Analyse innerhalb eines Projektes oder bei der Weiterentwicklung oder kontinuierlichen Verbesserung eines Unternehmens. Die nachfolgende Grafik zeigt, wie drei der Wissensgebiete die Bereitstellung betrieblicher Werte bzw. betrieblichen Nutzens (business value) vor, während und nach dem Lebenszyklus eines Projekts unterstützen.
Abb.1.1.1: Business-Analyse über Projekte hinaus
1.2 Was ist Business-Analyse?
Business-Analyse ist die Tätigkeit, Change in einem Unternehmen zu ermöglichen, indem sie Bedarfe definiert und Lösungen empfiehlt, die den Stakeholdern Nutzen bringen. Business-Analyse ermöglicht es einem Unternehmen, Bedarfe und Gründe für Veränderung zu artikulieren und Lösungen zu entwerfen und zu beschreiben, die für das Unternehmen wertvoll/wertschöpfend sind.
Business-Analyse wird in verschiedenen Vorhaben in einem Unternehmen ausgeübt. Die Vorhaben können strategischer, taktischer oder operativer Art sein. Business-Analyse kann innerhalb eines Projektes ausgeübt werden oder bei der Weiterentwicklung eines Unternehmens und dessen kontinuierlicher Verbesserung. Sie kann eingesetzt werden, um den Ist-Zustand zu verstehen, den Soll-Zustand zu definieren und die benötigten Aufgaben zu bestimmen, um vom Ist- zum Soll-Zustand zu kommen.
Business-Analyse kann aus verschiedenen Perspektiven durchgeführt werden. Der BABOK®-Leitfaden beschreibt mehrere dieser Perspektiven: Agil, Business Intelligence, IT, Geschäftsarchitektur und Business Process Management. Eine Perspektive stellt eine Art Linse dar, durch die ein Business-Analyst seine Aufgaben in dem jeweiligen Kontext sieht. Eine oder mehrere der Perspektiven können auf ein Vorhaben zutreffen. Die im BABOK®-Leitfaden vorgestellten Perspektiven stellen weder alle Kontexte der Business-Analyse dar, noch bilden sie eine vollständige Zusammenstellung aller Anwendungsmöglichkeiten der Business-Analyse.
1.3 Wer ist ein Business-Analyst?
Ein Business-Analyst ist jeder, der die im BABOK®-Leitfaden beschriebenen Business Analyse-Aktivitäten durchführt, unabhängig von der Stellenbezeichnung oder der organisatorischen Rolle.
Der Business-Analyst ist dafür verantwortlich, Informationen zu ermitteln, zu ordnen und zu analysieren. Diese Informationen stammen aus einer Vielzahl von Quellen in einem Unternehmen, u.a. IT-Werkzeugen, Geschäftsprozessen, Dokumenten und Stakeholdern. Der Business-Analyst ist verantwortlich dafür, dass die tatsächlichen Bedarfe der Stakeholder erhoben werden (was häufig die Untersuchung und Klärung der geäußerten Wünsche beinhaltet), um tieferliegende Anliegen und Ursachen zu bestimmen.
Der Business-Analyst ist daran beteiligt, die entworfenen und gelieferten Lösungen mit den Bedarfen der Stakeholder abzustimmen. Zu den Aktivitäten der Business-Analyse gehören:
Probleme und Ziele des Unternehmens verstehen
Bedarfe und Lösungen analysieren
Strategien entwickeln
Veränderung voranbringen
Zusammenarbeit mit und unter den Stakeholdern moderieren.
Weitere gebräuchliche Bezeichnungen für Personen, die Business-Analyse ausüben, sind
Unternehmensarchitekt
Business-System-Analyst
Datenanalyst
Unternehmensanalyst
Managementberater
Prozessanalyst
Produktmanager
Produktverantwortlicher
Requirements Engineer
Systemanalyst.
1.4 Aufbau des BABOK®-Leitfadens
Der Kern des BABOK®-Leitfadens sind die Aufgaben der Business-Analyse, die in Wissensgebiete unterteilt sind. Wissensgebiete sind eine Sammlung logisch zusammengehöriger (aber nicht unbedingt zeitlich aufeinanderfolgender) Aufgaben. Diese Aufgaben beschreiben die spezifischen Aktivitäten, die notwendig und sinnvoll sind, um den Zweck des zugehörigen Wissensgebiets zu erreichen.
Kernbegriffe der Business-Analyse, Basiskompetenzen, Techniken und Perspektiven sind Abschnitte des erweiterten Inhalts des BABOK®-Leitfadens. Sie helfen dem Business-Analysten, Aufgaben der Business- Analyse besser durchzuführen.
Kernbegriffe der Business-Analyse
definieren die zentralen Begriffe, die notwendig sind, um den Inhalt, die Konzepte und Ideen des BABOK
®
-Leitfadens zu verstehen.
Basiskompetenzen
beschreiben Verhaltensweisen, Charaktereigenschaften, Kenntnisse und persönliche Qualitäten, die für eine effektive Ausübung der Business-Analyse notwendig sind.
Techniken
bieten Hilfen, um Aufgaben der Business-Analyse zu erledigen. Mit den beschriebenen Techniken sollen die gebräuchlichsten und in der Community der Business-Analyse am weitesten verbreiteten Techniken abgedeckt werden.
Perspektiven
beschreiben verschiedene Sichten der Business-Analyse. Perspektiven helfen dem Business-Analysten, von verschiedenen Standpunkten Aufgaben der Business Analyse im jeweiligen Kontext eines Vorhabens besser auszuführen.
1.4.1 Kernbegriffe
Das Kapitel „Schlüsselkonzepte der Business-Analyse“ (business analysis key concepts) (Kap. 2) liefert die Kernideen, die für das Verständnis des BABOK®-Leitfadens benötigt werden.
Das Kapitel enthält:
Kernkonzept-Modell der Business-Analyse
Kernbegriffe
Klassifikationsschema von Anforderungen
Stakeholder
Anforderungen und
Designs
.
1.4.2 Wissensgebiete
Wissensgebiete sind zusammengehörige Bereiche der Expertise der Business-Analyse, die aus verschiedene Aufgaben bestehen.
Die sechs Wissensgebiete sind:
Planung und Überwachung der Business-Analyse
Beschreibt die Aufgaben des Business-Analysten zur Organisation und Koordination der Aktivitäten von Business-Analysten und Stakeholdern. Diese Aufgaben liefern Ergebnisse, die als Schlüssel-Inputs und Vorlagen für andere Aufgaben des BABOK
®
-Leitfadens dienen.
Erhebung
und Zusammenarbeit
Beschreibt die Aufgaben des Business-Analysten zur Vorbereitung und Durchführung von Erhebungen und zur Bestätigung der Ergebnisse. Das Wissensgebiet beschreibt zudem die Kommunikation mit Stakeholdern, sobald Informationen zur Business-Analyse zusammengestellt sind, wie auch die fortlaufende Zusammenarbeit mit den betroffenen Stakeholdern während der Business-Analyse.
Management des
Anforderungs-Lebenszyklus
Beschreibt die Aufgaben des Business-Analysten zum Management und zur Pflege von Anforderungen und von Informationen zum Design von deren Entstehen bis zu deren Auslaufen. Dazu wird beschrieben, wie sinnvolle Beziehungen zwischen verwandten Anforderungen und Designs hergestellt werden, wie vorgeschlagene Änderungen an Anforderungen und Designs bewertet und analysiert werden und wie Einigkeit bezüglich vorgeschlagener Änderungen erreicht wird.
Strategische Analyse
Beschreibt, was der Business-Analyst tun muss, um zusammen mit den Stakeholdern strategisch oder operativ wichtigen Bedarf zu identifizieren, dem Unternehmen zu helfen, diesen Bedarf zu adressieren und die sich für diese Veränderung ergebende Strategie mit Strategien auf höherem und niedrigerem Level abzustimmen.
Anforderungsanalyse und Design-Definition
Beschreibt die Aufgaben des Business-Analysten zur Strukturierung und Organisation von ermittelten Anforderungen, zur Spezifikation und Modellierung von Anforderungen und Designs, zur Verifizierung und
Validierung
von Informationen, zur Identifikation von Lösungsoptionen und zur Einschätzung des potentiellen Nutzens jeder Lösungsoption. Dieses Wissensgebiet deckt die inkrementellen und iterativen Aktivitäten ab, vom initialen Konzept und Erkennen des Bedarfs bis zur Umsetzung der Bedarfe in eine spezifische, empfohlene Lösung.
Lösungsbewertung
Beschreibt die Aufgaben des Business-Analysten zur Bewertung der Leistungsfähigkeit und des Nutzens einer Lösung, die in dem Unternehmen eingesetzt wird, und zu Empfehlungen, wie Hindernisse und Beschränkungen beseitigt werden, die der Erreichung der Ziele im Wege stehen.
Die folgende Abbildung zeigt die generellen Zusammenhänge zwischen den Wissensgebieten.
Abb.1.4.1: Zusammenhänge zwischen den Wissensgebieten
1.4.3 Aufgaben
Eine Aufgabe beschreibt einen abgrenzbaren Arbeitsabschnitt, der formal oder informal als Teil der Business-Analyse ausgeführt werden kann. Der BABOK®-Leitfaden definiert eine Liste von Business-Analyse-Aufgaben. Die Aufgaben können generell in den verschiedenen Einsatzgebieten der Business-Analyse – unabhängig von der Art des Vorhabens – durchgeführt werden. Ein Business-Analyst kann auch andere Aktivitäten durchführen, die von seinem Unternehmen vorgeschrieben werden, diese zusätzlichen Aktivitäten sind aber nicht als Teil des Berufsbildes der Business-Analyse anzusehen.
Aufgaben sind in Wissensgebiete gruppiert. Der Business-Analyst führt die Aufgaben aller Wissensgebiete entweder nacheinander, iterativ oder gleichzeitig aus. Der BABOK®-Leitfaden schreibt keinen Prozess vor, in der die Aufgaben durchzuführen sind. Aufgaben können in jeglicher Reihenfolge durchgeführt werden, solange die notwendigen Inputs für eine Aufgabe vorliegen. Ein Business-Analyse-Vorhaben kann mit jeder Aufgabe starten; die Ermittlung des Ist-Zustands oder die Messung der Performance einer Lösung sind allerdings typische Kandidaten für den Beginn.
Jede Aufgabe des BABOK®-Leitfadens wird in folgendem Format beschrieben:
Zweck
Beschreibung
Inputs
Elemente
Leitfäden und Werkzeuge
Techniken
Stakeholder
Outputs.
.1 Zweck
Der Abschnitt zum Zweck liefert eine kurze Beschreibung dafür, weshalb ein Business-Analyst diese Aufgabe durchführt und welcher Wert dabei geschaffen wird.
.2 Beschreibung
Der Abschnitt zur Beschreibung erläutert mit mehr Details, was die Aufgabe umfasst, warum sie ausgeübt wird und was sie erreichen sollte.
.3 Inputs
Der Abschnitt zu Inputs listet auf, was eine Aufgabe benötigt bzw. was sie auslöst. Inputs können Informationen sein, die verarbeitet oder transformiert werden, um einen Output zu produzieren. Inputs umfassen die notwendigen Angaben und Hilfsmittel, um eine Aufgabe zu beginnen. Sie können explizit außerhalb des Arbeitsgebietes der Business-Analyse entstanden oder durch eine Aufgabe der Business-Analyse geschaffen worden sein. Inputs, die außerhalb des Arbeitsgebietes der Business-Analyse entstanden sind, werden durch den Hinweis „(extern)“ in der Inputliste gekennzeichnet.
Wenn es einen Input gibt, kann daraus nicht geschlossen werden, dass das zugehörige Lieferobjekt damit schon vollständig sei. Der Input muss nur soweit fertig gestellt sein, dass Folgearbeiten beginnen können. Während des Lebenszyklus eines Vorhabens kann es beliebig viele Versionen eines Inputs geben. Der Abschnitt zu Inputs enthält eine grafische Darstellung der Inputs und Outputs, der anderen Aufgaben, die die Outputs nutzen, sowie der Leitfäden und Werkzeuge, die in den Aufgaben genannt werden.
.4 Elemente
Der Abschnitt zu Elementen beschreibt die Kernbegriffe, die zum Verständnis wichtig sind, wie eine Aufgabe erledigt wird. Die Elemente sind bei der Durchführung nicht zwingend vorgeschrieben; ihr Einsatz hängt vom jeweiligen Vorgehen ab.
.5 Leitfäden und Werkzeuge
Der Abschnitt zu Leitfäden (Vorlagen/Orientierungshilfen) und Werkzeugen listet die Ressourcen auf, die notwendig sind, um einen Input in einen Output zu transformieren. Ein Leitfaden liefert Instruktionen und Beschreibungen, warum und wie eine Aufgabe auszuführen ist. Ein Werkzeug wird genutzt, um eine Aufgabe zu erledigen. Leitfäden und Werkzeuge können auch Output anderer Aufgaben sein.
.6 Techniken
Der Abschnitt zu Techniken listet die Techniken auf, die für diese Aufgabe der Business-Analyse eingesetzt werden können.
.7 Stakeholder
Der Abschnitt zu Stakeholdern setzt sich aus einer generischen Liste von Stakeholdern zusammen, die typischerweise an der Durchführung der Aufgabe beteiligt oder von dieser betroffen sind. Der BABOK®-Leitfaden schreibt nicht vor, dass diese Rollen in jedem Vorhaben der Business-Analyse ausgefüllt oder gelebt werden müssen.
.8 Outputs
Der Abschnitt zu Outputs beschreibt die Ergebnisse, die bei der Durchführung der Aufgabe entstehen. Outputs werden geschaffen, verändert oder sie ändern ihren Zustand, wenn eine Aufgabe erfolgreich abgeschlossen ist. Ein Output kann ein selbstständiges Lieferobjekt sein oder Bestandteil eines übergeordneten Objekts. Die Form des Outputs hängt vom jeweiligen Vorhaben, den verwendeten Standards eines Unternehmens und dem Urteil des Business-Analysten ab, wie die Informationsbedürfnisse der Schlüssel-Stakeholder am besten abgedeckt werden können.
Ähnlich wie bei Inputs gilt, dass die Ausführung einer Aufgabe abgeschlossen sein kann, ohne dass der Output einen endgültigen Zustand erreicht hat. Aufgaben, die einen bestimmten Output nutzen, müssen nicht zwangsläufig auf dessen Vollständigkeit warten, um selbst zu beginnen.
1.4.4 Basiskompetenzen
Basiskompetenzen berücksichtigen Kenntnisse, Fähigkeiten, Verhaltensweisen, Charaktereigenschaften und persönliche Qualitäten, die dazu beitragen, dass der Business-Analyst seine Rolle erfolgreich ausfüllen kann. Diese Basiskompetenzen gelten nicht nur für das Berufsbild der Business-Analyse. Eine erfolgreiche Ausübung von Aufgaben und Techniken hängt jedoch häufig davon ab, ob eine oder mehrere Basiskompetenzen vorhanden sind.
Basiskompetenzen haben die folgende Struktur:
Zweck
Kernbeschreibung
Erfolgsmaßstäbe.
.1 Zweck
Der Abschnitt zum Zweck beschreibt, warum es für den Business-Analysten hilfreich ist, diese Basiskompetenz zu besitzen.
.2 Beschreibung
Der Abschnitt zur Beschreibunge enthält die Fähigkeiten und Expertise, die mit der Anwendung dieser Kompetenz verbunden sind.
.3 Erfolgsmaßstäbe
Der Abschnitt zu den Erfolgsmaßstäben beschreibt, wie bestimmt werden kann, ob eine Person dieser Basiskompetenz befähigt ist.
1.4.5 Techniken
Techniken bieten zusätzliche Informationen darüber, wie eine Aufgabe durchgeführt werden kann.
Die Liste der Techniken im BABOK®-Leitfaden erhebt keinen Anspruch auf Vollständigkeit. Es gibt verschiedene Techniken, die alternativ oder in Verbindung mit anderen Techniken angewendet werden können, um eine Aufgabe zu erfüllen. Der Business-Analyst wird ermutigt, bestehende Techniken abzuwandeln oder neue zu entwickeln, die seiner Situation und den Zielen seiner Aufgaben am besten dienlich sind.
Techniken haben die folgende Struktur:
Zweck
Beschreibung
Elemente
Bewertung.
.1 Zweck
Der Abschnitt zum Zweck beschreibt, wofür die Technik genutzt wird und zu welchen Gegebenheiten sie typischerweise eingesetzt wird.
.2 Beschreibung
Der Abschnitt zur Beschreibung erläutert die Technik und wie sie durchgeführt wird.
.3 Elemente
Der Abschnitt zu Elementen beschreibt Schlüsselkonzepte, die dem Verständnis dafür dienen, wie die Technik eingesetzt wird.
.4 Bewertung
Der Abschnitt zur Bewertung beschreibt Stärken und Grenzen der Technik.
1.4.6 Perspektiven
Perspektiven werden in der Business-Analyse genutzt, um im speziellen Kontext des Vorhabens die Aufgaben und Techniken der Business-Analyse zu schärfen. Viele Vorhaben nutzen typischerweise eine oder mehrere Perspektiven. Die Perspektiven im BABOK®-Leitfaden sind:
Agil
Business Intelligence
Informationstechnologie
Geschäftsarchitektur
Business Process Management (BPM).
Diese fünf Perspektiven decken nicht alle Blickwinkel ab, die in der Business-Analyse eingenommen werden können. Sie repräsentieren lediglich einige der Perspektiven der Business-Analyse, die zum Zeitpunkt des Erstellens des BABOK®-Leitfadens weit verbreitet sind.
Die Perspektiven schließen sich nicht gegenseitig aus, so dass in einem Vorhaben mehr als eine Perspektive eingenommen werden kann.
Perspektiven haben die folgende Struktur:
Scope des Change-Vorhabens
Scope der Business-Analyse
Methoden, Herangehensweisen und Techniken
Basiskompetenzen
Auswirkungen auf die Wissensgebiete.
.1 Scope des Change-Vorhabens
Der Abschnitt zum Scope des Change-Vorhabens beschreibt, welche Teile des Unternehmens von der Veränderung betroffen sind, falls diese Perspektive eingenommen wird, und in welchem Umfang Ziele und operatives Geschäft des Unternehmens beeinflusst werden. Der Scope des Change-Vorhabens zeigt auch, welche Probleme gelöst werden müssen, wie dabei vorzugehen ist und wie der geschaffene Wert gemessen werden kann.
.2 Scope der Business-Analyse
Der Abschnitt zum Scope der Business-Analyse beschreibt die Schlüssel-Stakeholder inklusive eines Profils typischer Sponsoren, die betroffene Zielgruppe und die Rolle des Business-Analysten in dem Vorhaben. Der Abschnitt erläutert auch typische Ergebnisse der Business-Analyse, die bei dieser Perspektive erwartet werden.
.3 Methoden, Herangehensweisen und Techniken
Bei jeder Perspektive gibt es eine andere Zusammenstellung dieses Abschnitts. In jedem Fall werden die Methoden, Herangehensweisen oder Techniken beschrieben, die für die Anwendung der Business-Analyse in dieser Perspektive gebräuchlich und spezifisch sind. Methoden und Herangehensweisen sind spezialisierte Wege, die Arbeiten der Business-Analyse durchzuführen. Die Techniken dieses Abschnitts sind Techniken, die nicht im Kapitel 10 (Techniken) des BABOK®-Leitfadens enthalten, sondern besonders für diese Perspektive relevant sind.
In der Perspektive „Geschäftsarchitektur“ sind Referenzmodelle anstelle von Methoden und Herangehensweisen aufgeführt. In der Perspektive „Business Process Management“ werden Frameworks (Rahmenmodelle/Bezugsrahmen) anstelle von Herangehensweisen behandelt.
.4 Basiskompetenzen
Der Abschnitt zu Basiskompetenzen beschreibt die Kompetenzen, die in dieser Perspektive besonders häufig benötigt werden.
.5 Auswirkungen auf die Wissensgebiete
Der Abschnitt zu den Auswirkungen auf die Wissensgebiete beschreibt, wie Wissensgebiete angewandt oder modifiziert werden. Er erläutert auch, wie spezifische Aktivitäten in einer Perspektive zu den Aufgaben des BABOK®-Leitfadens passen.
2 Schlüsselkonzepte der Business-Analyse
Das Kapitel „Schlüsselkonzepte der Business-Analyse“ bietet Informationen, die Grundlage für alle anderen Inhalte, Konzepte und Ideen des BABOK®-Leitfaden sind.
Es liefert dem Business-Analysten Einsichten in die zentralen Ideen, die für das Verständnis und die Anwendung des BABOK®-Leitfadens in seiner täglichen Praxis der Business-Analyse notwendig sind.
Dieses Kapitel enthält:
Kernkonzept-Modell der Business-Analyse
(Business Analysis
Core Concept
Model
™
/BACCM
™
)
:
Darin wird ein konzeptioneller Rahmen für den Beruf des
Business-Analysten
definiert.
Kernbegriffe:
Das sind Definitionen der wesentlichen Konzepte, die wegen ihrer Bedeutung für den BABOK
®
-Leitfaden hervorgehoben werden.
Klassifikationsschema von Anforderungen:
Es werden Anforderungsebenen und
-typen
identifiziert, die den Business-Analysten und andere
Stakeholder
bei der Klassifikation von Anforderungen unterstützen.
Stakeholder:
Hier werden Rollen definiert und Gruppen oder Einzelpersonen charakterisiert, die an den Aktivitäten der Business-Analyse in einem Change-Prozess teilhaben oder davon betroffen sind.
Anforderungen und Designs
: Es wird der Unterschied zwischen und die Wichtigkeit von Anforderungen und
Designs
im Zusammenhang mit der Business-Analyse beschrieben.
2.1 Kernkonzept-Modell der Business-Analyse
Das Kernkonzept-Modell der Business-Analyse (BACCM™) stellt den Rahmen für das Konzept der Business-Analyse dar. Es erklärt die Business-Analyse und zeigt, was es für diejenigen bedeutet, die mit der Durchführung der Aufgaben der Business-Analyse betraut sind. Es ist unabhängig von der Perspektive, der Branche, der gewählten Methodik oder der Ebene in der Organisation. Es besteht aus sechs Begriffen, die für alle Business-Analysten das gleiche bedeuten, mit deren Hilfe sie über die Business-Analyse diskutieren können und deren Bedeutung in der üblichen Terminologie sie kennen. Jeder dieser Begriffe wird als ein Kernkonzept betrachtet.
Die sechs Kernkonzepte sind: Change, Bedarf, Lösung, Stakeholder, Nutzen und Kontext. Jedes Kernkonzept ist von grundlegender Bedeutung für die Praxis der Business-Analyse. Alle Konzepte sind gleichwertig und notwendig. Jedes Kernkonzept wird durch die anderen fünf Kernkonzepte definiert und kann nicht verstanden werden, ohne die anderen Konzepte vollständig verstanden zu haben. Kein Konzept hat eine größere Bedeutung oder Signifikanz als ein anderes Konzept. Diese Konzepte helfen, die Art der Informationen zu verstehen, die in der Business-Analyse erhoben, analysiert oder verwaltet werden.
Das BACCM™ kann verwendet werden, um
den Beruf des Business-Analysten und das Arbeitsgebiet der Business-Analyse zu beschreiben
über Business-Analyse mit umgangssprachlicher Terminologie zu kommunizieren
die Beziehungen der Kernkonzepte in der Business-Analyse zu bewerten
die Qualität der Business-Analyse durch eine ganzheitliche Beurteilung der Beziehungen zwischen diesen sechs Konzepten zu steigern
den Einfluss dieser Konzepte und Beziehungen zu jedem Zeitpunkt bei der Arbeit zu bewerten, um sowohl eine Basis zu legen als auch den weiterführenden Weg zu gestalten.
Kernkonzept
Beschreibung
Change
Der Akt der Veränderung als Reaktion auf einen Bedarf.
Changes werden durchgeführt, um die Leistung eines Unternehmens zu verbessern.
Diese Verbesserungen sind bewusst und werden durch die Aktivitäten der Business-Analyse kontrolliert.
Bedarf
Ein Problem, das zu lösen, oder eine Chance, die wahrzunehmen ist.
Der Bedarf kann Changes auslösen, wenn Stakeholder zum Handeln motiviert werden.
Changes können auch einen Bedarf auslösen, wenn durch sie der Nutzen bestehender Lösungen vermindert oder erhöht wird.
Lösung
Ein bestimmter Weg, um einen Bedarf (oder auch mehrere) in einem bestimmten Kontext zu befriedigen.
Eine Lösung befriedigt den Bedarf des Stakeholders, indem ein aufgezeigtes Problem beseitigt oder aus einer Chance ein Vorteil geschaffen wird.
Stakeholder
Eine Einzelperson oder eine Gruppe, die mit dem Change, dem Bedarf oder der Lösung in einer Beziehung steht.
Stakeholder werden meistens den Gruppen „ist interessiert am Change“, „ist betroffen vom Change“ oder „kann den Change beeinflussen“ zugeordnet.
Stakeholder werden gemäß deren Beziehung zum Bedarf, zum Change oder zur Lösung gruppiert.
Nutzen
Der Wert, die Bedeutung oder die Zweckmäßigkeit für den Stakeholder in einem bestimmten Kontext.
Der Nutzen kann als potentielle oder realisierte Rendite, als Zugewinn oder als Verbesserung gesehen werden. Die Verringerung eines Verlustes, eines Risikos oder die Reduzierung von Kosten stellt einen Nutzen dar.
Der Nutzen kann materiell oder immateriell sein. Materieller Nutzen ist direkt messbar und hat häufig eine signifikante monetäre Komponente. Immaterieller Nutzen kann nur indirekt gemessen werden. Immaterieller Nutzen hat häufig eine bedeutende Motivationskomponente wie die Reputation des Unternehmens oder die Moral der Mitarbeiter.
Manchmal kann der Nutzen absolut bewertet werden, in vielen Fällen aber nur als relative Größe eine Lösungsvariante ist aus der Sicht der Stakeholder nützlicher als andere.
Kontext
Die Umstände, die einen Change beeinflussen, die von einem Change selbst beeinflusst werden und die den Change verständlich machen.
Changes treten in einem Kontext auf. Der Kontext ist alles, was für den Change im Rahmen des gegebenen Umfeldes relevant ist. Zum Kontext können gehören: Einstellungen, Verhaltensweisen, Überzeugungen, Mitbewerber, Kultur, Demografie, Ziele, Regierung, Infrastruktur, Sprachen, Verluste, Prozesse, Produkte, Projekte, Vertrieb, Saison, Terminologie, Technik, Wetter und weitere Faktoren.
Tabelle 2.1.1: Das BACCM™
Die Kernkonzepte werden von Business-Analysten verwendet, um Qualität und Vollständigkeit ihrer Arbeit zu prüfen. In der Beschreibung jedes Wissensgebietes gibt es Beispiele, wie die Kernkonzepte für die einzelnen Aufgaben eingesetzt oder angewendet werden können. Während der Planung oder Durchführung einer Aufgabe oder Technik können Business-Analysten prüfen, wie jedes Kernkonzept durch Fragen angesprochen wird, wie z.B.:
Welche Arten von Changes machen wir?
Welche Bedürfnisse versuchen wir zu befriedigen?
Welche Lösungen schaffen oder adaptieren wir?
Welche Stakeholder sind eingebunden?
Was erachten Stakeholder als nützlich?
In welchem Kontext befinden wir uns, in welchem befindet sich die Lösung?
Wenn sich eines der Kernkonzepte verändert, sollten die Kernkonzepte und deren Beitrag zum Nutzen neu bewertet werden.
Abb.2.1.1: BACCM™
2.2 Kernbegriffe
Business-Analyse
Der BABOK®-Leitfaden beschreibt und definiert die Business-Analyse als die Praxis, Anforderungen zu ermitteln und Lösungen vorzuschlagen, die in Unternehmen Veränderungen (Changes) bewirken und Stakeholdern Nutzen bringen.
Weitere Informationen im Kapitel 1.2 „Was ist Business-Analyse?“
Information der Business-Analyse
Informationen der Business-Analyse sind alle Arten unterschiedlichster Informationen, die vom Business-Analysten analysiert, transformiert, zusammengefasst und berichtet werden. Es handelt sich um jede Art von Informationen, in jedem Detaillierungsgrad, die als Input für die Business-Analyse verwendet werden oder bei der Business-Analyse entstehen. Beispiele für Informationen der Business-Analyse sind Erhebungsergebnisse, Anforderungen, Designs, Lösungsvarianten, Lösungsumfang und Change-Strategien.
Es ist wichtig, den Gegenstand der Aktivitäten der Business-Analyse nicht nur auf die „Anforderungen“ zu beschränken, sondern generell auf „Informationen“ zu erweitern, um sicherzustellen, dass alle Inputs und Outputs der Business-Analyse zu deren Aufgaben und Aktivitäten gehören, so wie es im BABOK®-Leitfaden beschrieben wird. So sind alle oben genannten Beispiele Elemente bei der Umsetzung der Aufgabe „Informationsmanagement der Business-Analyse planen“. Würde der BABOK®-Leitfaden nur das „Anforderungsmanagement planen“ beschreiben, dann würden Outputs wie Erhebungsergebnisse, Lösungsvarianten und Change-Strategien nicht dazugehören.
Design
Ein Design ist eine nutzbare Darstellung einer Lösung. Das Design konzentriert sich auf die Festlegung, welcher Nutzen von einer fertigen Lösung realisiert werden kann. Dieses kann in der Form eines Dokumentes (oder einer Reihe von Dokumenten) dargestellt sein und je nach den Umständen sehr unterschiedlich aussehen.
Weitere Informationen im Kapitel 2.5 „Anforderungen und Designs“
Unternehmen
Ein Unternehmen ist ein System, das aus einer oder mehreren Organisationen und deren Lösungskonzepten besteht und bestimmte (in der Regel wirtschaftliche) Ziele verfolgt.
Diese Lösungskonzepte (auch organisatorische Fähigkeiten genannt) können Prozesse, Werkzeuge oder Informationen sein. Für die Zwecke der Business-Analyse können Unternehmensgrenzen in Bezug auf das konkrete Change-Vorhaben festgelegt werden und müssen nicht durch die Grenzen einer juristischen Person, eines Unternehmens oder einer Organisationseinheit bestimmt sein. Ein Unternehmen kann eine beliebige Anzahl von Geschäften, öffentlichen Aufgaben oder andere Organisationstypen enthalten.
Organisation
Eine Organisation ist eine autonome Einheit in einem Unternehmen, die von einem Einzelnen oder von einer Personenmehrheit geleitet wird, gemeinsamen Zielen verpflichtet ist und sich von anderen Einheiten abgrenzen lässt (institutionelle Sicht der Organisation). Organisationen sind dauerhaft eingerichtet, im Unterschied etwa zu Projektgruppen, die sich mit der Erledigung eines Auftrags wieder auflösen.
Plan
Ein Plan ist ein Vorschlag, wie etwas zu tun oder zu erreichen ist. Ein Plan ist eine Aufstellung von beispielsweise Ereignissen, Abhängigkeiten, Abfolgen, Planzeiten, Outputs, benötigten Materialien und Ressourcen und Stakeholdern (Beteiligten), die zusammenwirken, um etwas zu tun oder zu erreichen.
Anforderung
Eine Anforderung ist eine brauchbare Darstellung eines Bedarfs. Anforderungen konzentrieren sich darauf, zu verstehen, welche Art von Nutzen geliefert werden könnte, um diese Anforderung zu erfüllen. Die Anforderung kann in der Form eines Dokumentes (oder eine Reihe von Dokumenten) dargestellt werden und je nach Umständen sehr unterschiedlich aussehen.
Weitere Informationen im Kapitel 2.5 „Anforderungen und Designs“
Risiko
Ein Risiko ist die Unsicherheit über den Wert eines Change oder über die Wirksamkeit einer Lösung. Der Business-Analyst arbeitet mit anderen Stakeholdern zusammen, um Risiken zu identifizieren, zu bewerten und zu priorisieren und damit besser steuern zu können. Risiken sind so zu steuern, dass die Eintrittswahrscheinlichkeit für Ereignisse und deren Rahmenbedingungen besser abgeschätzt werden kann, etwa indem Folgen abgeschwächt, Gefahrenquellen beseitigt oder Gefahren vermieden werden, etwa durch die Entscheidung, gar nicht zu starten oder eine Aktivität nicht fortzusetzen oder auch das Risiko mit anderen Parteien zu teilen (Versicherung) oder das Risiko bewusst zu akzeptieren (evtl. sogar zu erhöhen), um Chancen wahrzunehmen.
2.3 Klassifikationsschema von Anforderungen
Für die Zwecke des BABOK®-Leitfadens beschreibt das folgende Klassifikationsschema die Anforderungen:
Betriebliche Anforderungen
:
Das sind Ziele oder gewünschte Ergebnisse, die einen Change-Prozess auslösen. Sie können sich auf das gesamte Unternehmen (Unternehmensziele), einen Geschäftsbereich (Bereichsziele) oder auf ein bestimmtes Vorhaben beziehen.
Stakeholder-Anforderungen:
Sie beschreiben die Bedürfnisse von Stakeholdern, die erfüllt sein müssen, damit die betrieblichen Anforderungen erfüllt werden können. Sie können als eine Brücke dienen zwischen betrieblichen Anforderungen und
Lösungsanforderungen
.
Lösungsanforderungen:
Sie beschreiben die Fähigkeiten und Qualitäten einer Lösung, welche die Stakeholder-Anforderungen erfüllt. Sie sind so weit detailliert, dass die Lösung entwickelt und implementiert werden kann. Lösungsanforderungen können in zwei Unterkategorien eingeteilt werden:
Funktionale Anforderungen
:
Sie beschreiben die Leistungen oder Fähigkeiten, die ein Produkt, ein Service oder eine sonstige Lösung dem Kunden oder
Anwender
bietet.
Nicht-funktionale Anforderungen oder Anforderungen an die Servicequalität:
Sie beziehen sich nicht direkt auf das funktionale Verhalten der Lösung, sondern beschreiben, unter welchen Bedingungen eine Lösung funktionsfähig bleiben muss oder welche Qualitäten die Lösung haben muss.
Überleitungsanforderungen
:
Das sind Anforderungen an eine Lösung oder ein System, bzw. Bedingungen, die gegeben sein müssen, um den Wechsel von dem heutigen Zustand in einen zukünftigen Zustand (Lösung) vollziehen zu können. Sie werden nach dem Abschluss des Change-Prozesses nicht mehr benötigt. Die Anforderungen unterscheiden sich somit von anderen, indem sie nur vorübergehender Natur sind. Überleitungsanforderungen betreffen Themen wie Datenkonvertierung, Schulungen und Sicherstellung des laufenden Geschäftsbetriebs während des Change.
Weitere Informationen im Kapitel 10.30 „Analyse nicht-funktionaler Anforderungen“
2.4 Stakeholder
Stakeholder sind Einzelpersonen oder Personengruppen, die eigene Interessen in ein Vorhaben einbringen, auf die Lösung Einfluss nehmen oder von der Lösung betroffen sind. Jede Aufgabe enthält eine Liste von Stakeholdern, die bei der Ausführung dieser Aufgabe mitarbeiten oder die von ihr betroffen sind. Der Business-Analyst hat direkt oder indirekt mit den Stakeholdern zu tun. Der BABOK®-Leitfaden schreibt nicht vor, dass alle Rollen für jedes einzelne Vorhaben vorhanden sein müssen. Die Stakeholder sind im Allgemeinen eine Quelle für Anforderungen, Annahmen oder Einschränkungen.
Die folgende Liste erhebt nicht den Anspruch darauf, alle möglichen Interessengruppen und Klassifikationen zu enthalten. Es gibt auch andere Rollenbezeichnungen für Personen, die zu diesen generisch gebildeten Rollen gehören. Viele Stakeholder lassen sich nicht eindeutig einer Rolle zuordnen. Andererseits kann eine einzelne Person gleichzeitig oder nacheinander mehr als eine Rolle erfüllen.
Für die Zwecke des BABOK®-Leitfadens enthält die Liste der Stakeholder folgende Rollen:
Business-Analyst
Kunde
Fachexperte
Anwender
Umsetzungsexperte
Support
Projektmanager
Regulierer
Sponsor/Auftraggeber
Lieferant
Tester
2.4.1 Business-Analyst
Der Business-Analyst ist in seiner Natur ein Stakeholder für alle Aktivitäten der Business-Analyse. Der BABOK®-Leitfaden unterstellt, dass der Business-Analyst für die Ausführung dieser Tätigkeiten zuständig und verantwortlich ist. In einigen Fällen kann der Business-Analyst auch für die Erledigung von Aktivitäten zuständig sein, die anderen Stakeholder-Rollen zugeordnet sind.
2.4.2 Kunde
Der Kunde ist ein Stakeholder, der Produkte oder Services des Unternehmens nutzt oder nutzen kann und der vertragliche oder moralische Ansprüche hat, die ein Unternehmen erfüllen muss.
2.4.3 Fachexperte
Der Fachexperte ist eine Person mit besonderen Kenntnissen in einem bestimmten Gebiet, das für ein Unternehmen wichtig oder für eine Lösung relevant ist.
Diese Rolle wird häufig von folgenden Personen ausgeübt: Anwender oder Personen mit fundierten Kenntnissen der Lösung, Manager, Prozessverantwortliche, Juristen, Berater und andere.
2.4.4 Anwender
Der Anwender ist ein Stakeholder, der direkt mit der Nutzung der Lösung zu tun hat. Anwender sind auch Beteiligte in einem Geschäftsprozess (sie nutzen die Ergebnisse vorgelagerter Prozessstufen) oder die finalen Nutzer des Produkts oder der Lösung.
2.4.5 Umsetzungsexperte
Der Umsetzungsexperte ist ein Stakeholder, der hinsichtlich der Umsetzung einer oder mehrerer Lösungsbestandteile besonders qualifiziert ist. Es ist zwar nicht möglich, eine vollständige Liste aller Rollen von Umsetzungsexperten zu erstellen, die für alle Vorhaben passt, die gebräuchlichsten sind jedoch: Projektbibliothekar, Change Manager, Konfigurationsmanager, Lösungsarchitekt, Entwickler, Datenbankadministrator, Informationsarchitekt, Usability-Analyst, Trainer und Change-Berater.
2.4.6 Support (Operational Support)
Der Support ist ein Stakeholder, der für das Management und die Wartung von Systemen oder Produkten im Tagesgeschäft zuständig ist.
Es ist zwar nicht möglich, eine vollständige Liste aller Supportrollen für alle Initiativen zu erstellen, aber die gebräuchlichsten sind: Betriebs-Analyst, Produkt-Analyst, Benutzerservice und Release Manager.
2.4.7 Projektmanager
Der Projektmanager ist für die Steuerung eines Projekts formal verantwortlich. Er ist dafür zuständig, dass die Projektziele hinsichtlich Anforderungen, Scope, Qualität und Risiko in der vorgegebenen Zeit und mit den bewilligten Ressourcen erreicht werden.
Gebräuchliche andere Bezeichnungen für diese Rolle sind Projektleiter, technischer Leiter, Produktmanager und Teamleiter.
2.4.8 Regulierer
Der Regulierer ist ein Stakeholder, der für Definition und Durchsetzung von Standards zuständig ist. Standards für eine Lösung können von Aufsichtsbehörden, vom Gesetzgeber, von der Unternehmensführung, von Prüfungsrichtlinien oder von betrieblichen Kompetenzzentren stammen. Mögliche Rollen sind Regierung, Regulierungsbehörden und Wirtschaftsprüfer.
2.4.9 Sponsor/Auftraggeber
Der Sponsor ist ein Stakeholder, der befugt ist, eine Bedarfsermittlung auszulösen und ein Vorhaben auf den Weg zu bringen, das diesen Bedarf erfüllt. Er kann den Scope festlegen und verfügt über die für das Vorhaben notwendigen Mittel.
Er genehmigt die durchzuführenden Arbeiten und steuert das Budget und den Scope für die Aktivität. Mögliche Rollen sind Führungskraft und Projektauftraggeber/Projektsponsor.
2.4.10 Lieferant
Der Lieferant ist ein Stakeholder außerhalb der Grenzen einer Organisation. Er liefert Services oder Produkte und hat moralische oder vertragliche Ansprüche oder Verpflichtungen, die zu beachten sind. Mögliche Rollen sind Anbieter, Verkäufer und Berater.
2.4.11 Tester
Der Tester ist dafür zuständig, dass eine Lösung daraufhin überprüft wird, ob sie die definierten Anforderungen und die erarbeiteten Spezifikationen erfüllt. Der Tester muss sicherstellen, dass die Lösung die geltenden Qualitätsstandards einhält und dass das Risiko von Fehlern oder Störungen erkannt und minimiert wird. Eine alternative Rolle ist der Qualitätssicherer.
2.5 Anforderungen und Designs
Erhebung, Analyse, Bewertung und Verwaltung von Anforderungen sind Schlüsselaktivitäten der Business-Analyse. Der Business-Analyst ist jedoch auch für die Definition des Designs einer Lösung auf einer bestimmten Ebene verantwortlich. Inwieweit der Business-Analyst für das Design zuständig ist, hängt von der Wahrnehmung seiner Rolle im Einzelfall ab.
Anforderungen fokussieren auf den Bedarf, Designs fokussieren auf die Lösung. Die Unterscheidung zwischen Anforderungen und Designs ist nicht immer eindeutig. Für beide können die gleichen Techniken verwendet werden, es wird erhoben, modelliert und analysiert. Eine Anforderung führt zu einem Design, das umgekehrt wieder zur Erhebung und Analyse von weiteren Anforderungen führen kann. Die Verschiebung des Fokus ist oft subtil.
