istar 2.0 language guide - uzh ifidc1e764b-3e84-4ae0-a5fb-f7d2b4645b4e/... · istar 2.0 language...

iStar 2.0 Language Guide

Fabiano Dalpiaz1, Xavier Franch2, and Jennifer Horkoff3 ?

1 Utrecht University, The Netherlands2 Universitat Politecnica de Catalunya, Spain3 City University London, United Kingdom

[email protected],[email protected],[email protected]

Abstract. The i* modeling language was introduced to fill the gap inthe spectrum of conceptual modeling languages, focusing on the inten-tional (why? ), social (who? ), and strategic (how? how else? ) dimensions.i* has been applied in many areas, e.g., healthcare, security analysis,eCommerce. Although i* has seen much academic application, the di-versity of extensions and variations can make it difficult for novices tolearn and use it in a consistent way. This document introduces the iStar2.0 core language, evolving the basic concepts of i* into a consistent andclear set of core concepts, upon which to build future work and to basegoal-oriented teaching materials. This document was built from a set ofdiscussions and input from various members of the i* community. It isour intention to revisit, update and expand the document after collectingexamples and concrete experiences with iStar 2.0.

? Endorsers: Okhaide Akhigbe, Fatma Basak Aydemir, Juan Pablo Carvallo, JaelsonCastro, Luiz Marcio Cysneiros, Sepideh Ghanavati, Alicia Grubb, Giancarlo Guiz-zardi, Renata Guizzardi, Matthias Jarke, Alexei Lapouchnian, Tong Li, Lin Liu, LidiaLopez, Alejandro Mate, John Mylopoulos, Soroosh Nalchigar, Elda Paja, Angelo Susi,Juan Carlos Trujillo Mondejar, Eric Yu, Jelena Zdravkovic.

arX

iv:1

605.

0776

7v3

[cs

.SE

] 1

6 Ju

n 20

16

2 F. Dalpiaz, X. Franch, and J. Horkoff

Version History

Version Date Implemented Changes

3 June 17, 2016 New integrity rules: at most one actor link between a pair ofactors; contribution and qualification cannot connect the sametwo elements.

2 June 3, 2016 Fixed typos in the original version

1 May 26, 2016 -

iStar 2.0 Language Guide 3

1 Motivation and Overview

The i* language was presented in the mid-nineties [4] as a goal- and actor-orientedmodeling and reasoning framework. It consists of a modeling language along withreasoning techniques for analyzing created models. i* was quickly adopted by theresearch community in fields such as requirements engineering and business mod-eling. Benefiting from its intentionally open nature, multiple extensions of thei* language have been proposed (see [2,3] for useful reviews), either by slightlyredefining some existing constructs, by detailing some semantic issues not com-pletely defined in the seminal proposal, or by proposing new constructs for specificdomains.

This flexible use of i* has been fruitfully employed by researchers, who wereable to benefit from a consolidated modeling and reasoning approach whilst tai-loring it to their needs. However, this use has also some drawbacks. The mostcritical is the difficulty to spread the framework outside the experts’ community:

– Newcomers find it hard to learn the intricacies of the language;– Educators do not have a shared body of knowledge to teach;– Practitioners are not provided with an established reference for using i* in

their projects;– Technology providers cannot easily determine which are the core constructs

to be implemented and the techniques to apply on top of those constructs.

As a response to the need of balancing the framework’s open nature anda possible solution to the aforementioned adoption problems, the i* researchcommunity started an initiative to identify a widely agreed upon set of coreconcepts in the i* language. The main goal is to keep open the ability to tailorthe framework while agreeing on the fundamental constructs.

This document summarizes the outcomes of the first iteration of the iStar1

standardization process. To clearly distinguish this core language from its prede-cessors, we name it iStar 2.0.

