Aspect-Oriented Requirements Engineering David Schaefer, Joao Araujo, Isabel Brito, Awais Rashid, Claudia Mesquita

Problems How to identify aspects at the requirements level? –What is the relationship between aspects and non- functional requirements, constraints and concerns? How to model aspects at the requirements level? How to trace requirements level aspects through later development stages and during re- engineering? How to validate aspects identified at the requirements level?

Identifying Aspects (1) Solution 1: Model using viewpoints/use cases/scenarios/stakeholder concerns and then identify crosscutting requirements. + Exploit the power and potential of existing mechanisms - Scalability problems. Hard to observe crosscutting in the presence of a large number of viewpoints, use cases or scenarios. Int Easier to see the functional crosscutting against a base SOC Int Adapt existing techniques.

Identifying Aspects (2) Solution 2: Brainstorming without the modelling. + No effort required for initial structuring - You could be absolutely list: brainstormed! - You are bound to miss something Int You could find aspect you might not find using other techniques

Identifying Aspects (3) Solution 3: Look at global properties, non- functional requirements and constraints as they are potential aspects + Easier to spot Int Might not necessarily be global

Modelling Aspects (1) Solution 1: Extension of existing modelling mechanisms e.g. OO, FSM, Concern-based + Ride the power of existing techniques + Ease of integration with existing techniques, tools, etc. + Ease of learning - Inherit the shortcomings of existing techniques

Modelling Aspects (2) Solution 2: Express them as requirements affected by multiple concerns in a concern graph. The edges of the concern graph express satisfaction of requirements by certain other entities. + No modelling restrictions => greater flexibility - Difficult to integrate with other techniques - Higher maintenance costs Int Complex structure might make it difficult to identify an aspect

Traceability (1) Solution 1: Concern graph developed through stepwise concretisation of concerns. The leaves of the graph are the code and in between are other documents such as design. + Good traceability - Maintenance and scalability Int Development time is a question of evaluation in real world systems development

Traceability (2) Solution 2: Re-engineering: Tool to find aspects in your code. Some form of code mining and extract patterns of crosscutting. + Tool support - Effort to develop a tool Int Accuracy Solution 3: Guidelines for the mapping and influence of aspects to later stages perhaps influenced by domain analysis. + Early identification of traceability - Need really good guidelines otherwise mistakes are likely

Validation (1) Solution 1: Prototyping + Intensive participation of stakeholders at an early stage - Things can be missed Solution 2: Formal methods + Precision - Doesn’t mean it is correct - Hard to obtain input from stakeholders - Can be complicated an expensive

Validation (2) Solution 3: Domain analysis + Domain constraints taken into account - Hard to generalise Solution 4: Early architecture development (in parallel with requirements modelling) + Early exchange of information between architecture and requirements design Int Decision on architecture may be too early

Conclusion Need a systematic process to identify, model and validate concerns –Exploit existing mechanisms for backward compatibility, their existing user base and power –Scalability and traceability are critical –Validation is extremely important though hard to achieve –Domain analysis and stepwise development has an important role to play