Goals and Quality Characteristics: Separating Concerns * * This work has been funded by the Spanish CICYT project DYNAMICA TIC2003-07776-C02-02 Elena Navarro Computer Science Department University of Castilla-La Mancha Avda. España S/N, Albacete, Spain enavarro@info-ab.uclm.es Patricio Letelier, Isidro Ramos Department of Information Systems and Computation Polytechnic University of Valencia Camino de Vera s/n, Valencia, Spain {letelier, iramos}@dsic.upv.es Abstract Software Requirements Specification (SRS) organization for complex and/or large systems have to do with several not faced challenges until the moment. This organization is a key factor to facilitate the quality assurance of the SRS, regarding features as: correctness, completeness, consistency and modifiability. Organization is also crucial for an effective exploitation of the SRS when elaborating other related or derived artefacts. Although there is a consensus about SRS content, this is not applicable to the organization. Nevertheless, it is evident that depending on the system, their stakeholders and the activities to perform with the SRS, the relevant criteria for SRS organization and presentation can be different. Additionally, another of the main problems to be solved is related to the crosscutting of requirements that produces tangled specifications. This work faces these issues: the organization of SRS by applying Aspect Oriented techniques to properly manage the crosscutting. A Goal Oriented approach for requirements allows us to establish traceability from software goals to specific requirements and from the latter to operationalizations that are realized as software components. In this work, we present an integration of aspect and Goal Oriented approaches, to properly manage the SRS organization and presentation. Furthermore, our proposal uses the standard ISO/IEC 9126 as the starting point to organize goals and requirements. ATRIUM, a methodology to concurrently define requirements and software architecture, provides the setting for our proposal. 1. Introduction IEEE 830-1998 [11] recommendations are the milestone concerning the contents which are mandatory in a Software Requirements Specification (SRS). This standard suggests several possible organizations for specific software requirements. Nevertheless, when the amount of requirements and/or the complexity are considerable, those suggestions are not enough. Requirements organization and presentation are crucial to facilitate their maintenance and ensure other desirable features such as: correction, completeness, consistency and traceability. Along the requirements elicitation and specification process, several stakeholders are involved (both from the customer and technical side) every one with their own interests and views of the system, which ought to be rightly represented and reconciled in the SRS. A requirement is a capacity that software should exhibit or a condition that should be met. This capacity or condition can be expressed at different abstraction or detail levels. Concretely, we distinguish two levels: goals and requirements. Goals allow one to establish, by means of refinement and composition processes, a derivation graph from software interests or goals until specific requirements. On the other hand, requirements are detailed enough as to be assigned to a software component and lately be verified. Goal Oriented Requirements Engineering [13] employs this strategy to perform this refinement from goals until requirements and their subsequent operationalization in software elements. In the literature, different paradigms cope with the separation of concerns of a system in order to provide support for evolution adaptability, comprehensibility, etc. These concerns can range from non-functional features, as security or fault tolerance, to functional features. Aspect Oriented Software Development (AOSD) [1] is one of these approaches. AOSD provides a set of techniques that allow managing those interests that appear scattered along the system and crosscut several elements. AOSD identifies these concerns realizing them as aspects and managing them explicitly. In the AOSD context, several proposals have been introduced at different abstraction levels, both during implementation [12] and design [21] that define an aspect as an additional constructor of the language. It is associated to the constructor “class” to manage the crosscutting that can appear in the methods specification for a class. Several works have also been proposed at the requirements level as Aspect Oriented Requirements Engineering (AORE) [20]. In this proposal, an aspect is a requirement which is related to a set of other requirements, but that is separately specified. By means of