The community discussed this language in several meetings and discussionsstarting in a dedicated one-day meeting before the ER’14 conference in Atlanta(October 2014). At the subsequent community meeting at CAiSE’15 in Stock-holm (at the iStar teaching workshop, iStarT, June 2015), it was decided thata smaller group of researchers (the authors of this document) would guide theprocess, making concrete proposals and processing the inputs of the rest of thecommunity. An initial draft of the core was discussed both at the iStar Workshopcolocated with RE’15 (August 2015) and in another dedicated one-day meetingbefore ER’15 in Stockholm (October 2015). The obtained feedback has been in-corporated into the document. A preliminary version was distributed among theresearchers that participated in this process (December 2015), who provided alast round of comments, considered in this version (May 2016).

Each of the following five sections (Section 2–6) addresses a particular cat-egory of language constructs as presented in most i* sources, for example, theiStar-wiki2. For each category, the document lists the concepts that are includedin iStar 2.0, with a definition, necessary comments, concise examples and the

1 The language is spelled iStar instead of i* to allow better indexing through searchengines.

2 http://istarwiki.org

http://istarwiki.org


graphical representation. The focus of this document is on concepts and relation-ships; methodological possibilities are mentioned only briefly.

Several aspects are excluded from this first version of iStar but are plannedfor inclusion in the next versions. Among them, we mention the ontological defi-nition of constructs (e.g., what is a goal?), visual representation (e.g., what is aneffective graphical notation?), wording conventions (e.g, passive voices in goals),and methodological issues (e.g., when can a model be considered final?).

Illustrative example. We illustrate the concepts of iStar 2.0 using a running ex-ample concerning University travel reimbursement. Students must organize theirtravel (e.g., to conferences) and have several goals to achieve, and options toachieve them. To achieve their goals, students rely on other parties such as aTravel Agency and the university’s trip management information system. We willintroduce iStar concepts gradually, slowly building up the example. In Fig. 1 weshow a final view of the example in order to give readers an early idea of thecapabilities of iStar 2.0.

Travel

organized

Authorization

obtained

Trip booked

Supervisor

authorizesHead-of-dept

authorizes

Authorization

signed

Request

prepared

Fill in paper

formFill in

online form

Quick

booking

Tickets

booked

Accommodation

booked

Trip parts

booked

Minimal own

payments

Agency buys

tickets

Self-book

tickets

Buy

tickets

Pay for

ticketsBuy through

booking.com

Buy through

hotel website

Conference

hotel bookedBudget hotel

booked

No errors

Comfort

Credit

card

Trip bundle

booked

Buy flight

tickets

Book bundle

Student

Book bundle

via expedia

Travel

agencyUniv. trip mgmt IS

Online form

processed

Process

form

Request

authorization

Notify

applicant

Details

validated

Univ. of Wonder-

Land

Mike White

PhD

student

Fig. 1. A preview of the Travel Reimbursement Scenario as captured in iStar 2.0


Organization. Section 2 introduces the notion of actor and distinguishes betweenthree types of actors. Section 3 presents the links in iStar 2.0 for relating actors.Section 4 describes the intentional elements that characterize the actors. Section 5discusses the dependencies that socially relate the actors. Section 6 explains howthe intentional elements can be linked. Section 7 details how to create differentviews of an iStar 2.0 model. Section 8 shows the metamodel of the language.Finally, we conclude and present future directions in Section 9.

2 Actors and actor types

Actors are central to the social modeling nature of the language. Actors are active,autonomous entities that aim at achieving their goals by exercising their know-how, in collaboration with other actors. In the iStar 2.0 language, two types ofactors are distinguished:

– Role: an abstract characterization of the behavior of a social actor withinsome specialized context or domain of endeavor. Examples are: Student, PhDStudent.

– Agent : an actor with concrete, physical manifestations, such as a human indi-vidual, an organization, or a department. Examples are: Travel agency, PhDStudent, University of Wonderland, Mike White.

Whenever distinguishing the type of actor is not relevant, either because ofthe scenario-at-hand or the modeling stage, the notion of generic actor—withoutspecialization—can be used in the model. For example, we can denote Travelagency as an actor to say that we do not know yet whether it is a specific agency(agent) or a characterization of the travel agency role.

