Antwort

Ein Business Analyst sollte Abnahmekriterien (acceptance criteria) für jede Anforderung formalisiert, sodass sie für alle Projektbeteiligten: Auftraggeber, Entwickler und Tester klar und eindeutig sind. Hierfür werden Spezifikationstechniken wie die Formulierung von Kriterien in Gherkin-Notation (Given-When-Then), Checklisten und Anwendungsbeispiele (use cases) verwendet. Der Analyst dokumentiert die Kriterien in den Anforderungsartefakten und sorgt dafür, dass jede Anforderung über einen Satz objektiver Bedingungen verfügt, um die Erfüllung der Aufgabe eindeutig zu bestätigen.

Wesentliche Merkmale:

• Klare, messbare Formulierung der Kriterien unter Verwendung von geschäftlichen und technischen Begriffen.
• Beteiligung des Auftraggebers an der Bestätigung der Kriterien vor Beginn der Entwicklung.
• Aufnahme der Kriterien in User Stories, Spezifikationen und Testfälle.

Fangfragen.

Kann man ausschließlich User Stories zur Beschreibung von Anforderungen verwenden, ohne zusätzliche Abnahmekriterien?

Nein, User Stories ohne klare Abnahmekriterien sind zu abstrakt und können unterschiedlich interpretiert werden. Kriterien sind notwendig, um sicherzustellen, dass die Anforderung korrekt umgesetzt wird.

Müssen nicht-funktionale Anforderungen (z.B. Leistung) in die Abnahmekriterien einbezogen werden?

Ja, auch nicht-funktionale Anforderungen sollten in die Kriterien formalisiert werden, andernfalls besteht das Risiko, sie unbeabsichtigt zu vergessen oder nicht vollständig umzusetzen.

Wer sollte die Abnahmekriterien genehmigen: nur der Business Analyst?

Nein, es ist immer notwendig, die Kriterien mit dem Auftraggeber und, wenn möglich, dem Entwicklungsteam abzustimmen, um Missverständnisse zu minimieren.

Typische Fehler und Anti-Patterns

• Ignorieren der Abstimmung der Kriterien mit dem Auftraggeber.
• Überlassen der Kriterien dem Ermessen des Entwicklungsteams.
• Verspätete Aufnahme der Kriterien nach Projektstart.

Beispiel aus dem Leben

Negativer Fall: Der Business Analyst hat die Abnahmekriterien nicht mit dem Auftraggeber abgestimmt, und die Entwickler haben die Anforderungen auf ihre Weise verstanden. Vorteile: Schnelle Entwicklung, keine Abstimmungen haben den Prozess aufgehalten. Nachteile: Nach dem Release entsprach 70% der Funktionalität nicht den tatsächlichen Erwartungen, es entstand ein Konflikt.

Positiver Fall: Der Analyst hat die formalen Abnahmekriterien aufgeschrieben, diese mit beiden Seiten abgestimmt und zu den User Stories hinzugefügt. Vorteile: Verständnis zwischen Auftraggeber und Team, minimale Bugs nach dem Release. Nachteile: Zu Beginn etwas mehr Zeit für die Abstimmungen benötigt.