User:Ashot97/I*
 | |
| Developer(s) | Eric Yu, advised by John Mylopoulos |
|---|---|
| Initial release | 1993 |
| Stable release(s) | |
2016: iStar 2.0 2008: i* wiki 1994: i* metamodel 1993: i* genesis | |
| Type | Requirements Engineering |
i* (pronounced "i star") or i* framework is a modeling language suitable for an early phase of system modeling in order to understand the problem domain, such as the elicitation phase of requirements engineering. Whereas i* itself is part of the goal modeling domain, i* models are coined as sociotechnical systems[2][3][4] since these provide a way to represent the social and technical aspects of a system and their interactions. In current times, the i* framework is often referred to as iStar 2.0; the name of its most recent stable release. The name i* refers to the notion of distributed intentionality which underlines the framework. It is an approach originally developed for modeling and reasoning about organizational environments and their information systems composed of heterogeneous actors with different, often competing, goals that depend on each other to undertake their tasks and achieve these goals.[5][6] The i* modeling language is introduced to focus on the intentional (why?), social (who?), and strategic (how? how else?) dimensions.[1][6] The current version, iStar 2.0, builds on this ideology.
The i* language was originally introduced as a actor modeling and goal modeling framework.[1] It includes a modeling language as well as reasoning methods for evaluating models that have been developed. The research community quickly adopted i* in areas such as requirements engineering and business modeling.[1] Several modifications to the i* language have been proposed over the years, either via subtly revising particular existing terms, expressing certain semantic concerns that were not explicitly expressed in the original proposal, or suggesting new components for particular areas.[1]
Modeling components
[edit]
The original i* framework consists of two main modeling components, that is, two perspectives on a model: The Strategic Dependency view and the Strategic Rationale view.[6] Within the iStar 2.0 release, even a third perspective has been introduced, namely the combination of both views: the Hybrid view.[1][7]
Strategic Dependency
[edit]A Strategic Dependency (SD) model describes a network of dependency relationships among various actors in an organizational context. In the SD model, actors are typically identified within the context in which they operate, as this allows for a clear understanding of the dependencies and relationships between actors in the organizational context. This model shows who an actor is and who depends on the work of an actor.[5]
An SD model consists of a set of nodes and links connecting the actors. Nodes represent actors and each link represents a dependency between two actors. The depending actor is called the Depender and the actor who is depended upon is called the Dependee.
Strategic Rationale
[edit]A Strategic Rationale (SR) model allows modeling of the reasons for each actor and their dependencies and provides information about how actors achieve their (soft) goals. This model only includes elements considered important enough to impact the results of a goal.[5]
The SR model shows the dependencies of the actors by including the SD model. Relating to these dependencies, the SR model specifies goals, soft goals, tasks, and resources. In iStar 2.0, soft goals are considered as qualities.[1] Compared to SD models, SR models provide a more detailed level of modeling by looking inside actors to model internal, intentional relationships. Intentional elements (goals, soft goals, tasks, resources) appear in the SR model not only as external dependencies but also as internal elements linked by means-ends relationships and task-decompositions. The means-end links explain why an actor would engage in some tasks, pursue a goal, need a resource, or want a soft goal; the task-decomposition links provide a hierarchical description of intentional elements that make up a routine. Such a model is used to describe stakeholder interests and concerns, and how they might be addressed by different configurations of systems and environments.
Hybrid SD/SR
[edit]When using the i* framework, it can be helpful to mix different views of the model to focus on specific aspects of the system. For example, we can show some actors but not all, and also hide certain relationships between them. Further useful ideas 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. The Hybrid SD/SR approach, as founded within the iStar 2.0 framework, allows for a more comprehensive understanding of the system by considering multiple perspectives.
Elements
[edit]
A key aspect of the i* framework is the use of specific elements to describe the dependencies between actors. These elements are used to model the requirements and dependencies of the different actors and agents in a system and to identify the ways in which they may be affected by the system. This allows for a comprehensive understanding of the relationships and interactions between stakeholders, enabling the identification of opportunities and vulnerabilities within the system. These elements will be further discussed in the following sections. Note that only the most important elements of the i* notation will be discussed, such as the actor and the intentional elements.
To maintain comprehensivity, not all elements (as noted in the figure containing the i* notation) are discussed in great detail. More details about the purpose of these relationships, dependencies, and the remaining elements can be found in the original i*[5] and iStar 2.0 guidelines[1].
Actor
[edit]The model describes the dependencies between actors. Within the i* framework, the central concept is that of the intentional actor. Organizational actors are viewed as having intentional properties such as goals, beliefs, capabilities, and commitments (the concept of distributed intention).
Actors depend on each other to achieve goals, perform tasks, and provide resources. An actor can achieve goals that he finds difficult or impossible to achieve on his own by relying on others; Yet an actor becomes vulnerable if dependent actors fail to carry out their own respective tasks.[5] Actors are strategic in the sense that they are concerned with opportunities and vulnerabilities. Also, they attempt to tailor their environment to better suit their interests through the reorganization of planned relationships. Actor boundaries refer to the limits that define the scope of an actor's goals and responsibilities in relation to the system and other actors.
Three actor types exist within i*, namely: Actor, Agent, and Role. In i*, an actor is a stakeholder or agent that is involved in or affected by a system or process. Actors can be people, organizations, or even software systems. Actors are used for modeling the relationships and interactions between stakeholders in a system, and to identify the goals, interests, and needs of those stakeholders. Also, the use of actor elements is typical when it is unclear if the actor in question is an agent or role.
An agent is a particular category of actor that symbolizes a conscious, independent being that may act to accomplish its goals. An agent can be a person, an organization, or a software system, and is characterized by its ability to make decisions and take independent action based on its own goals and motivations.
A role, on the other hand, is a set of responsibilities and behaviors that are associated with a particular actor or agent. Roles can be used to model the different ways in which an actor or agent may interact with a system or process, and to represent the different goals, interests, and needs that the actor or agent may have in relation to the system.
Within an educational institute, a Student would be an actor (since it is not specified who this student is), whereas Students from Faculty X would represent a role (since it is more specified, but not atomic), and Student A would represent an agent.
Intentional elements
[edit]In the i* framework, there are four intentional elements that are used to model the goals, dependencies, and relationships between actors and agents in a system.
- Goals: Goals, also referred to as hard goals, represent the desired outcomes or objectives that actors or agents have in relation to a system. Goals can be used to represent the motivations and interests of actors and agents, and to identify the ways in which they may be affected by the system.
- Softgoals: Softgoals represent the not strictly necessary, but often desirable, objectives or outcomes that actors or agents have with regard to a system. Softgoals can be used to represent the preferences and values of actors and agents, and to identify the ways in which the system may influence them. NOTE: Within iStar 2.0, these are depicted as qualities.[1]
- Tasks: Tasks represent the actions or activities that actors or agents must perform in order to achieve their goals. Tasks can be used to model the behaviors and responsibilities of actors and agents, and to identify the dependencies and interactions between them.
- Resources: Resources represent the tangible or intangible assets that actors or agents need in order to perform their tasks and achieve their goals. Resources can be used to model the constraints and dependencies of actors and agents, and to identify the ways in which the system may impact them.
These four intentional elements are used in the i* framework to model the requirements and dependencies of complex sociotechnical systems, focusing on how different actors and agents interact with each other and with the system as a whole. Commonly, goals and tasks are mixed up. To implement some form of homogeneity, it is common practice to write goals in the past form “Degree obtained”, whereas tasks are presented in the active form “Obtain degree”. Furthermore, goals do not present a precise (sequence of) step(s) to take in order to achieve the goal. Tasks, however, are unambiguous and atomic to show exactly what is to be done to complete the task.
Contribution Relationships
[edit]Contribution links, as defined in the original i* framework, describe how an element contributes to the achievement of a soft goal.[8] These links are represented as simple arrows, with the type of link written at the edge of the arrow will. NOTE: These relationships differ from the current iStar 2.0 framework.[1]
| type | description |
|---|---|
| Make | A positive contribution that is strong enough on its own to achieve a goal. |
| Help | A positive contribution that is not strong enough on its own to achieve a goal. |
| Some+ | A positive contribution that helps achieve a goal, but whose weight (Help or Make) is unknown or difficult to assess. |
| Break | A negative contribution that is strong enough on its own to dismiss a target. |
| Hurt | A negative contribution that is not strong enough on its own to disallow a target. |
| Some- | A negative post whose severity (Hurt or Break) is unknown or difficult to assess. Perhaps such an influencing factor is enough to discard a goal. |
| Unknown | An influencing factor whose effect is difficult to assess. It can be a positive, negative or neutral post. As the data improves over time, these relationships can be replaced or removed accordingly. |
| And | An overarching goal is achieved when all subordinate goals have been achieved. It is therefore a logical conjunction. |
| Or | An overarching goal is achieved when at least one of the subordinate ones has been achieved. One speaks here of a logical disjunction. In some derived dialects, a distinction is made explicitly between disjunction (IOR) and contravalence (XOR). |
History of i* development
[edit]The i* framework was developed by researchers at the University of Toronto in the 1980s and 1990s. It builds on a number of other modeling languages and frameworks that were developed in the field of software engineering in the 1970s and 1980s, including Structured Analysis and Design Technique (SADT), Entity-Relationship Diagrams (ERDs), and Object-Oriented Analysis and Design (OOAD).[6][1][9][7]
Here is a rough chronology of the development of the i* framework:
- 1980s-1990s: The i* framework is developed at the University of Toronto, building on SADT, ERD, and OOAD.
- 1993: i* genesis is developed. i* genesis is a version of the i* framework. It is based on the original i* framework but adds additional features and capabilities, such as the ability to model the evolution of a system over time and the ability to model the values and beliefs of stakeholders.[10]
- 1994: i* metamodel is developed. The metamodel is a formal representation of the structure and elements of the i* framework. It defines the different types of elements that can be used in an i* model (such as actors, goals, and tasks) and the relationships between those elements. The i* metamodel serves as a reference for creating and interpreting i* models and helps to ensure that those models are consistent and well-formed.[10]
- Late 1990s: The i* framework is published and begins to gain wider recognition in the field of software engineering.
- 2000s: The development of the i* metamodel promoted and accelerated other developments.
- 2000 The publication of the NFR framework.[10]
- 2001 The publication of Tropos: A Framework for Requirements-Driven Software Development.[10]
- 2008: i* Wiki is developed. This site is intended to enable collaborative work on i* and related topics.
- 2010s: The iStar 2.0 version of the i* framework is developed, adding new features and capabilities. It is designed to be more flexible and expressive than the original i* framework and to support the modeling of a wider range of requirements and dependencies.
- Present: The i* framework continues to be used and developed in a variety of fields, including computer science, engineering, and organizational studies.
Reasons for using i*
[edit]There are several reasons identified why people might choose to use the i* framework:[1][7]
- Representing and analyzing the relationships and objectives of a organization and how to achieve them.
- These diagrams consist of a number of different elements, including actors, goals, and dependencies. By representing these elements visually in an i* diagram, it is possible to analyze the relationships between actors, goals, and dependencies, and to identify potential conflicts and gaps in the achievement of goals. This can help to inform the development of strategies for achieving those goals and managing dependencies.
- Identifying potential gaps and inconsistencies in achieving objectives.
- By analyzing the dependencies between actors and goals, it is possible to identify potential conflicts and gaps that may hinder the achievement of those goals. For example, if two actors have conflicting goals, this may create a gap that needs to be addressed in order to achieve both goals. Similarly, if an actor has a goal that depends on another actor's goal, but that second actor's goal is in conflict with the first actor's goal, this may create a conflict that needs to be resolved. Identifying these conflicts and gaps can help to inform the development of strategies for achieving goals and managing dependencies.
- Evaluating the effects of changes on an organization's objectives and relationships via scenario analysis.[11]
- Scenario analysis is a technique for evaluating the potential consequences of a decision or action by considering different possible outcomes. In the context of the i* framework, scenario analysis can be used to consider the potential impact of a proposed change on an organization's goals and dependencies. To perform scenario analysis using the i* framework, you would first create an i* diagram that represents the current state of the organization, including its actors, goals, and dependencies. You would then create additional i* diagrams that represent different scenarios, each representing a different possible outcome of the proposed change. By comparing the i* diagrams for the different scenarios, you can evaluate the potential impact of the proposed change on the organization's goals and dependencies. This can help to inform decision-making and identify potential risks or unintended consequences of the proposed change.
- Identifying and prioritizing steps to achieve objectives via goal breakdown and improvement.
- Goal decomposition is the process of breaking down a high-level goal into smaller, more specific subgoals. This helps to make the goal more manageable and easier to achieve. In the i* framework, goal decomposition is represented visually in an i* diagram by linking a high-level goal to one or more subgoals using a dashed line. Goal refinement is the process of further breaking down subgoals into even more specific and actionable subgoals. This helps to make the goals even more specific and easier to achieve. In the i* framework, goal refinement is represented visually in an i* diagram by linking a subgoal to one or more specific subgoals using a dashed line. By decomposing and refining goals in this way, it is possible to identify the specific actions that need to be taken in order to achieve those goals. This can help to prioritize actions and inform the development of a plan for achieving the desired goals.
- Facilitating collaboration and communication among stakeholders for strategy development and implementation by providing a standard language and process.
- This includes steps for identifying goals, analyzing dependencies, and developing and evaluating scenarios. By following this methodology, stakeholders are able to work together more efficiently and effectively to develop and implement strategies that are aligned with the organization's goals.
Drawbacks of applying i*
[edit]Several complexities and drawbacks can be identified regarding the practicality of the i* framework:[1][7]
- It can be time-consuming to create and maintain i* diagrams, especially for large or dynamic organizations with many actors and goals.
- This can be time-consuming because it requires careful analysis and consideration of the relationships between all of these elements. Once an i* diagram has been created, it must be maintained in order to ensure that it accurately reflects the current state of the organization. This may require updating the diagram as new actors and goals are added, or as existing actors and goals change. This can also be time-consuming, especially if the organization is large or dynamic.
- It may be difficult for stakeholders who are not familiar with the i* framework to understand and interpret i* diagrams.
- Each element in an i* diagram, such as an actor or a goal, is represented by a specific symbol, and the relationships between these elements are represented by lines with different styles and patterns. In order to understand and interpret an i* diagram, stakeholders must be familiar with these symbols and conventions. If stakeholders are not familiar with the i* framework, they may have difficulty understanding and interpreting the diagrams, and may need to spend time learning about the framework in order to effectively use it. This can be a barrier to effective communication and collaboration using i* diagrams.
- The i* framework is not well-suited for analyzing situations that involve a high degree of uncertainty or rapid change.
- In situations where there is a high degree of uncertainty or rapid change, it may be difficult to accurately identify and represent the relationships between actors and goals. This can make it challenging to use the i* framework effectively in these situations, as the analysis may be based on incomplete or inaccurate information. Additionally, the i* framework is focused on the analysis and development of long-term strategies, which may not be relevant in situations that involve rapid change. In these cases, more flexible and adaptable approaches may be more suitable for analyzing and responding to changing circumstances. There are numerous different approaches that may be more suitable for analyzing and responding to changing circumstances than the i* framework, depending on the specific needs and context of the situation. Overall, the best approach will depend on the specific needs and context of the situation and may involve a combination of different methods and frameworks.
- It can be challenging to accurately represent complex or dynamic relationships between actors and goals in an i* diagram.
- The i* framework is designed to represent relatively simple and static relationships. In situations where the relationships between actors and goals are complex or dynamic, it may be difficult to accurately represent these relationships using these simple lines and patterns. In these cases, it may be necessary to use other tools or approaches in addition to or in place of the i* framework in order to accurately represent and analyze the relationships between actors and goals. Such examples would be: Network analysis, System dynamics, Agent-based modeling, or Graph databases.
i* tool comparison
[edit]There are various tools closely related to i*. All of which have their own strengths and weaknesses. This table shows a variety of the tools that are available. [12]
| i* Tool | Description |
|---|---|
| piStar | The piStar modelling tool is an open-source, online, i* 2.0 modelling tool. Access from here. |
| VISIO | A general modeling tool created by the Microsoft Corporation. Access from here |
| OpenOME | As a standalone application and as a plug-in for other popular tools, such as Eclipse and Protégé, OpenOME is designed to be a goal-oriented and/or agent-oriented modeling and analysis tool. Access from here. |
| RE-Tools[12] | RE-tools is an open-source requirements modeling toolkit. The following notations are supported by RE-tools: NFR framework, i* framework, KAOS, Problem Frames, BPMN, and UML. Access from here. |
| jUCMNav | jUCMNav is a graphical editor for ITU-T's User Requirements Notation (Z.150). URN is composed of two complementary notations: the Use Case Map (UCM) scenario notation and the Goal-oriented Requirement Language (GRL). GRL is based on the i* and NFR frameworks. jUCMNav is an Eclipse plug-in that provides editors for both notations, links between both views, analysis capabilities (including GRL model evaluations), and various import and export formats. Access from here. |
| TAOM4E | TAOM4E supports model-driven, agent-oriented software development and, in particular, the Tropos methodology. It has been designed taking into account Model Driven Architecture (MDA) recommendations. Access from here. |
| GR-Tool | Forward and backward reasoning is supported in Tropos by a Goal Reasoning Tool (GR-Tool). Basically, the GR-Tool is a graphical tool in which it is possible to draw the goal models and run the algorithms and tools for forward and backward reasoning. The algorithms for forward reasoning have been fully developed in java and are embedded in the GR-Tool. Access from here. |
| REDEPEND-REACT | REDEPEND-REACT is a tool that supports i* modeling and the analysis of the resulting models. This version extends the REDEPEND i* modeling tool. The extension focus on the representation of the information system using the i* framework and provides specific functionalities for the generation and evaluation of alternative architectures for the modeled information system. |
| T-Tool | T-Tool provides a framework for the effective use of formal methods in the early requirements phase. The framework allows for the formal and mechanized analysis of early requirements specifications expressed in a formal modeling language. |
| ST-Tool | ST-Tool, the Secure Tropos tool, is a graphical tool where it is possible to draw Secure Tropos models and to perform the effective formal analysis of Secure Tropos specifications. The tool is written in Java with the swing components and uses XML as its document format. Formal analysis is based on logic programming. ST-Tool allows to different systems based on Datalog to analyze Secure Tropos specifications. |
| J-PRiM | JPRiM is a tool in Java that supports PRiM, a methodology that addresses i* modeling and analysis from a Process Reengineering point of view. J-PRiM allows one to analyze an existing information system and to represent it as a hierarchy of i* elements. Once modeled, several alternatives for the system as-is can be explored, each of one model as a different i* model. All the generated alternatives can be evaluated by defining and applying metrics over the i* models in order to establish which is the most appropriate for the system to-be. |
| Snet Tool | Within this tool, the i* formalism is applied and extended in the context of a requirements engineering methodology to support inter-organizational networks. In particular, the tool provides an automatic transformation of graphical network representations (based on extended i*) into executable programs. Via this, network participants can simulate various network scenarios whose outcomes may give valuable information regarding the risks and benefits of taking certain actions. |
| OME | A graph editor to support goal-oriented and/or agent-oriented modeling. |
| DesCARTES | DesCARTES (Design CASE Tool for Agent-Oriented Repositories, Techniques, Environments and Systems) Architect a Computer-Aided Software Engineering (CASE) Tool developed by the Information Systems Unit (ISYS) at the Catholic University of Louvain (UCL). It is designed to support various models edition: i* models (Strategic Dependency and Strategic Rationale models), NFR models, UML models, and AUML models in the context of Tropos and I-Tropos developments. DesCARTES is a plug-in for the Eclipse IDE (Integrated Development Environment). The originality of the tool is that allows the development of the methodology analysis and design models as well as forward engineering capabilities and an integrated software project management module. |
The table below shows a comparison between the various tools, showing which capabilities they have. [12]
| Main purpose of the tool: | OpenOME | OME | REDEPEND- REACT-BCN | TAOM4E | GR-Tool | T-Tool | ST-Tool | J-PRiM | jUCMNav | Snet Tool | DesCARTES | RE-Tools | VISIO |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| i* modelling | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | ||
| Analysis or Evaluation of models | Yes | Yes | Yes | Yes | |||||||||
| Support the Tropos Methodology | Yes | ||||||||||||
| Forward and backward goal reasoning in Tropos | Yes | Yes | |||||||||||
| Early requirements analysis using KAOS and Formal Tropos | Yes | Yes | |||||||||||
| Formal analysis of functional and security requirements | Yes | ||||||||||||
| User Requirements Notation (URN) = UCM + GRL | Yes | ||||||||||||
| Simulation of networks scenarios | Yes | ||||||||||||
| Support the PRiM methodology | Yes | Yes | |||||||||||
| NFR, UML and AUML modelling | Yes | Yes | |||||||||||
| Support the I-Tropos methodology | Yes | ||||||||||||
| Provide forward engineering capabilities | Yes | ||||||||||||
| Provide an integrated software project module | Yes |
i* and variants
[edit]Various (goal) modeling languages exist alongside the i* framework. It is closely related to the general purpose modeling language UML for late requirements. It is therefore not uncommon to convert i* models to UML models. Furthermore, it is closely related to the goal modeling languages KAOS and GRL. There are various drawbacks and benefits to using one over the other, as will become clear from the following section.
Application and integration
[edit]i* to UML
[edit]i* is used for the early requirements and UML for late requirements. Thus you have to transform the i* model into a UML model. You can do this by using the following guidelines:
- actors: actors can be mapped to class aggregation,
- tasks: tasks can be mapped to class operations. For example a task between a dependent actor and a dependence in the SD model corresponds to a public operation in the dependence UML class,
- resources: resources can be mapped as classes,
- goals and soft goals: strategic goals and soft goals can be mapped to attributes,
- task decomposition: the task decomposition can be represented by pre- and post-conditions.
Comparison to similar methods
[edit]UML
[edit]i* is a framework for modeling strategic relationships and dependencies in organizations and systems. It was developed by academics in the fields of information systems and organizational design.
UML (Unified Modeling Language) is a standardized visual language for specifying, constructing, visualizing, and documenting the artifacts of software systems. It is used to model the structure and behavior of software systems, as well as for business modeling and other non-software systems.
In general, i* is used for modeling the strategic goals and dependencies of an organization or system, while UML is used to model the design and implementation of software systems. However, both i* and UML can be used for modeling and analysis, and they can be used in conjunction with each other in some cases.[13]
Goal Modeling languages
[edit]KAOS
[edit]KAOS (Knowledge Acquiring and Organizing System) is a goal-oriented requirements engineering method that is used to model the functional and non-functional requirements of a system.[14] It is based on the i* framework.[1] There are some similarities and differences between KAOS and the i* framework:
Similarities:
- They are used to model the requirements and dependencies of a system.
- Both approaches are based on the concept of actors and the dependencies between them.
- Both methods can be used to model complex systems with multiple actors and dependencies.
Differences:
- KAOS is a method for requirements engineering, while the i* framework is a modeling language.
- KAOS focuses on the identification and organization of requirements, while the i* framework is more focused on the representation and analysis of dependencies between actors.
- KAOS is more prescriptive and structured in its approach, while the i* framework is more flexible and allows for the representation of a wider range of dependencies.
In summary, KAOS is based on the i* framework and uses many of the same concepts and principles. However, KAOS is more focused on the identification and organization of requirements, while the i* framework is more focused on the representation and analysis of dependencies between actors.
GRL
[edit]Goal-oriented Requirements Language (GRL) is a graphical modeling language that is used to represent and analyze the goals and dependencies of a system. [15] It is based on the i* framework.[1] There are some similarities and differences between GRL and the i* framework.
Similarities:
- Both GRL and the i* framework are based on the concept of actors and the dependencies between them.
- Both approaches are used to represent and analyze the requirements and dependencies of a system.
- Both methods can be used to model complex systems with multiple actors and dependencies.
Differences:
- GRL is a graphical modeling language, while the i* framework is a general-purpose modeling language.
- GRL is more focused on the representation and analysis of goals and dependencies, while the i* framework is more general and can be used to represent a wider range of dependencies.
- GRL allows for the automatic generation of goal-oriented traceability links between requirements and design elements, while the i* framework does not have this capability.
In summary, GRL is based on the i* framework and uses many of the same concepts and principles. However, GRL is more focused on the representation and analysis of goals and dependencies and has the added capability of generating traceability links between requirements and design elements.
External links
[edit]Category: Specification languages Category: Software requirements
- ^ a b c d e f g h i j k l m n o Dalpiaz, Fabiano; Franch, Xavier; Horkoff, Jennifer (16 June 2016). "iStar 2.0 Language Guide". arXiv:1605.07767 [cs].
- ^ Dell’Anna, Davide; Dalpiaz, Fabiano; Dastani, Mehdi (1 September 2019). "Requirements-driven evolution of sociotechnical systems via probabilistic reasoning and hill climbing" (PDF). Automated Software Engineering. 26 (3): 513–557. doi:10.1007/s10515-019-00255-5.
- ^ Yu, Eric; Giorgini, Paolo; Maiden, Neil; Mylopoulos, John (2010). "Social Modeling for Requirements Engineering". The MIT Press. doi:https://doi.org/10.7551/mitpress/7549.001.0001.
{{cite journal}}:|access-date=requires|url=(help); Check|doi=value (help); External link in|doi= - ^ Franch, Xavier; López, Lidia; Cares, Carlos; Colomer, Daniel (2016). "The i* Framework for Goal-Oriented Modeling". Domain-Specific Conceptual Modeling: 485–506. doi:10.1007/978-3-319-39417-6_22.
- ^ a b c d e Yu, E.S.K. (1993). "Modeling organizations for information systems requirements engineering". [1993] Proceedings of the IEEE International Symposium on Requirements Engineering: 34–41. doi:10.1109/ISRE.1993.324839.
{{cite journal}}:|access-date=requires|url=(help) - ^ a b c d Yu, Eric S. (2009). Conceptual Modeling: Foundations and Applications. Berlin, Heidelberg: Springer Berlin Heidelberg. pp. 99–124. ISBN 10.1007/978-3-642-02463-4_7.
{{cite book}}: Check|isbn=value: invalid character (help) - ^ a b c d Yu, Eric S. (2009). "Social Modeling and i*" (PDF). In Borgida, Alexander T.; Chaudhri, Vinay K.; Giorgini, Paolo; et al. (eds.). Conceptual Modeling: Foundations and Applications. LNCS. Vol. 5600. Springer. pp. 99–121. doi:10.1007/978-3-642-02463-4_7. ISBN 978-3-642-02462-7. ISSN 0302-9743.
- ^ Cite error: The named reference
iStar_Wiki_Guidewas invoked but never defined (see the help page). - ^ Dalpiaz, Fabiano; Franch, Xavier; Horkoff, Jennifer. "iStar-tutorial-online.pdf" (PDF). Dropbox.
- ^ a b c d Cares, Carlos; Franch, Xavier (Advisory role) (2012). "From the i* Diversity to a Common Interoperability Framework".
{{cite journal}}:|access-date=requires|url=(help); Cite journal requires|journal=(help) - ^ Palomino, Marco A.; Bardsley, Sarah; Bown, Kevin; De Lurio, Jennifer; Ellwood, Peter; Holland‐Smith, David; Huggins, Bob; Vincenti, Alexandra; Woodroof, Harry; Owen, Richard (1 January 2012). "Web‐based horizon scanning: concepts and practice". Foresight. 14 (5): 355–373. doi:10.1108/14636681211269851. ISSN 1463-6689. Retrieved 5 Jan 2023.
- ^ a b c "i* tools". istarwiki. Retrieved 11 January 2023.
- ^ Santander, V.F.A.; Castro, J.F.B. (2002). "Deriving use cases from organizational modeling". Proceedings IEEE Joint International Conference on Requirements Engineering: 32–39. doi:10.1109/icre.2002.1048503.
- ^ Van Lamsweerde, Axel; Darimont, Robert; Letier, Emmanuel (11-1998). "Managing Conflicts in Goal-Driven Requirements Engineering" (PDF). ieee transactions on software engineering. 24 (11): 908–925. Retrieved 5 January 2023.
{{cite journal}}: Check date values in:|date=(help) - ^ Quartel, Dick; Engelsman, Wilco; Jonkers, Henk; Van Sinderen, Marten (01-04-2009). "A Goal-Oriented Requirements Modelling Language for Enterprise Architecture". 2009 IEEE International Enterprise Distributed Object Computing Conference. doi:10.1109/EDOC.2009.22.
{{cite journal}}: Check date values in:|date=(help)