An effective requirements engineering (RE) approach must harmonise the need to achieve separation of concerns with the need to satisfy broadly scoped requirements and constraints. Techniques such as use cases and viewpoints help achieve separation of stakeholders' concerns but ensuring their consistency with global requirements and constraints is largely unsupported. In this paper we propose an approach to modularise and compose such crosscutting, aspectual requirements. The approach is based on separating the specification of aspectual requirements, non-aspectual requirements and composition rules in modules representing coherent abstractions and following welldefined templates. The composition rules employ informal, and often concern-specific, actions and operators to specify how an aspectual requirement influences or constrains the behaviour of a set of non-aspectual requirements. We argue that such modularisation makes it possible to establish early trade-offs between aspectual requirements hence providing support for negotiation and subsequent decision-making among stakeholders. At the same time early separation of crosscutting requirements facilitates determination of their mapping and influence on artefacts at later development stages. A realisation of the proposed approach, based on viewpoints and the eXtensible Markup Language (XML), supported by a tool called ARCaDe and a case study of a toll collection system is presented.

Effective RE must reconcile the need to achieve separation of concerns with the need to satisfy broadly scoped requirements and constraints. Techniques such as use cases and viewpoints help achieve separation of stakeholders' concerns but ensuring their consistency with global requirements and constraints is largely unsupported. In this paper we build on recent work that has emerged from the aspect-oriented programming (AOP) community to propose a general model for aspect oriented requirements engineering (AORE). The model supports separation of crosscutting functional and nonfunctional properties at the requirements level. We argue that early separation of such crosscutting properties supports effective determination of their mapping and influence on artefacts at later development stages. A realisation of the model based on a case study of a toll collection system is presented.

0 7 4 0 -7 4 5 9 / 0 6 / $ 2 0 . 0 0 © 2 0 0 6 I E E E J a n u a r y / F e b r u a r y 2 0 0 6 I E E E S O F T W A R E 6 1 focus criterion, in the early stages of the software life cycle. "Early" signifies occurring before implementation in any development iteration. An aspect in requirements is a concern that crosscuts requirements artifacts; an aspect in architecture is a concern that crosscuts architectural artifacts. Identifying and managing early aspects helps to improve modularity in the requirements and architecture design and to detect conflicting concerns early, when trade-offs can be resolved more economically.In addition, identifying aspects at one stage provides benefits downstream. Knowing requirements-level aspects helps the architect design a better system, and knowing architecture-level aspects helps produce a more robust implementation. Early aspects can span development activities, and many find their way into the code as traditional implementation aspects. More concretely, identifying and managing early aspects across phases can ■ increase the consistency of requirements and architecture designs with each other and with the implementation; ■ provide a rationale and traceability for aspects across life-cycle activities; and ■ help ensure that crosscutting concerns evident in a system's problem domain or solution space are captured as aspects in the implementation.In this article, we describe how to identify and capture early aspects in requirements and architecture activities and how they're carried over from one phase to another. We'll focus on requirements and architecture design activities to illustrate the points, but the same ideas apply in other phases as well, such as domain analysis or in the fine-grained design activities that lie between architecture and implementation. There are many approaches for working with early aspects in practice (for a Discovering Early Aspects T raditionally, aspect-oriented software development has focused on the software life cycle's implementation phase: developers identify and capture aspects mainly in code. But aspects are evident earlier in the life cycle, such as during requirements engineering and architecture design.Early aspects are concerns that crosscut an artifact's dominant decomposition, or base modules derived from the dominant separation-of-concerns