Actors are represented graphically as circles. In the case of agent, a straightline is added in the top part of the actor circle. For a role, a curved line is addedin the lower part. The graphical notation follows the mnemonic guidelines thatthe original i* adopts3. Fig. 2 illustrates the notation.

Travel

agency

PhD

student

Univ. of Wonder-

Land

Fig. 2. Examples of actor, role and agent

Actors’ intentionality is made explicit through the actor boundary, which isa graphical container for their intentional elements (see Section 4) together withtheir interrelationships (see Section 6). Fig. 3 shows the graphical representationof an actor boundary; elements and relationships will appear inside the grey area.

3 These symbols are stylized depictions of a person wearing a hat and viewed fromdifferent angles. The Agent symbol is the frontal view where the name of the agentappears on the face. The Role symbol is an overhead view so that the label on thehat is visible.


Travel

agency

Fig. 3. Example of actor boundary

3 Actors association links

Actors are often interrelated. In iStar 2.0, this is captured via actor links thatdefine/describe these relationships. Actor links are binary, linking a single actorto a single other actor. Two different types of actor links have been defined:

– is-a: represents the concept of generalization / specialization in iStar 2.0. Onlyroles can be specialized into roles, or general actors into general actors. Forinstance, a PhD student (role) can be defined as a specialization of a Student(another role). Agents cannot be specialized via is-a, as they are concreteinstantiations (e.g., Mike White cannot be another agent).

– participates-in: represents any kind of association, other than generalization /specialization, between two actors. No restriction exists on the type of actorslinked by this association. Depending on the connected elements, this linktakes different meanings. Two typical situations are the following:• When the source is an agent and the target is a role, this represents the

plays relationship, i.e., an agent plays a given role. For instance, MikeWhite plays the role of PhD student.

• When the source and the target are of the same type, this will oftenrepresent the part-of relationship. For instance, the University trip man-agement information system is part of the University of Wonderland.

Every actor can participate-in multiple other actors.

Univ. trip mgmt IS

Univ. of Wonder-

Land

StudentPhD

student

Mike White

PhD

student

Fig. 4. Examples of actor association links

Actor association links are represented using arrows in the diagram. The arrow-head identifies the target (the participated actor or the superclass, respectively).


A label identifying the type of link must be included. Fig. 4 shows the graphicalrepresentation of the three examples mentioned above.

4 Intentional elements

Intentional elements are the things actors want. As such, they model differentkinds of requirements and are central to the iStar 2.0 language. An intentionalelement appearing inside the boundary of an actor denotes something that isdesired or wanted by that actor. An intentional element can also appear outsideof actor boundaries, as part of a dependency relationship between two actors (seeSection 5). In this section, we focus on the former case: elements inside actorboundaries. The following elements are included in the language:

– Goal : a state of affairs that the actor wants to achieve and that has clear-cutcriteria of achievement.

– Quality : an attribute for which an actor desires some level of achievement.For example, the entity could be the system under development and a qualityits performance; another entity could be the business being analyzed and aquality the yearly profit. The level of achievement may be defined preciselyor kept vague. Qualities can guide the search for ways of achieving goals, andalso serve as criteria for evaluating alternative ways of achieving goals4.

– Task : represents actions that an actor wants to be executed, usually with thepurpose of achieving some goal.

– Resource: A physical or informational entity that the actor requires in orderto perform a task.

Goals are graphically represented as ovals, while qualities are represented as morecurved cloud-like shapes. Tasks are represented as hexagons to highlight theirmore structured definition in terms of a process to be followed. Resources arerepresented as rectangles. Fig. 5 shows examples of the intentional elements.

Tickets

booked

Quick

booking

Pay for

tickets

Credit

card

Fig. 5. Examples of intentional elements

5 Social dependencies

