E. Dubois and K. Pohl (Eds.): CAiSE 2006, LNCS 4001, pp. 513 – 527, 2006.
© Springer-Verlag Berlin Heidelberg 2006
An Empirical Evaluation of the i* Framework in a
Model-Based Software Generation Environment∗
Hugo Estrada1,2, Alicia Martínez Rebollar1,3, Oscar Pastor1, and John Mylopoulos4
1
Valencia University of Technology, Valencia, Spain
{hestrada, alimartin, opastor}@dsic.upv.es
2 CENIDET, Cuernavaca, Mor. Mexico
3 ITZ, Zacatepec, Mor. Mexico
4 University of Trento, Italy
jm@cs.toronto.edu
Abstract. Organizational modelling has been found to be very effective in
facilitating the elicitation of requirements for organizational information
systems. In this context, the i* modelling framework has been used widely in
research and – some – industrial projects. However, no empirical evaluation
exists to-date to identify areas of strength as well as weaknesses of the
framework. This paper presents the results of an empirical evaluation of i*
using industrial case studies. These were conducted in collaboration with an
industrial partner who employs an object-oriented and model-driven approach
for software development. The evaluation of i* uses a feature-based framework.
The paper reports on lessons learned from this experience, both in terms of
strengths and detected weaknesses. The results of this evaluation can play an
important role in guiding extensions of the i* framework.
1 Introduction
Organizational modelling is a promising approach for early requirements analysis
during the development of organizational information systems. In this context, the i*
modelling framework [13] offers a well-founded and widely used set of concepts for
describing organizational settings made up of social actors who have freedom of
action, but also depend on other actors to achieve their goals.
The i* framework and its methodological extensions (such as GRL [4] and Tropos
[2]) have been used in a wide range of application domains, such as business modelling,
object-oriented software development, software requirements elicitation, agent-oriented
software development, modelling and analysis of non-functional requirements, security
requirements, trust and privacy requirements, and more. In all these applications, i*
concepts have been used to capture social and intentional elements of each specific
domain, thereby supporting software development. However, despite well-known
theoretical advantages of i*, there have been no empirical studies that confirm its
usefulness and identify potential weak spots.

∗
This work has been partially supported by the MEC project with ref. TIN2004-03534, the
Valencia University of Technology, Spain, Care Technologies Enterprise Inc. and the University
of Trento, Italy.

514 H. Estrada et al.
The purpose of this paper is exactly this: to present an empirical evaluation of i*,
based on industrial case studies. The case studies were conducted in collaboration with
Care Technologies Inc. (http://www.care-t.com), a software company that has adopted
the OO-Method for software development. OO-Method is a model transformation
method that relies on a CASE tool ([7]) to automatically generate complete information
systems from object-oriented conceptual models. The OO-Method can be viewed as a
computer-aided requirements engineering (CARE) method where the focus is on
properly capturing system requirements in order to manage the complete software
production process. The resulting conceptual model specifies what the system is
(problem space). Then, an abstract execution model is provided to guide the
representation of these requirements in a specific software development environment
that is focused on how the system will be implemented (solution space).
The transformation from a conceptual to an execution model (implementation) is
effected by a Conceptual Model Compiler. The compiler exploits precise transformation
rules from conceptual modelling constructs to corresponding software representations.
The execution model is based on a component-based architecture in order to deal with
the characteristics of component-based systems. The final software product’s
functionally is equivalent to the requirements specification. Figure 1 presents a
graphical representation of the OO-Method.
Problem
Space Level
Automated
Translation
Solution
Space Level
Formal Specification
Late Requirements
Repository
Uses
Conceptual Model
Functional Model
Object Model
Dynamic Model
Presentation Model
Navigational Model
Persistence Tier (SQL Server, ORACLE)
Application Tier (.NET, EJB)
Interface Tier (Visual Environments, Web, XML)
Empiricism (ESE)
Obtain
Care Technologies, S.A.

Fig. 1. The OO-Method approach for model-driven software development
Despite the major advantage of the OO-Method in automatically generating
information systems, there are disadvantages as well. Specifically, there are currently
no mechanisms for acquiring the requirements of an information system.
Accordingly, the next step in developing further the OO-Method consists of adding a
new phase of organizational modelling as a starting point to determine the correct
requirements for the information system-to-be.