Zielmodell: Einsatz im Requirements Engineering & bei der Business-Strategie

Rathes Sachchithananthan — 12.Mrz.2016
in Web

Das Zielmodell ist ein Element aus dem Requirements Engineering, das bei der Ermittlung von Anforderungen und deren Spezifikation eingesetzt werden kann. In diesem Beitrag zeige ich euch, wie man dieses Modell ausweiten und sogar für die Entwicklung der optimalen Business-Strategie einsetzen kann.

Mit der Webentwicklung beschäftige ich mich schon sehr lange. Aber erst seit meinem Studium der Medieninformatik an der Universität Ulm kamen – gezwungenermaßen – theoretische Komponenten der Software-Entwicklung dazu. Es gibt zwei Felder, die mein Interesse für sich gewonnen haben: Usability Engineering, die Analyse und Entwicklung von Bedienbarkeitskonzepten und Requirements Engineering, die Analyse von Software-Projekten und die Entwicklung von Anforderungen. Über das Requirements Engineering habe ich dann auch meine Bachelor-Abschluss-Arbeit geschrieben und dort die zwei Vorgehensmodelle der objektorientierten und zielorientierten Anforderungsanalyse anhand eines praktischen Beispiels verglichen. Für die zielorientierte Vorgehensweise habe ich das Buch „Requirements Engineering – From System Goals to UML Models to Software Specifications“ von Axel van Lamsweerde als Hauptquelle verwendet.

In diesem Buch erläutert der Autor ein Modell, das bei mir selbst heute noch zum Einsatz kommt. Und das obwohl ich kaum noch an der Anforderungsanalyse beteiligt bin. (Auch wenn ich das bei einigen Projekten lieber sollte, aber das ist ne andere Geschichte.). Bei dem Modell handelt es sich um das Zielmodell (im Englischen Goal Diagrams & Goal Modeling).

Zielmodell im Kontext der Software Entwicklung

(Nicht nur) nach Van Lamsweerde muss man, um mit einer Software erfolgreich ein Problem zu lösen, genau wissen welches Problem gelöst werden muss. Mag zwar logisch klingen, aber wenn man mal durch die Software- und Applandschaften für diverse Plattformen geht, dann sieht man immer wieder Anwendungen, wo man sich fragt „Was zur Hölle will man mit dieser App?“ oder „Wie soll diese App mir helfen?“. Zum einen liegt das an mangelnder Usability, die nicht zur Bedarfsgruppe passt, aber meistens einfach daran, dass die Entwickler sich bei der Entwicklung einfach nicht bewusst waren, für welches Problem sie gerade eine Lösung entwickeln. Eine Software muss erst für das Problem entwickelt werden und dann für die Bedarfsgruppe und erst dann kommt alles andere.

[…] what problem should be solved, why such a problem needs to be solved and who should be involved in the responsibility of solving that problem. — van Lamsweerde

Van Lamsweerde sagt also, dass man das Problem kennen muss, um die Lösung zu schaffen. Und er erklärt auch direkt wie man das Problem kennen muss. Man muss wissen, welches Problem gelöst werden soll, warum das Problem überhaupt gelöst werden soll und wer an der Lösung der Problem beteiligt sein soll.

Die drei Dimensionen der Anforderungsanalyse
Die drei Dimensionen der Anforderungsanalyse

Er bezeichnet die drei Fragen als die drei Dimensionen der Anforderungsanalyse: Warum, Was und Wer-Dimension. Die oberste Dimension ist die Warum-Dimension, die Ziele und Wünsche definiert, welche durch die Was-Dimension erfüllt werden sollen. Diese Ziele und Wünsche sollen anhand des bestehenden Systems (ob mit oder ohne Software) und deren Problemen erkannt und ermittelt werden.

Das Zielmodell

Für die Ermittlung der Ziele und Wünsche führt van Lamsweerde in seinem Buch das Zielmodell ein. Ein Ziel ist eine präskriptive (im Sinne von vorschreiben) Aussage über eine Absicht, die das System im Zusammenspiel der Agenten erfüllt werden soll. Agenten sind hierbei die Benutzer des Systems, dazu zählen neben dem Menschen auch Geräte und andere Software, die sich in das System einklinken.