Dependencies represent social relationships in iStar 2.0. This, along with the as-sumption that actors can be human, organizations, technical systems (hardware,software), or any combination thereof, makes iStar 2.0 a socio-technical modelinglanguage. A dependency is defined as a relationship with five arguments:

4 iStar 2.0 departs from the original goal / softgoal dichotomy, which distinguishesthese concepts based on the existence of a clear-cut metric for satisfaction, and fromthe Non-Functional/Functional Requirement distinction, as the use of this distinctionvaried in practice. By including qualities, which can be either “soft” or “hard” usingi* terminology, and by including the qualifies relationship between qualities and goals(Section 6.4), we clarify the relationships between goals and qualities.


– depender is the actor that depends for something (the dependum) to be pro-vided;

– dependerElmt is the intentional element within the depender’s actor boundarywhere the dependency starts from, which explains why the dependency exists;

– dependum is an intentional element that is the object of the dependency;– dependee is the actor that should provide the dependum;– dependeeElmt is the intentional element that explains how the dependee in-

tends to provide the dependum.

Student

Bundle

booked

Travel

agency

Trip bundle

booked

Book bundle

via expedia

Fill in

online form

Univ. trip mgmt IS

Check address

validity

Student

depender

depender dependee

dependee

dependerElmt

dependerElmt

dependeeElmt

dependeeElmt

dependum

dependum

Validate

fields

Fig. 6. Examples of dependencies

Dependencies (illustrated in Fig. 6) link the dependerElmt within the dependeractor to the dependum, outside actor boundaries, to the dependeeElmt within thedependee actor. The link is drawn with a “D” symbol indicating direction, withthe D acting as an arrowhead “>”, pointing from dependerElmt to dependum todependeeElmt.

Both the dependerElmt and the dependeeElmt can be omitted. This optional-ity is used when creating an initial Strategic Dependency view (see Section 7), orto support expressing partial knowledge, e.g., when the “why” (dependerElmt) orthe “how”; (dependeeElmt) of the dependency are unknown. If both are omitted,the dependency links the depender actor to the dependee actor through the de-pendum. It is also possible to specify only one of them. See Fig. 7 for an examplewhere the dependeeElmt is omitted.

The type of the dependum specializes the semantics of the relationship:

– Goal: the dependee is expected to achieve the goal, and is free to choose how;– Quality: the dependee is expected to sufficiently satisfy the quality, and is

free to choose how;– Task: the dependee is expected to execute the task in a prescribed way;– Resource: the dependee is expected to make the resource available to the

depender.

This way, different dependency types indicate different degrees of freedom affordedby the depender to the dependee, with qualities and goals allowing the highestdegree of freedom, tasks medium, and resource the lowest.


Agency buys

tickets

Travel

agencyBuy flight

tickets

Student

depender

dependum

dependee

dependerElmt

Fig. 7. Example dependency with dependeeElmt omitted

Rules and restrictions

When a depender depends on the dependee for its dependerElmt, the dependercannot or chooses not to satisfy/perform/have the dependerElmt on its own.Thus, the dependerElmt cannot be refined or contributed to.

It is possible that one or more of the dependerElmt, dependum, and depen-deeElmt have the same element name. In this case, each of these elements isnevertheless distinct, as they reflect the separate viewpoints of the depender, therelationship between the two actors, and of the dependee respectively.

Dependency relationships should not share the same dependum, as each de-pendum is a conceptually different element; in some cases, a dependum in onedependency is achieved, but is not achieved in another dependency, even if thedependums may have the same name. In other words, an actor cannot depend onmore than one actor for the same dependum, or two actors cannot depend on thesame dependum from an actor.

6 Intentional element links

There are four types of links between intentional elements: refinement, needed-by,contribution and qualification. These are described in the following sub-sectionsand are summarized in Table 1.

Table 1. Links between intentional elements: overview

Arrowhead pointing toGoal Quality Task Resource

Link starts from

Goal Refinement Contribution Refinement n/aQuality Qualification Contribution Qualification QualificationTask Refinement Contribution Refinement n/a

