Antwort.

Der Lebenszyklus der Business-Analyse ist eine Abfolge von Phasen, die durchlaufen werden, um ein Problem zu lösen, beginnend mit dem Verständnis des Problems und endend mit der Implementierung eines IT-Systems oder von Geschäftsänderungen. Normalerweise umfasst der Zyklus:

1. Identifikation des Problems. Bestimmung der Schlüsselaufgabe und der Ziele der Untersuchung.
2. Anforderungserhebung und -analyse. Kontakt mit den Stakeholdern, Klärung der Bedürfnisse.
3. Dokumentation und Modellierung. Beschreibung der Anforderungen in Form von Spezifikationen, Modellen und Diagrammen.
4. Übermittlung der Anforderungen an das Entwicklungsteam. Formalisierung und Erläuterung der Erwartungen.
5. Überwachung der Implementierung und Erhalt von Feedback. Teilnahme an Tests, Analyse des Erfolges der Änderungen.

Wichtige Merkmale:

• Verständnis der Rolle des Business-Analysten als Vermittler zwischen dem Geschäft und der IT.
• Einsatz verschiedener Modellierungstools (UML, BPMN usw.).
• Iterativer Prozess: Anforderungen werden in jeder Phase verfeinert.

Fangfragen.

Was ist der Unterschied zwischen funktionalen und nicht-funktionalen Anforderungen?

Funktionale Anforderungen beschreiben, WAS das System tun soll (zum Beispiel die Bearbeitung von Bestellungen). Nicht-funktionale Anforderungen beschreiben, WIE das System arbeiten soll (Leistung, Zuverlässigkeit, Sicherheit usw.). Oft werden diese Konzepte verwechselt, wenn nur die Funktionalität entworfen wird.

Können Anforderungen einmalig zu Projektbeginn festgelegt werden?

Nein, die Anforderungen werden während des gesamten Projekts verfeinert. Sie können sich aufgrund neuer Informationen des Unternehmens oder aus den Ergebnissen der Marktanalyse ändern.

Muss ein Business-Analytiker programmieren können?

Nein, auf der Ebene der Aufgaben ist dies nicht erforderlich. Wichtig ist das Verständnis der Geschäftsprozesse und der Grundlagen der Entwicklung, um Aufgaben angemessen zu beschreiben und mit dem Team zu kommunizieren.

Typische Fehler und Anti-Pattern

• Ignorieren von Änderungen der Anforderungen während des Projekts.
• Fehlende klare Dokumentation.
• Unzureichende Kommunikation zwischen den Stakeholdern.

Beispiel aus der Praxis

Negativer Fall: Der Business-Analyst hat die Anforderungen zu Projektbeginn festgehalten und bis zum Ende des Sprints keine Änderungen vorgenommen. Das Ergebnis — Veröffentlichung eines irrelevanten Produkts.

• Vorteil: schnelle Entwicklung ohne Änderungen. − Nachteil: das Ergebnis spiegelt nicht die Bedürfnisse des Unternehmens wider.

Positiver Fall: Der Analyst führte regelmäßige Sprint-Reviews durch und korrigierte die Anforderungen gemäß dem Feedback.

• Vorteil: das Produkt deckt genau die Geschäftsziele ab. − Nachteil: erhöhter Aufwand für Abstimmungen.