User:Ashot97/I*

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 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. The i* modeling language is introduced to focus on the intentional (why?), social (who?), and strategic (how? how else?) dimensions. The current version, iStar 2.0, builds on this ideology.

The i* language was originally introduced as a actor modeling and goal modeling framework. 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. 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.

Modeling components
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. Within the iStar 2.0 release, even a third perspective has been introduced, namely the combination of both views: the Hybrid view.

Strategic Dependency
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.

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
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.

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. 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
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
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* and iStar 2.0 guidelines.

Actor
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. 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
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.


 * 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
Contribution links, as defined in the original i* framework, describe how an element contributes to the achievement of a soft goal. 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.

History of i* development
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).

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.
 * 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.
 * 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.
 * 2001 The publication of Tropos: A Framework for Requirements-Driven Software Development.
 * 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*
There are several reasons identified why people might choose to use the i* framework:
 * 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. 
 * 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*
Several complexities and drawbacks can be identified regarding the practicality of the i* framework:
 * 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
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.

The table below shows a comparison between the various tools, showing which capabilities they have.

i* and variants
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.

i* to UML
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.

UML
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.

KAOS
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. It is based on the i* framework. 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
Goal-oriented Requirements Language (GRL) is a graphical modeling language that is used to represent and analyze the goals and dependencies of a system. It is based on the i* framework. 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.