i*

i* bzw. iStar [aɪ stɑr] (Intentional STrategic Actor Relationships) ist eine grafische Notation zur Modellierung von Zielen. Der erste Entwurf dieser Notation wurde Mitte der Neunziger in der Dissertation des kanadischen Wissenschaftlers Eric Siu-Kwong Yu veröffentlicht. Ein Alleinstellungsmerkmal von i* ist der Fokus auf soziale Akteure und deren Abhängigkeiten, Wechselwirkungen und Aktivitäten zur Erfüllung von Zielen. Die Notation verbindet die Intention („Warum?“) mit den sozialen Akteuren („Wer?“) und der Strategie („Wie?“), mit der die Ziele erreicht werden können.

Alle Sprachelemente von i* 1.0

Der Sprachumfang von i* ist relativ komplex und lässt sich in zwei Diagrammtypen (SD und SR) aufteilen. Die beiden Aspekte können jedoch auch in einem gemeinsamen Diagramm betrachtet werden (siehe Beispieldiagramm). In der zweiten Version von i* und in diversen abgeleiteten Sprachen, wird der Sprachumfang bewusst reduziert.

Die Internationalen Fernmeldeunion (ITU) empfiehlt die Nutzung der Goal-oriented Requirements Language (GRL) zur Beschreibung von nichtfunktionalen Anforderungen. GRL basiert hauptsächlich auf i* und bildet zusammen mit Use Case Maps (UCM) die User Requirements Notation (URN).

Diagrammtypen

Strategic Dependency (SD) Diagramm

Das SD-Diagramm beschreibt die Dependenzen zwischen Stakeholdern. Ein solches Modell besteht aus Knoten und gerichteten Verbindungen, welche die Knoten miteinander verbinden. Die Knoten stellen Akteure dar. Assoziationsbeziehungen beschreiben das Verhältnis von zwei Akteuren zueinander. Abhängigkeitsbeziehungen stellen eine Abhängigkeit eines Akteurs von einem anderen Akteuren dar. Der abhängige Akteur wird Depender genannt, und der Akteur, von dem er abhängig ist, wird als Dependee bezeichnet. Das zentrale Element, um das sich die Abhängigkeit dreht, wird als Dependum bezeichnet.

Akteure

Es gibt mehrere Arten von Akteuren (Actors), die miteinander in Verbindung stehen können. Akteure jeder Art sollten grundsätzlich nicht ineinander verschachtelt werden. Stattdessen sollte jeder Akteur separat beschrieben werden und übergeordnete oder verwandte Akteure mit einer Is Part Of- oder ISA-Beziehung verbunden werden.

Typ	Beschreibung
Actor	Bei Akteuren handelt es sich um Entitäten, die durch ihre Aktionen dazu beitragen, Ziele zu erreichen. Agenten, Rollen und Positionen sind spezialisierte Untereinheiten von komplexen sozialen Akteuren.
Agent	Agenten sind Akteure, denen eine konkrete Manifestation zugrunde liegt. Es handelt sich dabei aber nicht ausschließlich um menschliche Individuen, sondern unter anderem auch um Institutionen oder z. B. auf dem Gebiet der Informatik auch um Hardware- oder Software-Komponenten. Agenten können Abhängigkeiten besitzen, die unabhängig davon gelten, welche Rolle diese gerade ausüben. Dabei handelt es sich beispielsweise um Fähigkeiten, Erfahrungen oder physische Einschränkungen, die in der Regel nicht ohne weiteres auf andere Agenten übertragen werden können.
Position	Positionen bilden eine zusätzliche Abstraktionsebene zwischen einem Agenten und einer Rolle. Die Agenten müssen dabei nicht zwingend menschlicher Natur sein.
Role	Dieses Element repräsentiert eine soziale Rolle. Es handelt sich also um eine abstrakte Charakterisierung des Verhaltens eines sozialen Akteurs in einem speziellen Kontext oder auf einem Fachgebiet. Die mit der Rolle verbundenen Aufgaben und Eigenschaften lassen sich einfach auf einen anderen sozialen Akteur übertragen. Die Ausübung einer Rolle durch einen Akteur lässt sich mit Hilfe der Plays Verknüpfung darstellen.

