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.