Resource n/a Contribution NeededBy n/a

6.1 Refinement

To promote ease of adoption, iStar 2.0 features a generic relationship called refine-ment that links goals and tasks hierarchically. Refinement is an n-ary relationshiprelating one parent to one or more children. An intentional element can be theparent in at most one refinement relationship.


Two types of refinement exist—and apply to any kind of parent (goal ortask)—that define the logical operator that relates the parent with the children:

– AND : the fulfillment of all the n children (n ≥ 2) makes the parent fulfilled;– Inclusive OR: the fulfillment of at least one child makes the parent fulfilled.

This relationship allows for a single child.

A parent can only be AND-refined or OR-refined, not both simultaneously.Depending on the connected elements, refinement takes different meanings:

– If the parent is a goal :• In the case of AND, a child goal is a sub-state of affairs that is part of

the parent goal, while a child task is a sub-task that must be fulfilled;• In the case of OR, a child task is a particular way (a “means”) for fulfilling

the parent goal (the “end”), while a child goal is a sub-goal that can beachieved for fulfilling the parent goal;

– If the parent is a task :• In the case of AND, a child task is a sub-task that is identified as part of

the parent task, while a child goal is a goal that is uncovered by analyzingthe parent task;

• In the case of OR, a child goal is a goal whose existence that is uncoveredby analyzing the parent task which may substitute for the original task,while a child task is a way to execute the parent task.

Refinement relationships do not imply a strictly top-down process, they can bebuilt from the bottom-up, top-down, or via a mixed approach.

Graphically5, refinement is expressed as a set of links directed from the sub-elements to the parent element. We employ a T-shaped arrowhead to denoteAND-refinement, and a solid arrow directed towards the parent to represent OR-refinement (we use the original i* symbol). See Fig. 8 for examples.

Authorization

obtained

Authorization

signed

Request

prepared

Tickets

booked

Agency buys

tickets

Trip booked

Trip parts

booked

Book bundle

Process

form

Request

authorization

Notify

applicantDetails

validated

Fig. 8. Examples of refinement links

The first refinement shows a goal decomposed into two sub-goals that areboth necessary (AND-refinement) to achieve the parent. The second refinementshows alternatives (OR-refinement): to book a trip, either the parts are booked,a bundle is booked, or both alternatives are chosen; while the former sub-elementis a sub-state of affairs to achieve (a goal), the latter sub-element is a concreteset of actions to execute (a task). The third refinement exemplifies the existenceof a single alternative. The fourth refinement shows the uncovering of goals whileanalyzing tasks: the goal “Details validated” is in the model because of the task“Process form”.5 As mentioned in Section 1, an accurate study of the graphical definition of refinement

(and other relationships) is left to future versions of the language.


6.2 NeededBy

The NeededBy relationship links a task with a resource and it indicates thatthe actor needs the resource in order to execute the task. This relationship doesnot specify what is the reason for this need: consumption, reading, modification,creation, etc. Graphically, NeededBy is represented as an arrow with a circlearrowhead directed towards the task, as shown in Fig. 9.

Pay for

tickets

Credit

card

Fig. 9. Example of NeededBy relationship

6.3 Contribution

Contribution links represent the effects of intentional elements on qualities, andare essential to assist analysts in the decision-making process among alternativegoals or tasks. Contribution links lead to the accumulation of evidence for qual-ities. We talk of qualities being fulfilled or satisfied, having sufficient positiveevidence, or being denied, having strong negative evidence.

Contributions are defined as relationships from a source intentional elementto a target quality, and having one of the following types:

– Make: The source provides sufficient positive evidence for the satisfaction ofthe target.

– Help: The source provides weak positive evidence for the satisfaction of thetarget.

– Hurt : The source provides weak evidence against the satisfaction (or for thedenial) of the target.

– Break : The source provides sufficient evidence against the satisfaction (or forthe denial) of the target.

