Vom Ziel zur Anforderung

Anforderungen sind nur Mittel zum Zweck. Letzten Endes geht es darum, das gesetzte Ziel zu erreichen. Daher ist es nicht sonderlich verwunderlich, dass es dafür eine eigene Disziplin gibt, nämlich Goal-Oriented Requirements Engineering (GORE).

Zielorientiertes Anforderungsmanagement kann man leicht am Whiteboard mit Zetteln praktizieren, und das ist auch der Ansatz, den ich generell empfehle. Man kann aber auch beliebig formal werden. Bekannte Modellierungssprachen in dieser Kategorie sind i* und KAOS. Allerdings lässt sich auch mit UML zielorientierte Modellierung betreiben, auch wenn es dafür keine expliziten Modellelemente gibt.

Die Frage nach dem Warum

Zielorientierte Ansätze fragen gezielt nach dem „Warum“, warum das System etwas können muss. Und da hinter jeder Intention letzten Endes ein Aktor steckt, stellen diese Ansätze auch die Frage „Wer“. In den Hintegrund rückt die Frage, was gemacht werden muss, um die Ziele zu erreichen.

Um das konkret zu zeigen, schauen wir uns ein klassisches Beispiel an, einen Fahrstuhl. Das wichtigste Element hierbei ist das Ziel, wobei es da neben einem „normalen“ Ziel auch noch sogenannte Soft Goals, also „weiche Ziele“ gibt. Das sind Ziele, die sich schwer messen lassen können, wie „Fahrvergnügen“. Weiterhin gibt es Hürden (Obstacles), die überwunden werden müssen, also eine Art „Anti-Ziel“. Bei der Analyse können dann Aspekte identifiziert werden, die das Soft Goal entweder unterstützen oder hemmen.

Ziele werden über Anforderungen, Erwartungen und Randbedingungen (Domain Properties) konkretisiert. Hier kommen dann auch die Nutzer ins Spiel: Denn für diese Elemente muss es Verantwortliche geben. So kann es nun passieren, dass es indirekt mehrere Verantwortliche für ein Ziel gibt, die möglicherweise gegensätzliche Interessen haben. Der Nutzer hat vielleicht Interesse an einer hohen Geschwindigkeit, was sich möglicherweise negativ auf die Sicherheit auswirkt.

Die Beziehungen zwischen den Elementen ermöglichen das Identifizieren von Konflikten, die dann aufgelöst werden können. Aber auch ohne direkte Konflikte können hypothetische Hindernisse analysiert werden, was im Bild oben gezeigt ist: Die Fahrstuhlanzeige ist möglicherweise nicht lesbar, weil die Anzeige zu klein oder der Passagier blind ist. In der Analyse identifizierte Hürden können dann wieder aufgelöst werden.

Lohnt es sich?

Der Langsamste, der sein Ziel nicht aus den Augen verliert, geht noch immer geschwinder, als jener, der ohne Ziel umherirrt. (Gotthold Ephraim Lessing)

Ob sich eine zielorientierte Analyse lohnt, und in welcher Tiefe, hängt von der Problemstellung ab. Für mich hat sich diese Analyse für Teilprobleme bewährt. Die Befürworter von KAOS, hingegen suggerieren, dass eine vollständige Entwicklung nach diesem Ansatz möglich ist. Und das KAOS-Modell enthält dementsprechend nicht nur Elemente für die Ziel-Modellierung, sondern auch für statische und dynamische Aspekte. Für KAOS gibt es das Modellierungswerzeug Objectiver, welches für drei Monate evaluiert werden kann (allerdings scheint seit 2013 dort nichts passiert zu sein).

Zielmodellierung im Webbrowser

Wer Lust hat, im Webbrowser nach der i*-Methode zu modellieren, der kann das Werkzeug Creative Leaf ausprobieren. Es scheint zwar noch ein paar raue Ecken zu haben, gibt aber einen schnellen Eindruck von i*.

Mal ausprobieren? Wenn Sie mehr über zielorientierte Modellierung lernen möchten, dann buchen Sie bei mir einen Workshop zu dem Thema.