Und das Zielmodell ist ein UND/ODER-Graph dieser Ziele, wobei die Ziele auf höherer Ebene durch die Ziele auf den niedrigeren Ebenen verfeinert werden. Dabei gibt es zwei Arten von Verknüpfungen: Die UND-Verknüpfung und die ODER-Verknüpfung.

Die UND-Verknüpfung stellt ein Set von Sub-Zielen dar, die erfüllt werden müssen, damit das Ziel erfüllt wird. Nehmen wir mal als einfaches Beispiel das Ziel „Kaffee haben“. Um das Ziel zu erreichen, hätten wir die beiden Sub-Ziele „heißes Wasser haben“ und „Kaffeepulver haben“ und vielleicht als dritten Punkt noch „funktionstüchtige Maschine haben“. Diese Punkte sind alle Sub-Ziele, die erreicht werden müssen, damit das Ober-Ziel erreicht werden kann, denn es reicht nicht nur eine funktionsfähige Maschine und das heiße Wasser zu haben, man braucht auch schon Kaffeepulver, um Kaffee zu machen.

Die ODER-Verknüpfung stellt ein Set von Alternativen dar. Das heißt, dass nur eines dieser Sub-Ziele erreicht werden müssen, damit das Ober-Ziel erreicht wird. Erweitern wir unser Beispiel mal um das Ziel „heißes Getränk haben“. Dann wären sowohl „heißen Kaffee haben“ als auch „heißen Tee haben“ Sub-Ziele davon. Beide sind aber Alternativen, die auch funktionieren, wenn das andere nicht erfüllt ist.

Zielmodell: Und/Oder-Verknüpfungen
Zielmodell: Und/Oder-Verknüpfungen (Klicken für vergrößerte Ansicht)

Die Abbildung zeigt wie man Ziele samt ihren Verknüpfungen darstellt. Die Darstellungsweise ist mir aber nicht wichtig, weswegen ich in diese Artikel nicht explizit auf diese eingehen werde, aber ihr seht wie man UND und ODER-Verknüpfungen unterscheidet. Vielmehr geht es mir darum die Methodik der Verfeinerung zu zeigen.

Fallbeispiel: Eine Fitness-App

So simpel und schön das Beispiel mit dem Kaffee auch sein mag, reicht dieses nicht aus, um alle weiterführenden Konzepte auszuführen. Aus diesem Grund führe ich hier ein kleines realitätsnahes Beispiel ein, eine Fitness-App. Es handelt sich hierbei nicht um die App für funktionales Training RAW-Workout, sondern um eine eigens für diesen Artikel ausgedachte App.

Am Anfang haben wir für die App nicht viel. Lediglich die Idee: Eine App, die Menschen zu Sport machen motiviert. Diese Idee wird jetzt mithilfe des Zielmodells so ausgearbeitet, dass wir eine komplette Sammlung an Anforderungen für unsere App haben.

1. Idee zu Ziel

Bevor wir anfangen unsere Ziele zu ermitteln und zu verfeinern, müssen wir aus der Idee ein Ziel definieren. Wir erinnern uns an die Definition von einem Ziel, diese muss präskriptiv sein und eine Absicht haben, die erfüllt werden soll.

Ein Ziel ist eine präskriptive (im Sinne von vorschreiben) Aussage über eine Absicht, die das System im Zusammenspiel der Agenten erfüllt werden soll.

Schauen wir uns unsere Idee an. Wir wollen eine App, die Menschen zum Sport machen motiviert. Die Absicht ist hier schon klar definiert, wir wollen Menschen zum Sport machen motivieren. Drücken wir das noch präskriptiv aus, dann haben wir ein klares Ziel: Erreiche höhere Motivation der Menschen zum Sport machen

Das hört sich zwar komisch an, aber ist ein nach Definition richtiges Ziel.

2. Oberziele ermitteln — Die Frage nach dem Warum