Contributions are represented graphically as solid arrows with a text labelthat indicates the contribution type (see Fig. 10). While the examples show con-tributions starting from goals and tasks, it is also possible to initiate contributionsfrom resources and qualities.

Supervisor

authorizes

Quick

booking

Bundle

booked

Minimal own

payments

Head-of-dept

authorizes

Quick

booking

Fill in paper

form

No errors

Fig. 10. Example of contribution links


6.4 Qualification

The qualification relationship relates a quality to its subject: a task, goal, orresource. For example, the quality “Quick booking” refers to the goal “Trip partsbooked”, it qualifies how the operation or function of this goal should be achieved.Similarly, the quality “No errors” refers to errors possibly created while fulfillingthe goal “Request prepared”, elaborating on how this goal might be achieved.Qualities are not necessarily attached to other elements through a qualificationlink. For example, “Avoid own payments” can be a standalone quality that doesnot qualify any other element, particularly if a task or goal concerning makingone’s own payments is not present in the model.

Placing a qualification relationship expresses a desired quality over the execu-tion of a task, the achievement of the goal, or the provision of the resource. Forexample, in Fig. 11, saying that “No errors” qualifies “Request prepared” meansthat the preparation of a request should be achieved in such a way that it leadsto no errors. The qualification relationship is represented graphically via a dottedline connecting the element that is qualifies.

Request

prepared

No errors

Fig. 11. Example of qualification link

7 Model views

When using iStar 2.0, the analyst creates a model. Such model can be visualizedvia multiple perspectives or model views (see also [1]). We specifically introducethree views that stem from the original i* proposal and some extensions: theStrategic Rationale view, the Strategic Dependency view, and the Hybrid view.

Strategic Rationale (SR). The SR view shows all of the detail captured in themodel, including actors, dependencies, actor association links, and the internaldetails of each actor. Modelers can view the strategic rationale inside each of theactors in the model. An SR view for the travel reimbursement scenario was shownat the beginning of this document, in Fig. 1.

Strategic Dependency (SD). The SD view shows each actor in the model, the actorassociation links, and the dependency relationships from depender to dependumto dependee. Fig. 12 shows an SD view of the travel reimbursement scenario.

Hybrid SD/SR. It is often useful to combine SD/SR views where some of theactors are open, but not all, focusing on the strategic rationale of a particular setof actors, and the actor links are hidden. This view is illustrated in Fig. 13.

Further useful views can be defined as needed, for example, the actor view,showing only actors and actor links, or a functional view, hiding all qualities,contribution and restriction links.


Student

Univ. trip mgmt IS

Travel

agency

Trip bundle

booked

Buy flight

tickets

Mike White

PhD

student

Univ. of Wonder-

Land

Online form

processed

Fig. 12. An SD view of the Travel Reimbursement scenario

Travel

organized

Authorization

obtained

Trip booked

Supervisor

authorizesHead-of-dept

authorizes

Authorization

signed

Request

prepared

Fill in paper

formFill in

online form

Quick

booking

Tickets

booked

Accommodation

booked

Trip parts

booked

Minimal own

payments

Agency buys

tickets

Travel

agency

Self-book

tickets

Buy

tickets

Pay for

ticketsBuy through

booking.com

Buy through

hotel website

Conference

hotel bookedBudget hotel

booked

No errors

Comfort

Online form

processed

Credit

card

Trip bundle

booked

Buy flight

tickets

Book bundle

Univ. trip mgmt IS

Student

Fig. 13. A hybrid SD/SR view of the Travel Reimbursement scenario


8 Metamodel

The metamodel for iStar 2.0 is shown in Fig. 14. The concepts and relationshipsin the metamodel have been explained and illustrated in the previous sections. We

{xor}

Actor

Agent Role

participates-in .

0..*0..*

Intentional Element

wants . 1 0..*

Quality

Task

Resource

Dependency

depender

0..*

1

dependee .

0..*

1

dependerElmt .0..*

0..1

dependeeElmt .0..*

