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.