Jetzt haben wir schon mal unser erstes Ziel. Als nächstes müssen wir schauen, ob das bereits unser oberstes Ziel ist. Meist haben wir eine Vision und sind direkt der Meinung, dass unsere Idee am Anfang schon unser oberstes Ziel ist. Dem ist aber nicht immer so. Manchmal gibt es einfach ein Bedürfnis, das erfüllt werden muss, von dem wir nur unbewusst wissen. Also suchen wir im zweiten Schritt nach einem Oberziel zu unserem Ziel.

Dies erreichen wir, indem wir uns Fragen, warum wir dieses Ziel haben: Warum wollen wir mehr Menschen zum Sport motivieren? Auf diese Fragen kann man mehrere Antworten finden. Eine wäre zum Beispiel: Um mehr Menschen fitter zu machen. In dem Fall hätten wir ein neues Oberziel: Erreiche höhere Anzahl an fitten Menschen.

Wir könnten jetzt also weitermachen und für dieses Ziel nach einem weiteren Oberziel suchen, aber wann hören wir auf? Stellen wir uns vor, wir hätten auf die Frage, warum wir mehr Menschen zum Sport motivieren wollen, damit geantwortet, dass die meisten Menschen zu unmotiviert für Sport sind. In diesem Fall hätten wir nicht mit einem neuen Ziel geantwortet, sondern mit einem Problem, das gelöst werden muss. Das wäre das Zeichen dafür, dass man sein oberstes Ziel erreicht hat. Dieses Ziel kann man nun als Startpunkt nehmen und anfangen das Zeil weiter zu verfeinern.

Wir halten also fest: Oberziele finden wir durch die Frage nach dem Warum

3. Ziele verfeinern — Die Frage nach dem Wie

Oberziele haben wir gefunden, indem wir uns gefragt haben, warum wir dieses Ziel erreichen wollen. Mit einer weiteren Frage finden wir die verfeinernden Unterziele eines Ziels, nämlich mit der Frage wie wir dieses Ziel erreichen wollen. Nehmen wir uns unser Ziel „Erreiche höhere Anzahl an fitten Menschen“ vor. Wie wollen wir das erreichen? Ein Ziel haben wir ja bereits, nämlich das Erreichen einer höheren Motivation zum Sport machen. Allein die Motivation reicht aber nicht. Um einen Menschen fit zu bekommen, brauchen wir noch eine gesunde und ausgewogene Ernährungsweise des Menschen sowie ein für den Menschen angepasstes Training. Wir haben also für unser oberstes Ziel drei Sub-Ziele gefunden, die erreicht werden müssen. Und bei diesen Sub-Zielen stellen wir wieder die „Wie?“-Frage und finden wieder Sub-Ziele.

Zielmodell: Anforderungen verfeinern mit Wie und Warum-Fragen
Zielmodell: Anforderungen verfeinern mit Wie und Warum-Fragen

Das können wir jetzt lange fortführen bis wir das unterste feinste Ziel gefunden haben. Aber wann ist das der Fall? Das unterste Ziel, das Blatt-Element in dieser Baumstruktur, haben wir dann gefunden, wenn wir dieses Ziel genau einem einzigen Agenten zuordnen können. Ein Agent kann wie oben bereits beschrieben der Mensch selbst sein, ein technisches Gerät, eine bestehende Software oder eine Software selbst. Das heißt wir verfeinern solange bis wir entweder das Ziel als eine Anforderung an einen Software-Agenten zuweisen können oder als Erwartung an ein Gerät bzw. dem Benutzer verbuchen können.

Verfeinern wir in unserem Beispiel den Ast „angepasstes Training“ erhalten wir definitiv ein Sub-Ziel „Ziele des Menschen bekannt„, welches wir wieder aufteilen können in „Ziele an System übermittelt“ und „Ziele im System gesichert„. Die letzteren beiden Ziele können wir dem Benutzer und der Software zuordnen, das heißt für den Ast hätten wir unsere Blattziele gefunden.

