Fostering the Adoption of i by Practitioners: Some Challenges and Research Directions - Intentional Perspectives on Information Systems Engineering - page 178

starting point since it is able to express virtually all of the concepts included in
the wiki version. Also, it is not oriented to any particular metamodeling technol-
ogy like EMOF, we think that technology-independence is a good property for this
general-purpose metamodel.
As for the customization, we propose that each proposal which needs a particular
variant of the i ∗ metamodel as reference, should formally specify the relationship
with the i ∗ metamodel. To do so, more than a simple refactoring exercise as proposed
in [ 9] , a semantically rich definition has to be provided. We may take for instance
the formal framework proposed by Wachsmuth [ 69] and then use the several rela-
tionships defined therein (equivalence, enrichment, extension, etc.) to classify the
proposed metamodel with respect to the i ∗ metamodel, providing also the concrete
mapping functions that express the differences in a rigorous manner.
One possible immediate application of this notion is to obtain technology-
oriented versions of the i ∗ metamodel. For instance, in [ 26] it is proposed to use
i ∗ as initial model in a model-driven development process, and a particular ver-
sion of the metamodel using EMOF defines the form that this departing model
may have. In the context proposed here, this EMOF version could be elaborated
as a semantics-preserving variation of the i ∗ metamodel. The mapping from this
EMOF-based version to the i ∗ metamodel would then be completely accurate.
Another technology-oriented version is the iStarML interchange format [ 10] .
This format translates the metamodel proposed in [ 9] into XML. It is currently used
as import/export format in the H i ME tool [ 34] and planned for adoption in a next
release of TAOM4E [ 63] . A natural consequence of agreeing on the i ∗ metamodel
would be to evolve iStarML into a version compliant to this metamodel.

3 Challenge 2: Providing Methodologies for i ∗ Modelling

Context. In general, modelling is an activity that requires prescriptive methods
in order to be repeatable, reproducible and in general, predictable. One could
reasonably expect that when facing the same problem, two different (teams of)
experts in both the domain being modelled and the modelling framework, working
independently, should produce very similar, in some sense “equivalent” models.
Problem. Modelling becomes harder when the level of abstraction of the knowl-
edge to be modelled increases. Therefore, creating a model for the requirements of
a system is harder than creating a model of a software architecture. When consider-
ing the i ∗ framework, the modelling activity is harder than ever due to its intentional
nature. As Yu states, “The i ∗ framework is aimed at modelling strategic relationships
and reasoning. Such knowledge is not expected to be complete” [ 71] . In addition, the
i ∗ language itself allows a degree of freedom that creates some uncertainty not only
to the novice, but also to the expert, modeller. A summary of recurrent questions
include:

Being i ∗ models of strategic nature, which elements have strategic relevance
enough as to be included in the models, and which don't, and why.

•