Assoziationsbeziehungen

Assoziationsbeziehungen (Association-Links) beschreiben das Verhältnis zwischen jeweils zwei Akteuren. Sie werden als gewöhnlicher Pfeil dargestellt, wobei der jeweilige Typ an den Rand des Pfeils geschrieben wird.

Typ	Beschreibung
ISA	Die ISA-Verknüpfung repräsentiert eine Verallgemeinerung zwischen zwei Akteuren des gleichen Typs.
Covers	Die Covers-Beziehung beschreibt den Zusammenhang einer Position und den Rollen, die durch diese abgedeckt werden. Eine Position ist ein Zusammenschluss von Rollen. Diese Art von Verbindung ist nur zwischen Positionen und Rollen zulässig, wobei der Pfeil an einer Position beginnt und die Pfeilspitze auf eine Rolle zeigt.
Is Part Of	Alle Arten von Akteuren können mit Hilfe der Is Part Of-Beziehung in kleinere Einheiten aufgeteilt werden.
Occupies	Die Occupies-Verknüpfung beschreibt den Sachverhalt, dass ein Agent alle Rollen spielt, die durch eine Position mittels der Covers-Verknüpfung abgedeckt sind. Der Pfeil beginnt an einem Agenten und zeigt auf eine Position.
Plays	Mit der Plays-Beziehung kann der Zusammenhang zwischen einem Agenten und einer Rolle beschrieben werden. Die Aufgaben von Agenten und Rollen sollten so aufgeteilt werden, dass der Agent jederzeit durch einen anderen Agenten ersetzt werden kann. Bei einem Entzug der Rolle sollte keine Änderung am betroffenen Agenten nötig sein. Die Verknüpfung geht von einem Agenten aus und zeigt mit der Pfeilspitze auf eine Rolle.
INS	Die INS-Beziehung repräsentiert einen Agenten, der eine Instanz eines verallgemeinerten Agenten darstellt. Diese Verknüpfung ist nur zwischen Agenten zulässig.

Abhängigkeitsbeziehungen

Abhängigkeitsbeziehungen (Dependency-Links) beschreiben die Abhängigkeit eines Akteurs (Depender) von einem anderen Akteur (Dependee). Es gibt insgesamt vier Arten von Abhängigkeitsbeziehungen, nämlich Hardgoal-Dependency-Links, Softgoal-Dependency-Links, Task-Dependency-Links und Resource-Dependency-Links. Diese Beziehungen verknüpfen die Aspekte von SD-Diagrammen mit den Aspekten von SR-Diagrammen. Abhängigkeiten sind stets gerichtet. Zur Modellierung von Interdependenzen ist es notwendig, einen zweiten Pfeil mit umgekehrter Richtung zu zeichnen, wobei sich die Rollen Depender und Dependee der beiden Akteure umkehren.

Strategic Rationale (SR) Diagramm

Das SR-Diagramm beschreibt, welche Ziele ein Akteur verfolgt und mit welchen Mitteln er diese erreichen kann. Diese Art von Diagramm wird meistens innerhalb eines gestrichelten Rahmens gezeichnet (Actor Boundary), wobei das runde Symbol des Akteurs in den Rand integriert ist. Je nach Modellierungswerkzeug lässt sich dieser Bereich bei Bedarf ein- und ausblenden. Die Elemente und Verbindungen in einem SR-Diagramm beziehen sich ausschließlich auf einen Akteur und dürfen dessen Grenzen nicht verlassen. Eine Verbindung zu anderen Akteuren ist nur über Abhängigkeitsbeziehungen (Dependency-Links) zulässig.

Elemente