0..1

dependum .1

1

Goal

GoalTask Element

contributesTo .0..*

0..*

neededBy

0..*

0..*

. is-a0..*0..*

. qualifies0..*

0..*

. qualifies

0..*

0..*

Refinement . refines 10..1

AND-refinement

OR-refinement

to .0..1 1..*

to .0..1

2..*

Contribution Type

{xor}

Fig. 14. Metamodel of iStar 2.0

describe a number of integrity constraints that explain more detailed constraintson the models that the iStar 2.0 metamodel allows:

– The is-a relationship applies only between pairs of roles or pairs of actors;– There should be no is-a cycles;– There should be no participates-in cycles;– A pair of actors can be linked by at most one actor link: it is not possible to

connect two actors via both is-a and participates-in;– In a dependency D, if the dependerElmt x exists, then the actor that wants

x is the same actor that is D’s depender ;– In a dependency D, if the dependeeElmt y exists, then the actor that wants

y is the same actor that is D’s dependee;– The depender and dependee of a dependency should be different actors;– For a dependency, if a dependerElmt x exists, then x cannot be refined or

contributed to;– The refinement relationship should not lead to refinement cycles (e.g., G OR-

refined to G1 and G1 OR-refined to G, G OR-refined to G, etc.);– The relationships between intentional elements (contributesTo, qualifies, need-

edBy, refines) apply only to elements that are wanted by the same actor;


– An intentional element and a quality can be linked by either a contributesTorelationship or a qualifies relationship, but not by both;

– It is not possible for a quality to contribute to itself.

Finally, note that some classes in the metamodel are abstract (GoalTask Element,Intentional Element, Refinement) as they are used to group together (via special-ization) concrete classes that share some characteristics. On the other hand, Actoris also specialized but it is a concrete class, thereby denoting that actors can beinstantiated without further specialization.

9 Conclusion and Outlook

This document presented the results of the iStar standardization process thathas led to the definition of the iStar 2.0 language. Supported by the researchcommunity of iStar, we promote the adoption of iStar 2.0 for educational andtraining purposes. To such extent, one of the next steps will be the creation ofteaching materials that can be readily used to teach iStar 2.0.

This document does not conclude the standardization process. Following it-erative design principles, we encourage the entire community to assist us in theconduction of studies about the ease of use, the adequacy for teaching, the ex-pressiveness, the graphical notation, and the automated reasoning techniques thatcan support iStar 2.0.

Although our efforts in reconciling the numerous viewpoints of the commu-nity, we are well aware that there is still room for improvement. Therefore, wewarmly welcome your feedback concerning the chosen primitives, the graphicalnotation, typographic errors, etc. We especially welcome examples of models thatare created using iStar 2.0, which are especially helpful to pinpoint the aspectsthat can be improved.

Contact us by sending an e-mail or post public comments on the iStar 2.0website: https://sites.google.com/site/istarlanguage/.

References

1. Fabiano Dalpiaz, Elda Paja, and Paolo Giorgini. Security Requirements Engineering:Designing Secure Socio-Technical Systems. MIT Press, 1 edition, 2016.

2. Jennifer Horkoff, Tong Li, Feng-Lin Li, Mattia Salnitri, Elsa Cardoso, Paolo Giorgini,John Mylopoulos, and Joao Pimentel. Taking goal models downstream: a system-atic roadmap. In International Conference on Research Challenges in InformationScience, pages 1–12. IEEE, 2014.

3. Jennifer Horkoff and Eric Yu. Comparison and evaluation of goal-oriented satisfactionanalysis techniques. Requirements Engineering, 18(3):199–222, 2013.

4. Eric Siu-Kwong Yu. Modelling strategic relationships for process reengineering. PhDthesis, University of Toronto, 1996.

https://sites.google.com/site/istarlanguage/

istar 2.0 language guide - uzh ifidc1e764b-3e84-4ae0-a5fb-f7d2b4645b4e/... · istar 2.0 language...

Documents