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

node 1 at the tree at the left: “does the depender depend on the dependee to achieve
an entity, or to attain a certain state? If entity, go to 3; if state, go to 2”). (b) The
definition of a grammar for fixing the syntax of intentional elements in order to
obtain uniform models from the point of view of naming (e.g., a Task's name is of
the form: “Verb + (Object) + (Complement)”, as in “Answer doubts by e-mail”).
(c) The agreement on standard vocabularies for using as lexicon in the intentional
models, e.g. the ISO/IEC 9126-1 standard [ 64] for quality concepts. On the other
hand, Oliveira et al. [ 48] propose i ∗ Diagnoses, a method that uses questions as a
way to elicit the intentional elements that compose the i ∗ models, e.g. “Why does
<<dependee>> collaborate with <<depender>> to have <<goal>>?” and “What if
<<goal>> is shared with another actor?”. Both proposals claim that the methods
produce more predictable models, although no validation supports these claims.
Grau et al. [ 32] propose the PR i M method framed in the business process reengi-
neering problem. Detailed Interaction Scripts describe the current behaviour of the
system in a scenario-like style. A set of prescriptive rules transform these scripts
into i ∗ models that act as the basis for an activity of generation of alternatives to be
evaluated as part of the reengineering process.
A comprehensive comparative analysis using 12 criteria and including Tropos,
R i SD, PR i M and three other methods (GBM, ATM and BPD) may be found at [ 30] .
Research directions. Given Yu's statement above, it is clear that aiming at design-
ing fully deterministic i ∗ modelling methods should not be an ultimate goal. But
based on the work described above, we may indicate some factors supporting the
formulation of more prescriptive methods:

• Steps . The method shall consist of a series of well-defined steps and substeps.

Remarkably, the model elements that may appear as input and output of each
step and their relationships shall be defined in terms of the i ∗ metamodel.

• Refinement rationale . The method shall provide a clear rationale about:

(1) whether is it still necessary to refine a given intentional element; (2) which
kind of decomposition is needed; (3) which type do the decomposing intentional
elements have. The use of questions as proposed in [ 22, 48] is probably the most
comfortable way to proceed for the modeller.

•

Correctness checks . The method shall provide verifiable means to check that the
model being generated fulfils some identified conditions about their structure.
The use of metrics [20] could help here.

• Patterns . The method shall contemplate the possibility of using knowledge pat-

terns as a way to drive reusability. Patterns could be organized into different
catalogues depending on the step where they apply (e.g., social patterns like in
[ 27] , but also requirement patterns as mentioned in [61, 70] , design patterns, etc.).

• Vocabulary . The method shall promote the use of ontologies as a way to improve

the accuracy of the models, as well as they consistence of different models over
the same domain or system facet. Ontologies of interest may include domain
ontologies like the REA enterprise ontology [ 66] , or facet ontologies like the
ISO/IEC 9126 quality standard [ 64] for non-functional characteristics used in