After Aspect Oriented Programming (AOP) became popular, people started to think about Aspect Oriented Requirements Engineering (AORE).Â Kaindl published a neat article trying to figure out what exactly was meant by that. Amongst other things, he points out that there is confusion about whether "Aspect" is meant as a synonym for crosscutting concern or a solution to it (in his opinion, the first doesn’t make much sense, and I agree; even the secion he doesn’t like to much, but the term is established, and we’re stuck with it now).
So Aspects solve cross-cutting concerns; in Software Development, typicall cross-cutting concerns are authorization, authentication, transaction management and more.Â Aspects provide a means to modularize these concerns.
Kaindl points out that almost always there is the hidden assumption that crosscutting concerns in software are the same as crosscutting concerns in requirements – but there is no foundation for that assumption!Â In fact, I would consider this a dangerous assumption.
So where does that leave us? Kaindl’s point is that we should avoid falling into the trap that cross-cutting concerns in requirements are not necessarily the same as in software.Â But what are the cross-cutting concerns in requirements?Â That’s a question that needs more research, but I am sure that it depends on the representation of the requirements, amongst other things.Â In a plain text specification, every entity (noun) or every action (verb) could be considered a cross-cutting concern.Â Consider a specification for a simple traffic light.Â Many requirements may refer to the same,Â traffic light in the specification.Â In the specification, the traffic light is a crosscutting concern.Â But not in the implementation – there, the traffic light may be one neatly capsuled object.Â Other representations don’t have this problem.Â KAOS, for instance, explicitly models objects.
Food for thought.