4. Alternativen — Die Frage nach dem Wie noch

Es führen aber viele Wege nach Rom und wir sollten uns nicht damit zufrieden geben, dass wir einen dieser Wege gefunden haben. Wir sollten also auch Alternativen zu den Sub-Zielen finden, die wir bereits gefunden haben. Dazu stellen wir uns die Frage: Wie können wir das noch Ziel erreichen? Und die Sets an Sub-Zielen, die wir hierbei finden, werden unsere Alternativen. Am besten geht man bei der Suche nach Alternativen von der untersten Ebene nach oben, da die Alternativen besser gefunden werden können, wenn das Ziel detaillierter ist. Findet man eine dieser Alternativen, muss man natürlich auch diese solange wieder verfeinern, bis man alle Blattziele dieses alternativen Strangs gefunden hat. Dieser Strang muss nicht die gleiche Größe haben als der andere, sondern kann sich komplett von den anderen unterscheiden.

5. Umgebungsvariablen und Erwartungen

Es gibt keine Software, die nicht von ihrer Umgebung beeinflusst werden kann oder ohne irgendwelche Annahmen, die im Vorfeld gemacht wurden, funktioniert. Aber oft werden diese erst dann gefunden, wenn man die Software schon fertig hat und dann sind diese Faktoren nur im Weg, um die eigentlichen Ziele zu erreichen. Daher ist es wichtig die Umgebungsvariablen und Erwartungen, die an die Ziele geknüpft sind, vorzeitig zu ermitteln. Diese werden ermittelt, indem man den bestehenden Baum komplett durchgeht und sich Gedanken dazu macht, welche Voraussetzungen man erwartet. Aus persönlicher Erfahrung finde ich es am einfachsten im Team einfach den Baum durchzugehen und zu diskutieren. Dabei findet man nicht nur die Erwartungen und Voraussetzungen, meist finden sich in solchen Diskussionen auch direkt Alternativen, wo manch Umgebungsvariablen keinen Einfluss mehr haben können.

Vorteile vom Zielmodell

Wir haben jetzt ein Zielmodell erarbeitet, das die funktionalen und nicht-funktionalen Ziele unserer Anwendung abbildet und diese Ziele sogar in Verbindung zueinander setzt. Wie bei der üblichen objektorientierten Anforderungsanalyse arbeitet man auch beim Zielmodell mit der Absicht ein vollständiges Set an Anforderungen zu finden. Während die objektorientierte Methode zunächst Geschäftsanwendungsfälle und Abläufe analysiert und durch die strukturierte Verfeinerung an ein Analysemodell und an die Anforderungen gelangt, beginnt die zielorientierte Lösung mit den Zielen der beteiligten Personen. Somit werden die nicht-funktionalen Anforderungen, die ein System mit sich führt nicht nur als Anhängsel neben den Funktionen behandelt.

Stattdessen werden die Bedürfnisse der Benutzer mehr in den Vordergrund gerückt. Gerade diese Bedürfnisse sind in den Anwendungen die Faktoren, ob der Benutzer eine Anwendung als nützlich empfindet oder nicht. Und da man mit dem Zielmodell diese Bedürfnisse gezielt verfeinert, kommt man zu Funktionalitäten des Systems, die perfekt auf die Wünsche der Benutzer zugeschnitten sind.

Außerdem kann man mit festen Regeln die Verfeinerung so kontrollieren, dass die Anforderungen größtenteils komplett sind. Van Lamsweerde beschreibt im bereits genannten Buch — neben den oben beschrieben Wegen Ziele zu verfeinern — verschiedene weitere Heuristiken, mit denen man ermitteln kann, ob ein Ziel vollständig verfeinert hat oder nicht. (Diese werde ich in diesem Artikel nicht näher beschreiben, da das den ohnehin großen Artikel noch weiter sprengen würde.)

Der größte Vorteil vom Zielmodell ist definitiv jener, dass man ein Zielmodell nicht nur für die Analyse der Anforderungen einer Software benutzen kann, sondern sogar das komplette Umfeld der Software mithilfe des Modells analysiert werden kann.

