Crosscutting requirements Export

@inproceedings{nuseibeh04aosd, abstract = {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.}, address = {Lancaster, UK}, author = {Nuseibeh, Bashar}, booktitle = {International conference on Aspect-oriented software development}, citeulike-article-id = {781131}, citeulike-linkout-0 = {http://dx.doi.org/10.1145/976270.976272}, doi = {10.1145/976270.976272}, isbn = {1581138423}, journal = {aosd 04}, keywords = {aspects, evolution, requirements}, pages = {3--4}, posted-at = {2006-07-31 21:20:34}, priority = {0}, publisher = {ACM Press}, title = {Crosscutting requirements}, url = {http://dx.doi.org/10.1145/976270.976272}, year = {2004} }

TY - CONF ID - nuseibeh04aosd L3 - citeulike-article-id:781131 N2 - 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. JF - aosd 04 SN - 1581138423 AD - Lancaster, UK EP - 4 TI - Crosscutting requirements PB - ACM Press T2 - International conference on Aspect-oriented software development SP - 3 KW - aspects KW - evolution KW - requirements AU - Nuseibeh, Bashar PY - 2004/// UR - http://dx.doi.org/10.1145/976270.976272 ER -