Tropos [
One of the main advantages of the Tropos methodology is that it allows to capture not only the what or the how, but also the why a piece of software is developed. This, in turn, allows for a more refined analysis of the system dependencies and, in particular, for a much better and uniform treatment not only of the system functional requirements, but also of the non-functional requirements. Tropos, although not exclusively, addresses particularly well the Agent Oriented Programming. In fact, the decision of using mentalistic notions in all the analysis phases has important consequences. Agent oriented specifications and programs use the same notions and abstractions used to describe the behavior of the human agents and the processes involving them; thus, the conceptual gap between users’ specification (in terms of why and what) and system realization (in terms of what and how), is reduced to a minimum.
Tropos supports five phases of software development: early requirements, late
requirements, architectural design, detailed design and implementation [
The present short paper concentrates on the analysis of the early requirement phase for the definition of a support tool for the Tropos methodology itself, called, since now on, the Tropos tool. In particular, the task of encoding initial informal requirement into the diagrammatic format used in the methodology, as well as the incremental transformational process that is at the basis of the construction of the complete model, will be addressed.
artifacts underesastialnydable manPaRGger manage versions and doc.
feassitbuidlyity delivered reqmuoidreelmeednts understand Legend customer req.
The early requirements analysis concerns with the understanding of a problem by
studying an existing organizational setting. The intentions of the stakeholders are modeled
as goals and goal dependencies among actors, and analyzed by means some form of
goal analysis [
An awful lot of high level requirements has been identified, listed and justified
in [
A further step concerns the decomposition of each goal from the point of view of the
actor who committed for its fulfillment. Goals are analyzed by using three basic analysis
techniques: means-ends analysis, contribution analysis and AND-OR decomposition [
In Figure 2, the goal requirements modeled is the “end” in a means-ends analysis where the “mean” is the goal build a requirements Tropos model. This last is AND-decomposed into the four subgoals: learn Tropos language, model managed, model documented and model reasoned.
An instance of contribution analysis is provided, in the figure, between the softgoal exhaustive guide and the goal learn Tropos language. Of course, subgoals deriving from an AND-OR analysis can be further AND-OR analyzed. For example, model managed is decomposed into the retrotraceability managed, multiple views visualized, diagrams edited and syntax of model checked. The subgoals automatic documentation generated and version managed contribute positively at the achievement of the goal model documented. The first subgoal concerns with the automatic generation of the documentation about the conceptual model and/or
PRG manager Legend
+ Contribution
OR decomposition AND decomposition + exhaustive
guide learn Tropos
language retrotraceability managed multiple views visualized requirements modeled build a requirements
Tropos model model managed diagrams edited
model documented
+ sintax of model checked
automatic documentation generated some views on it, while the second regards the management of different versions for each analyst.
The final setting of each Tropos phase may be reached after possibly several
refinements, in each one of which not only new details may be added, but, also, already
present elements and dependencies can be revised or even deleted [
It is obvious that the diagram of Figure 2 (and other developed during a first loop [
PRG manager exhaustive guide + learn Tropos
language views on the model visualized retrotraceability managed feasibility
study delivered model managed diagrams edited
Fig. 3. Revising Goal analysis from the point of view of the Analyst.
Just as an example of the intra-phase refinement activity, the revision of the
goal diagram in Figure 2 is presented in Figure 3. The contributions from build
a requirements Tropos model to organization described and understand
customer requirements are here introduced. These were initially considered as
original Analyst’s goal (see Figure 1), but then not further analyzed in Figure 2. The
revision proposed in Figure 3 is necessary to complete the analysis of the
requirements of Figure 2, according to what was initially introduced in Figure 1. Among
others elements introduced in the revision, let’s list: design case tests, text
documented, graphic documented and feasibility study delivered (see
Figure 1), that became the end in a means-ends analysis where the “mean” is the goal
record interview. For more details, see [
In the present paper the early analysis for a Tropos tool has been used as a case study for presenting some features of the Tropos methodology itself.
One point that deserves a note here is that the management of traceability has been raised as a crucial point for correctly dealing with the revision (specially the inter-phase revision) process. In future works, we aim at further developing this issue with other specifically focused case studies and examples.