Evidence is mounting that aspect-oriented programming is useful for (re-)structuring the many concerns that software is designed to address. Many of these concerns often arise in the problem domain, and, therefore, there is a growing effort to examine 'early aspects' - to identify and represent concerns that arise during software requirements engineering and design, and to determine how these concerns interact. But can one seek to identify aspects too early? While identifying concerns during requirements elicitation may indeed be profitable, the notion of crosscutting concerns, indeed of crosscutting requirements, may only make sense when elements of a solution also begin to be explored. There are two consequences of this: a case for more interleaving of the processes of requirements engineering and design, and a case for the explicit development of specifications that map the problem and solution structures. We elaborate and discuss this thesis, and offer an alternative research agenda for aspect-oriented requirements engineering.
展开▼
