i*

i*
Name	i*
Developer	Academic research community
Released	Late 1990s
Latest release	N/A
Programming language	N/A
Operating system	Cross-platform (notation)
Genre	Requirements engineering; conceptual modeling
License	Academic

i*.

i* is a goal-oriented conceptual modeling framework developed for early-phase requirements engineering and organizational modeling. It emphasizes intentionality, social dependencies, and strategic rationale among actors to capture goals, tasks, resources, and softgoals in socio-technical settings. The notation and constructs of i* support analysis of stakeholder goals, alternative means, and trade-offs, enabling alignment of system requirements with organizational objectives.

Overview

i* originated in the late 1990s within research communities that included scholars associated with University of Toronto, York University, University of Toronto Scarborough, and collaborative projects linked to ACM venues and IEEE workshops. It was introduced to address shortcomings in traditional techniques such as Unified Modeling Language and BPMN when modeling stakeholders’ intentions and interdependencies. i* became influential in requirements engineering curricula at institutions like Carnegie Mellon University, University of Oxford, and Technical University of Denmark and appeared in conferences such as the International Conference on Requirements Engineering and the International Conference on Conceptual Modeling. Over time, it influenced or was integrated with approaches such as Goal-oriented requirements engineering, KAOS, and Tropos.

Notation and Concepts

The core concepts in i* revolve around intentional actors and their relationships. An actor (often a person, role, or organizational unit) is represented as an entity that has goals and depends on others for achieving outcomes. i* distinguishes between strategic rationale models and strategic dependency models: the former captures internal intentional elements, while the latter captures inter-actor dependencies. Central constructs include goals, softgoals, tasks, resources, and their decomposition and contribution links. Softgoals model qualitative nonfunctional concerns, a feature resonating with work at ACM SIGSOFT and debates in IEEE Transactions on Software Engineering. The emphasis on social dependency aligns i* with actor-network perspectives discussed at London School of Economics seminars and organizational studies at Harvard Business School.

Modeling Elements and Constructs

i* modeling uses a limited but expressive palette of elements. Actors are nodes that contain internal elements: goals (representing desired states), tasks (means to accomplish goals), resources (physical or informational artifacts), and softgoals (subjective qualities). Decomposition links (AND/OR) express task refinement; contribution links indicate positive or negative effects on softgoals. Dependency links in strategic dependency models include depender, dependee, and dependum to make explicit the type of dependency, a pattern also used in Rational Unified Process-informed analyses. The strategic rationale model exposes alternatives and motivates trade-offs, facilitating mappings to traceability frameworks used in projects at Siemens or Nokia. Notation conventions were refined alongside tool-support initiatives at groups linked to University of Trento and University of Twente.

Methodology and Modeling Process

The i* methodology typically begins with stakeholder identification and scoping, followed by elicitation of goals and dependencies through interviews, workshops, or document analysis. Analysts construct strategic dependency models to identify critical dependences among stakeholders and then elaborate strategic rationale models for key actors to surface internal motivations and alternative means. Iterative refinement uses scenario analysis and what-if reasoning borrowed from techniques promoted at INCOSE and in case studies from European Commission projects. Validation often involves stakeholders from World Bank or industry partners for alignment with business objectives and regulatory constraints like those enforced by European Medicines Agency in pharmaceutical projects. Traceability from i* elements to later artifacts such as use cases, UML models, and test cases is a common practice.

Applications and Case Studies

i* has been applied across sectors: information systems design in Royal Bank of Scotland, healthcare workflow redesign studies at Mayo Clinic and Karolinska Institutet, e-government initiatives in Estonia and Canada, and socio-technical analyses in manufacturing projects at Bosch and Toyota. Case studies published in venues such as the Journal of Systems and Software and Requirements Engineering Journal illustrate its use for modeling organizational change, policy compliance, and stakeholder negotiation. Hybrid studies combined i* with methods like Business Process Model and Notation and Design Science Research to support tool selection and enterprise architecture alignment in organizations including Accenture and Capgemini.

Tool Support and Implementations

Tool support for i* ranges from academic prototypes to integrated modeling platforms. Notable tools and integrations have appeared in projects hosted by groups at University of Toronto, Universidad Politécnica de Madrid, and University of Oulu, and include plug-ins for environments such as Eclipse and extensions for enterprise modeling suites used by Sparx Systems. Research tools provide automated reasoning support for goal satisfaction, conflict detection, and traceability to artifacts in GitHub-hosted repositories. Industrial adoption often leverages custom implementations or mappings to UML and ArchiMate for interoperability with enterprise architecture tools used by Oracle and IBM. Ongoing tool development continues within research consortia and at conferences like MODELS and RE.

Category:Requirements engineering