J. Eder and M. Missikoff (Eds.): CAiSE 2003, LNCS 2681, pp. 633–646, 2003. © Springer-Verlag Berlin Heidelberg 2003 Evolving Requirements through Coordination Contracts Ana Moreira 1 , José Luiz Fiadeiro 2 , and Luís Andrade 3 1 Dept. Informatics, Faculty of Sciences and Technology, New University of Lisbon, 2829-516 Caparica, Portugal amm@di.fct.unl.pt 2 Department of Mathematics and Computer Science, University of Leicester Leicester LE1 7RH, United Kingdom jose@fiadeiro.org 3 ATX Software S.A., Alam. António Sérgio 7–1C, 2795-023 Linda-a-Velha, Portugal landrade@atxsoftware.com Abstract. Use-case driven software development processes can seriously com- promise the ability of systems to evolve if a careful distinction is not made be- tween "structure" and "use", and this distinction is not reflected immediately in the first model and carried through to the implementation. By "structure", we are referring to what derives from the nature of the application domain, i.e. to what are perceived to be the "invariants" or core concepts of the business do- main, as opposed to the business rules that apply at a given moment and deter- mine the way the system (solution) will be used. This paper shows how the notion of coordination contract can be used to support the separation between structure and use at the level of system models, and how this separation supports the evolution of requirements on "use" based on the re- vision or addition of use cases, with minimal impact on the "structure" of the system. 1 Introduction Use cases as introduced by Jacobson [11] and incorporated into the UML [3] play a fundamental role in object-oriented system development: they provide a description of the way the system is required to interact with external users. Existing proposals for a software development based on the UML are use case driven. It is not difficult to understand why. Given that the ultimate goal is to produce software that fulfils the expectations of the prospective users, driving the process based on user needs seems to make good sense. However, our own experience in developing software using object-oriented meth- ods has revealed that this approach is not without dangers. A use-case driven process can compromise the ability of the system to evolve if a careful distinction is not made between “structure” and “use”, and this distinction is not reflected immediately in the