Aspect-Oriented Requirements Engineering

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

2. 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?

3. 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.

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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