Einsatz vom Zielmodell in weiteren Bereichen

Wenn die Software nicht gerade für den Open-Source-Markt entwickelt wird, sondern einem Geschäft dienen soll, dann ist es nicht damit getan, dass man diese Software nur entwickelt. Diese entwickelte Software muss auch anständig an den Mann gebracht werden, denn nur so kann man Vorteile daraus ziehen. Dies erfordert eine gute Marketing-Strategie und übergeordnet eine anständige Business-Strategie. Und beide müssen sauber zum Produkt passen.

Facebook stands for helping to connect people and giving them voice to shape their own future. […] — Mark Zuckerberg

Hast du schon mal mitgezählt wie oft Mark Zuckerberg die Phrase „to connect the world“ benutzt? Oder Satya Nadella davon redet „to make people to achieve more“? Ich zähle nicht mehr mit, weil die das gefühlt in jedem Satz unterbringen. Warum machen die das? Um zu zeigen, dass alles, was sie machen einer großen Vision folgt und dass diese Vision der Grund für alle Entscheidungen ist, die man trifft, und für Produkte, die man entwickelt.

Zielmodell für die Geschäftsanalyse

Eine solche Vision brauchst du auch, wenn du erfolgreich sein willst. Denn nur so verkaufst du den Leuten das Gefühl, dass du etwas ganz Großes erschaffen wirst und ziehst eine große Aufmerksamkeit auf dich. Aber nicht nur der Aufmerksamkeit dient diese Vision. Auch für die eigene Entwicklung ist eine Vision immens wichtig, denn sie zeigt dir in welche Richtung du dich entwickeln solltest. Sie hilft dir dabei Grenzen zu setzen und neue Grenzen zu erforschen. Eine Vision sorgt dafür, dass du mit deinen Ideen nicht zu weit auseinanderdriftest, sondern immer schon vernetzt zusammenbehältst. Nur so schafft ein Unternehmen wie Facebook ihre Produktpalette konstant weiterzuentwickeln. Und auch so versucht jetzt Microsoft ihre Palette endlich wieder vernünftig zusammenzubringen.

Bestes Beispiel, wie weit man es mit einer guten Vision bringen kann, ist die Vision von Steve Jobs und wie er Apple mit seiner Vision vorangetrieben hat. Apple ist auch gleichzeitig das beste Beispiel wie sich die komplette Strategie verändern kann, wenn die Vision sich ändert.

Du solltest – egal ob du nur ein Freelancer bist oder ein Unternehmer – immer eine Vision haben wie deine Zukunft aussehen wird. Diese Vision sollte aber keine bunt ausgemalte Landschaft sein wie die Welt aussehen könnte, sondern ein nüchternes präskriptives Ziel.

Richtig, genau das präskriptive Ziel, das wir in der Anforderungsanalyse im Zielmodell haben. Und wenn du schon ein Zielmodell hast, das dein Produkt beschreibt, dann kannst du auch direkt anhand dieses deine Vision analysieren.

Wir erinnern uns: Je weiter wir im Zielmodell nach unten gehen, desto weiter werden unsere Ziele verfeinert, je weiter wir nach oben gehen desto mehr Oberziele bekommen wir.

Jetzt machen wir uns mal Gedanken darüber in welcher Relation ein Softwareprodukt zur Vision steht. Wir stellen fest, dass ein Produkt nur ein Teil der Antwort der Frage ist, wie wir unsere Vision erreichen. Im Zielmodell gedacht ist das bisherige Zielmodell für die Software nur ein Ast des Oberziels, das unsere Vision beschreibt.

Also können wir auch unsere Vision ermitteln wie wir auch andere Oberziele ermittelt haben. Wir fangen bei unserem aktuellen Ober-Ziel an und fragen noch einmal nach dem „Warum“ und stoßen auf unsere Vision.

Bei unserem Fitness-Beispiel könnte die Antwort lauten: „Gesunde Welt“ oder aber auch „Aktives Deutschland“. Während erstere Antwort auf eine medizinische Vision abzielt, spricht letztere eher eine Art großer Community an.

