Antwort

Geschichte der Frage:
Oft formuliert der Auftraggeber zu Beginn eines Projekts die Aufgabe nicht klar genug: Die Ziele können allgemein, und die Details unbeschrieben sein. Dies ist typisch für den Start neuer Richtungen oder die Digitalisierung traditioneller Prozesse. Der Analyst sieht sich widersprüchlichen Wünschen und unterschiedlichen Vorstellungen über das zukünftige Produkt gegenüber.

Problem:
Unklarheiten in den Anforderungen erhöhen das Risiko von Fehlern im Design, Konflikten, Verzögerungen und Budgetüberschreitungen. Engpässe sind Widersprüche zwischen den Stakeholdern und die Unmöglichkeit, den Aufwand abzuschätzen.

Lösung:
Der Analyst sollte eine schrittweise Erfassung der Anforderungen organisieren:

1. Interviews und Moderationssitzungen mit den wichtigsten Stakeholdern durchführen, um nicht nur offensichtliche, sondern auch verborgene Erwartungen zu identifizieren.
2. Prototyping-Techniken und die Erstellung von MVPs verwenden, um schnelles Feedback zu erhalten.
3. Analytische Werkzeuge anwenden: User Stories, Prozessdiagramme sowie Methoden der klärenden Fragen (5 Warum, Klärung „was bedeutet Erfolg“ usw.).
4. Alle Annahmen dokumentieren und mit dem Geschäft abstimmen – dies hilft, das Maß an Ungewissheit zu reduzieren.

Hauptmerkmale:

• Struktureller Ansatz zur Klarstellung unvollständiger Anforderungen
• Nutzung verschiedener Techniken zur Erfassung verborgener Informationen
• Notwendige Dokumentation und die Abstimmung von Annahmen

Fragen mit einem Haken.

Welche Dokumentation ist bei impliziten Anforderungen erforderlich: reicht es aus, nur eine User Story zu erfassen?

Eine User Story ist ein nützliches Werkzeug, deckt jedoch nicht alle Feinheiten ab, wenn die Anforderungen unklar sind. Es müssen zusätzliche Artefakte entwickelt werden: Bildschirmprototypen, Beispiele für Nutzungsszenarien und Tabellen mit Geschäftsregeln.

Was ist zu Beginn wichtiger – schnell ein Ergebnis (MVP) zu erzielen oder möglichst vollständig Anforderungen zu sammeln?

Das Gleichgewicht zwischen Geschwindigkeit und Vollständigkeit hängt von der Situation ab. Zu Beginn ist ein minimal lebensfähiges Produkt (MVP) wertvoller, das Feedback gibt und hilft, die Vision schnell zu korrigieren, als eine lange Abstimmung des gesamten Anforderungsspektrums.

Kann man Entscheidungen treffen, die sich nur auf die Worte des Auftraggebers stützen?

Nein. Der Auftraggeber äußert Wünsche, berücksichtigt dabei möglicherweise nicht die technischen Details und Einschränkungen. Der Analyst muss die Wünsche validieren, indem er die Prozesse versteht, alternative Meinungen einholt und die Konsequenzen analysiert.

Typische Fehler und Anti-Pattern

• Blinder Vertrauen auf die Aussagen des Auftraggebers ohne detaillierte Analyse der Prozesse
• Direkte Übertragung unklarer Anforderungen in Aufgaben für die Entwicklung
• Missachtung des Feedbacks zu Zwischenergebnissen

Beispiel aus dem Leben

Negativer Fall: Der Analyst hat nur die Wünsche des Auftraggebers notiert und sie den Entwicklern übergeben. Ergebnis: Eine Funktionalität wurde implementiert, die nicht die tatsächlichen Geschäftsprobleme löste. Vorteile: Die Entwicklung begann schnell. Nachteile: Das Produkt wurde nicht genutzt, es waren viele Anpassungen erforderlich.

Positiver Fall: Der Analyst führte eine Reihe von Treffen mit Benutzern durch, erstellte einen Prototypen und stimmte die Szenarien ab. Die Anforderungen klärten sich – das MVP brachte schnell Wert für das Geschäft. Vorteile: Schneller Wert, positives Feedback, minimale Nachbesserungen. Nachteile: Etwas mehr Zeit wurde in der Phase der Anforderungserfassung aufgewendet.