Vielleicht kennen Sie diese Situation. Ihre Partnerin/Ihr Partner bittet Sie auf dem Heimweg noch kurz einzukaufen. Sie sollen Milch, Brot, Wurst und Käse mitbringen. Sie kommen diesem Wunsch nach, packen zu Hause den Einkauf aus und bekommen zu hören: „Diese Milch habe ich nicht gemeint!“ oder „Ich wollte andere Milch!“
Was ist passiert? Sie sollten Milch einkaufen und haben Milch mitgebracht. Aber offensichtlich nicht die richtige Milch, weil Ihnen wichtige Angaben fehlten: Fettgehalt, Frischmilch/länger haltbare Milch/H-Milch, mit/ohne Laktose, Bio/Öko/beides/egal, Liter/500 ml, Marke/Hersteller, Supermarkt/Tante-Emma-Laden/Discounter, Preis, Haltbarkeitsdatum. Selbst bei Milch gibt es also diverse Anforderungen, die zu beachten sind.
Leider haben wir (in der Rolle eines Business Analysten bzw. Requirements Engineers) die Anforderungen des Stakeholders nicht genau genug ermittelt. Der Stakeholder (Partnerin/ Partner) hatte eine Vorstellung, welche Milch zu kaufen ist. Wir hatten eine andere Vorstellung. Beim Vergleich der Lösung (gekaufte Milch) mit den Anforderungen wurde deutlich, dass die Vorstellungen unterschiedlich sind.
Selbst wenn wir einige der Anforderungen (z.B. Fettgehalt, Preis) richtig umgesetzt hätten, hätten wir immer noch die falsche Milch (z.B. Marke) kaufen können.
Bei diesem Beispiel sollten auch Geschäftsregeln beachtet werden: „Kaufe die Marke mit den Bären, es sei denn die Marke mit den Kühen ist im Angebot.“ „Kaufe im Supermarkt ein, der unsere Rabattkarte Zahlzurück annimmt.“ „Wenn die Marke mit den Kühen im Angebot ist, kaufe trotzdem die Marke mit den Bären, wenn diese günstiger ist.“
Selbst wenn wir annehmen, unsere Stakeholder und die Anforderungen zu kennen, kann der Kauf daneben gehen: „Wir haben seit drei Monaten die Marke mit den Bären getrunken; ich bin den Geschmack leid und will die andere Marke probieren; das habe ich letzte Woche beim Frühstück angedeutet.“
Als Business Analyst bzw. Requirements Engineer ist es also wichtig, möglichst vollständig zu verstehen, was unsere Stakeholder benötigen. Wenn wir unsicher sind und Annahmen treffen, besteht die Gefahr, dass die Lösung nicht alle Anforderungen der Stakeholder erfüllt. Beim Milchkauf sind die eingesetzte Zeit und das ausgegebene Geld meistens zu verschmerzen. Für andere Anforderungen und daraus entwickelte Lösungen mag dies nicht gelten.
P.S. Häufig werden Business Analyse und Requirements Engineering mit Projekten in Verbindung gebracht (Projektcharakter hat für mich z.B. Kauf von Weihnachtsgeschenken). Der Supermarkteinkauf gehört eher zur Linie/Tagesgeschäft, oder? Auch hier spielen -wie beschrieben- die Ermittlung und Analyse von Anforderungen eine Rolle.
P.P.S Sicherlich kann man den Einkauf auch als Prozess modellieren; wie das für Ente à l’Orange möglich ist, verdeutlicht Jakob Freund 😉
… und wenn dann alle Erwartungen und Zwischentöne in vollem Umfang berücksichtigt sind, bin ich enttäuscht, dass das Ergebnis ja überhaupt keine Überraschung enthält … 😉