Page 113 -

98 GIORGINI, KOLP, AND MYLOPOULOS
are open, thanks to Web service and agent technologies, so that their components are no longer
determined at design-time, and can instead be discovered and composed at run-time to fulfill a
system’s mandate. IS are also multiply interconnected to many other information systems running
within and outside an organization, so that they can share data and support business processes
that are geographically and organizationally distributed. Most important, these interconnections
continuously evolve along with the organization in which they were conceived and its strategic
alliances. “Service orientation,” “peer-to-peer,” and “virtual organizations” are the buzzwords of
the day. Welcome to the Age of the Internet!
Within such a context, the components of IS need to support mechanisms for discovering ex-
ternal components that can help them fulfill their mission, for negotiating with these components,
and for composing selected ones dynamically. In addition, they need monitoring and diagnostic
mechanisms that supervise the operation of relevant software pieces and ensure that everything
is in order. Moreover, they need ways of self-repairing and self-tuning to ensure that the overall
system will be robust, reliable, and effective—despite the fact that it operates in open, dynamic
environments. None of these mechanisms is intrinsic to the object-oriented software paradigm.
But they all are intrinsic to the agent-oriented software paradigm (Jennings, 2000).
Not surprisingly, there has been growing interest in agent-oriented software development during
the past few years, including several projects aimed at the development of a comprehensive meth-
odology for building agent-oriented software. Many of these projects approached the problem by
proposing extensions to object-oriented software development techniques (e.g., Odell, Van Dyke
Parunak, and Bauer, 2000). Others adopted agent-oriented programming platforms as a baseline
and sought to extend these by introducing agent-oriented analysis and design techniques (e.g.,
Wooldridge, Jennings, and Kinny, 2000). An excellent overview of the whole field can be found
in Bergenti, Gleizes, and Zambonelli (2004). A brief summary is also included in this chapter.
This chapter introduces the Tropos methodology for agent-oriented software development
and compares it with other proposals in the same family. The following sections present the
Tropos methodology and its development phases, a brief introduction of the Media Shop case
study used in later sections to show the Tropos phases, a discussion of related work, and a
concluding section.

TROPOS

Tropos rests on the idea of using requirements modeling concepts to build a model of the system-
to-be within its operational environment. This model is incrementally refined and extended, pro-
viding a common interface to the various software development activities. The model also serves
as a basis for documentation and evolution of the software system.
In the following, we describe and illustrate the four development phases of the Tropos meth-
odology: requirements analysis (early and late), architectural design, and detailed design.

Requirements Analysis

Requirements analysis represents the initial phase in most software engineering methodologies.
Requirements analysis in Tropos consists of two phases: early requirements and late require-
ments analysis. The early requirements phase is concerned with understanding the organizational
context within which the system-to-be will eventually function. Late requirements analysis, on
the other hand, is concerned with a definition of the functional and nonfunctional requirements
of the system-to-be.