Zielmodell für die Produktentwicklung & im Marketing

Bei der weiteren Entwicklung des ganzen Unternehmens haben wir nun eine Vision, anhand welcher wir jetzt sämtliche Produktideen einordnen können. Jedes Mal stellen wir uns also die Frage: „Erreiche ich mit dieser Idee das Ziel ein aktives Deutschland zu schaffen?“ und haben nun einen schnellen Überblick, ob man sich die Idee näher ansehen sollte oder direkt verwerfen kann. Wer jetzt noch Ideen aus anderen Konzepten wie beispielsweise dem Lean-Konzept mit aufnimmt, wird sogar nachweisen, ob seine Idee helfen kann oder nicht. (Das werde ich zu geeigneter Zeit in einem gesonderten Beitrag erläutern.)

Und auch für die Marketingstrategien des Unternehmens und für die einzelnen Produkte und Teilprodukte kann man das Zielmodell verwenden. Greifen wir erneut auf das Beispiel von oben zurück. Wir haben als Hauptziel ermittelt, dass wir eine hohe Anzahl an fitten Menschen erreichen wollen, stellen uns dann die Frage wie wir das erreichen wollen: Höhere Motivation bei den Menschen und angepasstes Training für diese. Und ein wichtiges Sub-Ziel ist natürlich auch, dass wir eine hohe Anzahl von Menschen zu trainieren bewegen. Und wie erreichen wir das? Ganz genau: Erreiche viele Menschen mit unserem Produkt und erreiche, dass viele Menschen bei unserem Produkt lange bleiben. Und schon haben wir die ersten Ziele definiert, die den Marketing-Bereich ansprechen. Diese Ziele können wir jetzt verfeinern und mit ganz viele Ideen (Alternativen) versehen. Diese Ziele haben dann natürlich auch Bedingungen und Annahmen und können mithilfe vom Zielmodell gut analysiert werden.

Zusammenfassung und Vorschau

Wie wir sehen, gibt das Zielmodell, das Axel van Lamsweerde in seinem Buch „Requirements Engineering – From System Goals to UML Models to Software Specifications“ als Instrument für die Ermittlung von Anforderungen vorgestellt hat, mehr her als nur diese Anforderungen. Man kann das Zielmodell auch dazu benutzen, um die Ziele des Unternehmens zu ermitteln und die Weiterentwicklung des Unternehmens kontrollieren. Man kann neue Strategien entwickeln und auch neue Produktideen finden.

Eine weitere größere Möglichkeit, die wir von van Lamsweerde lernen können, ist die Risikoanalyse. Van Lamsweerde beschreibt in seinem Buch die Möglichkeiten der Risikoanalyse bei Software-Systemen anhand des entwickelten Zielmodells. Mit einer gewissen Adaption kann diese Risikoanalyse auch bei der eigenen Business-Strategie eingesetzt werden. Diese Idee werde ich bald in einem weiteren Beitrag näher behandeln.

Wenn man das ganze Modell auf die Spitze treiben will, dann kann man noch weiter nach dem Warum fragen und sogar seine persönlichen Ziele und Wünsche analysieren. Aber ich denke man muss mit der Modellierung nicht ganz so übertreiben und das auch ins Privatleben führen.

Rathes Sachchithananthan

Rathes Sachchithananthan

Hi, ich bin Rathes. Gründer dieses Blogs. Darüber hinaus habe ich Aheenam gegründet, eine Agentur für digitale Lösungen. Dort konzipiere und entwickle ich die digitale Weiterentwicklung meiner Kunden. Ich brenne für das Thema "Tamilen und Tamil Eelam" und bin ein Microsoft-Fanboy. Du findest mich auch auf diversen sozialen Netzwerken

Web und die Welt — Gott kann auch mal drin vorkommen

Ein Blog über das Web und die Welt. Wir schreiben über viele interessante Themen wie z.B. das Web, Tamil Eelam oder über Fotografie. Vielleicht ist auch was für dich dabei?