Typ	Beschreibung
Hardgoal	Ein Hardgoal repräsentiert ein klar definiertes, messbares und realistisch erreichbares Ziel (S.M.A.R.T.). Der Weg, wie das Ziel erreicht werden kann, wird via Aufgabenzerlegung beschrieben. Im Kontext der Softwareentwicklung handelt es sich hierbei meistens um eine funktionale Anforderung.
Softgoal	Im Gegensatz zu Hardgoals sind Softgoals nur vage beschriebene Ziele, bei denen die Kriterien zum Erreichen des Ziels nicht klar definiert und messbar. Die Einflussfaktoren zum Fördern oder Erreichen dieser Ziele werden mit Hilfe von Beitragsbeziehungen modelliert. Die Zerlegung in Teilziele erfolgt über And- und Or-Beziehungen. Im Kontext der Softwareentwicklung handelt es sich hierbei meistens um eine nichtfunktionale Anforderung.
Task	Hierbei handelt es sich um Aufgaben, die der Akteur ausüben muss, um Ziele zu verwirklichen. Aufgaben können in mehrere Teilelemente zerlegt werden. Dabei kann es sich um Ziele, Aufgaben und Ressourcen handeln.
Resource	Bei Ressourcen handelt es sich um physische oder informative Artefakte, die benötigt werden, um eine Aufgabe durchzuführen. Beispiele dafür sind Rohstoffe, Werkzeuge oder Geldmittel.
Belief	Diese Elemente repräsentieren eine Aussage über die Welt, die der Akteur für wahr bzw. gegeben hält. Anders als bei einem Ziel hat ein Akteur keinen expliziten Wunsch bzw. überhaupt die Möglichkeit, die angegebene Bedingung wahr werden zu lassen.

Aufgabenzerlegung

Aufgaben können (via Task-Decomposition-Links) in mehrere Teilaufgaben, Teilziele, und die benötigten Ressourcen zerlegt werden. Die Bestandteile einer Aufgabe werden mit der übergeordneten Aufgabe über eine kreuzförmige Linie (†) verbunden. Der kurze Abschnitt des Längsbalkens befindet sich dabei nahe der übergeordneten Aufgabe. Diese Art von Verbindung gilt nur für Aufgaben. Die Aufteilung von Zielen in Teilziele geschieht mittels And- und Or-Beziehung.

Means-Ends-Beziehungen

Means-Ends-Beziehungen beschreiben, mit welchen Mitteln (Means) ein Zweck (Ends) erfüllt werden kann. Sie sind nur zwischen Aufgaben und Hardgoals zulässig und werden als hohler Pfeil von der Aufgabe zum Ziel gezeichnet.

Beitragsbeziehungen

Beitragsbeziehungen (Contribution-Links) beschreiben, welchen Beitrag ein Element zum Erreichen eines Softgoals leisten. Diese Verbindungen werden als simple Pfeile dargestellt, bei denen der jeweilige Typ an den Rand des Pfeils geschrieben wird.

Typ	Beschreibung
Make	Ein positiver Beitrag, der für sich genommen stark genug ist, ein Ziel zu erreichen.
Some+	Ein positiver Beitrag, der dabei hilft, ein Ziel zu erreichen, aber dessen Gewichtung (Help oder Make) unbekannt oder schwer einzuschätzen ist.
Help	Ein positiver Beitrag, der für sich genommen nicht stark genug ist, ein Ziel zu erreichen.
Unknown	Ein Einflussfaktor, dessen Wirkung schlecht einzuschätzen ist. Es kann sich um einen positiven, negativen oder neutralen Beitrag handeln. Verbessert sich im Laufe der Zeit die Datenlage, können diese Beziehungen entsprechend ersetzt oder entfernt werden.
Hurt	Ein negativer Beitrag, der für sich genommen nicht stark genug ist, ein Ziel zu verwerfen.
Some-	Ein negativer Beitrag, dessen Gewichtung (Hurt oder Break) unbekannt oder schwer einzuschätzen ist. Möglicherweise genügt ein solcher Einflussfaktor, um ein Ziel zu verwerfen.
Break	Ein negativer Beitrag, der für sich genommen stark genug ist, ein Ziel zu verwerfen.
And	Ein übergeordnetes Ziel ist dann erreicht, wenn alle untergeordneten Zielen erreicht wurden. Es handelt sich also um eine logische Konjunktion.
Or	Ein übergeordnetes Ziel ist dann erreicht, wenn mindestens eines der untergeordneten erreicht wurde. Man spricht hier von einer logischen Disjunktion. Bei manchen abgeleiteten Dialekten wird explizit zwischen Disjunktion (IOR) und Kontravalenz (XOR) unterschieden.

