Requirements as Goals and Commitments Too - Intentional Perspectives on Information Systems Engineering - page 148

Query 3. Can Fly support commitment C 3 to customer ?
As observed before, commitment support reduces to goal support. Thus, let's
check whether Fly can support ticketsShipped if the antecedent of C 3 ( service-
Paid and shippingPaid ) holds. Given the goal tree hierarchy of Fig. 5, the three
goals that relate to C 3 are children of the top-level goal ticketsSold . The second
solution of Query 1 tells us that Fly can support C 3 as it contains all such goals.

5 Discussion

Goal-oriented requirements engineering methodologies have been conceived with
a traditional view of software in mind. They are adequate to design systems where
stakeholders cooperate in a fully specified environment, but they are not thought for
open systems composed of autonomous and heterogeneous participants.
The MAP approach [ 29] is describes processes in terms of intentions and strate-
gies : a map is a directed graph where nodes are intentions and directed arrows
represent strategies. A strategy explains how to achieve one intention starting from
another intention. Maps have been recently used to define the concept of Intentional
Services Oriented Architecture (ISOA) [ 30] , where the authors conceive services in
terms of intentional abstractions such as goals. In our approach, we model agents
as goal-driven entities. However, we place emphasis on the modeling of the system
itself via the social abstraction of commitments.
The i ∗ framework [ 43] starts from the identification of the stakeholders in
the analyzed organizational setting and model these stakeholders—actors—in
terms of their own goals and the dependencies between them. However, as con-
cerns open settings such as socio-technical systems, i ∗ suffers from two primary

drawbacks.
One, dependencies do not capture business relationships as commitments do.
Guizzardi et al. [ 20] and Telang and Singh [ 39] highlight the advantages of com-
mitments over dependencies for capturing relationships between roles. Both Telang
and Singh and Gordijn et al. [ 19] especially note that dependencies do not capture
the reciprocal nature of a business transaction.
Two, the strategic rationale model violates the heterogeneity principle by making
assumptions about the goals of others actors. Commitments, by contrast, obviate
looking inside an actor; as mentioned above, they completely decouple agents.
i ∗ has been recently used to describe services [ 23] ; this approach violates
agents heterogeneity by making assumptions about other participants' internals.
Commitment protocols are more reusable than the goal models of actors [14] .
Tropos [ 4] builds on top of i ∗ and adds models and concepts to be used in the
development phases that follow requirements engineering. Being a derivative of i ∗ ,
Tropos suffers of the same problem concerning dependencies. Tropos provides an
architectural model for the agents to develop, but exploits a weak notion of agency.
Agents are designed and implemented under the assumption that they will cooperate