Abstract. This position paper focuses on a forecast technology: a software development methodology founded on the concepts of agent and goal. This methodology is requirements-driven in the sense that the concepts used to define requirements for a software system are also used later on during design and implementation. Our proposal adopts Eric Yu's i* framework [1], a modeling framework for early requirements and use it  to model not just early, but also late requirements, as well as architectural and detailed design. The proposed framework, named Tropos, seems to complement nicely current proposals for agent-oriented programming platforms.
 

Motivation

Software development techniques have traditionally been inspired and driven by the programming paradigm of the day. During the era of structured programming, structured analysis and design techniques were proposed [2, 3], while object-oriented programming has given rise more recently to object-oriented design and analysis [4, 5]. Using the same concepts to align requirements analysis with software design and implementation makes perfect sense. For one thing, such an alignment reduces impedance mismatches between different development phases.  Moreover, such alignment can lead to coherent toolsets and techniques for developing software. As well, it can streamline the development process itself.

But, why base such an alignment on implementation concepts? Requirements analysis is arguably the most important stage of software development. This is the phase where technical considerations have to be balanced against social and personal ones. Not surprisingly, this is also the phase where the most and costliest errors are introduced to a software system. Even if (or rather, when) the importance of design and implementation phases wanes sometime in the future,  requirements analysis will remain a critical phase for the development of any software system, answering the most fundamental of all design questions: "what is the system intended for?"

A Software Development Framework

This position paper speculates on the nature of a forecast methodology: a software development framework, named Tropos, which is requirements-driven in the sense that it is based on concepts used during early requirements analysis. Moreover, we have argued that current software development techniques lead to inflexible and non-generic software. This is the case because the elimination of goals during late requirements freezes into the design of a software system a variety of assumptions which may or may not be true in its operational environment. To this end, we adopt the concepts offered by i* such as actor, agent, position and role, as well as social dependencies among actors, including goal, softgoal, task and resource dependencies and use it  to model not just early, but also late requirements, as well as architectural and detailed design.

The proposed methodology spans four phases of software development:

• Early requirements, concerned with the understanding of a problem by studying an existing organizational setting; the output of this phase is an organizational model which includes relevant actors and their respective goals;
• Late requirements, where the system-to-be is described within its operational environment, along with relevant functions and qualities;
• Architectural design, where the system's global architecture is defined in terms of subsystems, interconnected through data and control flows;
• Detailed design, where each architectural component is defined in further detail in terms of inputs, outputs, control, and other relevant information.

The Tropos project is only beginning and much remains to be done. We will be working towards a modelling framework which views software from four complementary perspectives:

• Social -- who are the relevant actors, what do they want? What are their obligations? What are their capabilities??
• Intentional -- what are the relevant goals and how do they interrelate? How are they being met, and by whom??
• Process-oriented -- what are the relevant business/computer processes? Who is responsible for what??
• Object-oriented - what are the relevant objects and classes, along with their inter-relationships?

In addition, we propose to offer three levels of software specification. The first is strictly diagrammatic. The second involves formal annotations which complement diagrams. For example, annotations may specify that some obligation takes precedence over another. These could be used as a basis for simple forms of analysis. Finally, we propose to include within Tropos a formal specification language for all built-in constructs, to support deeper forms of analysis. Turning to the organization of Tropos models, the concepts of i* will be embedded in a modeling framework which supports generalization, aggregation, classification, materialization and contextualization. Elements of UML will be adopted as well for modeling the object and process perspectives.

Like other requirements modelling frameworks proposed in the literature, we recognize that diagrams are important for human communication, but are imprecise and offer little support for analysis. Partially formal annotations can help in defining some forms of analysis, and they serve as bridges between informal diagrams and formal specifications. Finally, formal specifications serve as foundation for a formal semantics, as well as a range of analysis techniques, including proofs of correctness, process simulation, goal analysis etc.
 

Conclusion

This position paper argues in favour of a software development methodology which is founded on intentional concepts, such as those of actor, agent and goal, (goal, task, resource, softgoal) dependency, etc. Our argument rests on the claim that the elimination of goals during late requirements, freezes into the design of a software system a variety of assumptions which may or may not be true in its operational environment. Given the ever-growing demand for generic, component-ized software that can be downloaded and used in a variety of computing platforms around the world, we believe that the use of intentional concepts during late software development phases will become prevalent and should be further researched.

References

[1] Yu, E., Modelling Strategic Relationships for Process Reengineering, Ph.D. thesis, Department of Computer Science, University of Toronto, 1995.
[2] DeMarco, T., Structured Analysis and System Specification, Yourdon Press, 1978.
[3] Yourdon, E. and Constantine, L., Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Prentice-Hall, 1979.
[4] Wirfs-Brock, R., wilkerson, B., Wiener, l., Designing Object-Oriented Software. Englewood Cliffs, NJ; Prentice-Hall.
[5] Booch, G., Rumbaugh, J., Jacobson, I., The Unified Modeling Language User Guide, The Addison-Wesley Object Technology Series, Addison-Wesley, 1999.