Beispieldiagramm

Das folgende i*-Diagramm zeigt einen kleinen Ausschnitt aus den komplexen Beziehungen zwischen einem Stromversorger und dessen Kunden. Es werden fossile und erneuerbare Energiequellen und deren Auswirkungen auf die Versorgungssicherheit und Preisstabilität beschrieben. Das Beispiel bezieht sich dabei primär auf den deutschen Energiemarkt und dessen Gegebenheiten (v. a. im Rahmen der Energiewende). Obwohl es sich nur um ein kleines, nicht vollständiges Beispiel handelt, wirkt es bereits sehr komplex. Dabei fehlen einige eminente Energiequellen (z. B. Kernenergie, Wasserkraft, grüner Wasserstoff oder Biogas) und dutzende Teilschritte und deren Wechselwirkungen, die im Hintergrund ablaufen. Dennoch eignet sich die Notation, um Beziehungen zwischen mehreren Akteuren auf einer hohen Abstraktionsebene zu präsentieren, anstatt diese in einem langen Fließtext zu beschreiben. Zudem können umfangreiche Teilaspekte bei Bedarf auch in mehrere Diagramme aufgeteilt werden.

Vergleich mit KAOS

KAOS ist eine weitere Notation, mit der man Ziele und deren Zusammenhänge grafisch darstellen kann. Viele Aspekte sind ähnlich, es gibt allerdings auch Unterschiede, wie die nachfolgende Liste zeigt:

• Beide Notationen umfassen mehrere Diagrammtypen, um unterschiedliche Aspekte zu beschreiben. In i* gibt es SR- und SD-Diagramme, in KAOS ein Goal Model, Object Model, Responsibility Model und ein Operation Model.
• Im Hinblick auf die Komplexität hat KAOS deutlich weniger Notationselemente.
• In beiden Notationen existieren Hardgoals und Softgoals.
• Ziele können in beiden Notationen in mehrere Unterziele aufgespalten werden. Für die Aufteilung können in beiden Notationen die logischen Operatoren And und Or verwendet werden.
• Aufgaben können hingegen in KAOS nicht in mehrere Schritte aufgeteilt werden. In i* geht das via Task Decomposition Links.
• Im Gegensatz zu KAOS existieren in i* keine Ereignisse.
• Für negative Einflüsse bzw. Hindernisse existiert in KAOS ein eigenes Notationselement, nämlich Obstacles. In i* können positive, negative und auch unbekannte Einflüsse feingranular mit den Beitragsbeziehungen Make, Some+, Unknown, Hurt, Some- und Break beschrieben werden.
• In beiden Notationen existieren Akteure, wobei sich diese in i* in mehrere Arten aufteilen lassen. In KAOS gibt es nur einen einzigen Typ Agent, der alle Arten von Akteuren abdeckt.
• Im Gegensatz zu i*, kennt KAOS keine Assoziationsbeziehungen zwischen den Akteuren.

Werkzeuge

Eine umfangreiche Liste von Programmen, mit denen i* Diagramme gezeichnet werden können, findet man im i* Wiki (Tools) der RWTH Aachen.

• OpenOME
• iStarTool der Universidade Federal de Pernambuco (UFPE)
• i* Schablonen für Microsoft Visio
• Dia (Schablonen für i* sind standardmäßig in der Software enthalten)

Weblinks

• i* Wiki der RWTH Aachen. Abgerufen am 26. November 2022 (englisch). 
• iStar 2.0 Language Guide. Abgerufen am 26. November 2022 (englisch). 
• Publikationen über i* auf Google Scholar. Abgerufen am 26. November 2022 (englisch). 
• ITU-T Recommendation Z.151: User Requirements Notation (URN) – Language definition. Abgerufen am 26. November 2022 (englisch). 
• (Nicht mehr online verfügbar.) Archiviert vom Original am 27. April 2022; abgerufen am 26. November 2022 (englisch). 

Einzelnachweise

1. Eric Yu: Modelling strategic relationships for process reengineering. 1996 (englisch, PhD Thesis, University of Toronto). 
2. Fabiano Dalpiaz, Xavier Franch Jennifer Horkoff: iStar 2.0 Language Guide. 16. Juni 2016, doi:10.48550/arXiv.1605.07767 (englisch). 
3. Eric Yu: Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering. In: Proceedings of ISRE '97: 3rd IEEE International Symposium on Requirements Engineering. IEEE Computer Society Press, 1997, ISBN 0-8186-7740-6, ISSN 1090-705X, S. 226–235, doi:10.1109/ISRE.1997.566873 (englisch, toronto.edu [PDF; 115 kB; abgerufen am 7. Juni 2022]). 
4. International Telecommunication Union (Hrsg.): Z.151: User Requirements Notation (URN) - Language definition. Oktober 2018 (englisch, itu.int [PDF; 2,3 MB; abgerufen am 20. April 2022]). 
5. Daniel Amyot, Jennifer Horkoff, Daniel Gross, Gunter Mussbacher: A Lightweight GRL Profile for i* Modeling. In: Carlos Alberto Heuser, Günther Pernul (Hrsg.): Advances in Conceptual Modeling - Challenging Perspectives. Springer, Berlin, Heidelberg 2009, S. 254–264 (englisch). 
6. Samer Abdulhadi, Jennifer Horkoff, Eric Yu, Gemma Grau: i* Guide 3.0. In: i* Wiki. RWTH Aachen, August 2006, abgerufen am 13. März 2022 (englisch, umfasst alle untergeordneten Seiten). 
7. Michael Koch, Dieter Landes: Notations for Modeling Educational Goal Profiles. In: Georg Hagel, Jürgen Mottok (Hrsg.): European Conference on Software Engineering Education. ECSEE 2014, 27th and 28th November 2014, Seeon Monastery. 1. Auflage. Shaker Verlag, Aachen 2014, ISBN 978-3-8440-3067-9, S. 45–58, urn:nbn:de:101:1-2014110911365 (englisch, 284 S.). 
8. Samer Abdulhadi, Jennifer Horkoff, Eric Yu, Gemma Grau: i* Tools. In: i* Wiki. RWTH Aachen, 7. März 2018, abgerufen am 5. Juli 2022 (englisch). 
9. Jennifer Horkoff, Yijun Yu: OpenOME. SourceForge (sourceforge.net), 3. Mai 2013, abgerufen am 6. Juli 2022 (englisch). 
10. Jaelson Castro, Átila Moreira, Josias Paes Jr., Monique Conceição Soares: iStarTool.zip. (ZIP; 56,4 MB) Universidade Federal de Pernambuco (UFPE), 9. April 2012, abgerufen am 5. Juli 2022 (englisch). 
11. Jennifer Horkoff: Istar_Stencil.vss. (VSS; 96,5 kB) RWTH Aachen, 10. Juli 2006, abgerufen am 5. Juli 2022 (englisch). 
12. RE-i*. Objekte zum Entwerfen von i*-Diagrammen. In: dia-installer.de. Abgerufen am 20. November 2022.