Aspect-Oriented Requirements Engineering

1. Aspect-Oriented Requirements Engineering Incorporating AORE with ICSM and Agile Development Practices Cresta Kirkwood

2. A Quick Agile Refresher • Functional requirements are captured in user stories • A user story is meant to define the end-to-end functionality • But often times, certain functional and non-functional requirements cannot be separated

3. Agile Refresher (cont.) • Since non-functional requirements (NFR) are not captured… • It is difficult to fully reason about how NFR affects the system design, system architecture, and other requirements [1] • NFR may be integrated with functional requirements in later stages of development • Code Compromise [2] • Must consider cross-cutting concerns in early stages of development

4. Aspect-Oriented Requirements Engineering • With a composable set of requirements • Requirements and their relationships can be viewed together • Potential conflicts can be identified early • The team can identify when concerns are indeed crosscutting or whether they apply to a single capability [1] "Aspect-oriented requirements engineering techniques provide abstraction and composition mechanisms to separate crosscutting concerns and capture their interdependencies with other concerns through composition specifications”[3] – A. Rashid

5. AORE Processes AORE Process [4] AOREC Process [5] CORE Process [6]

6. Integrated AORE Process • Identify Concerns • Manage Concerns • Specify Concerns • Identify Crosscutting Concerns • Compose Concerns • Resolve Conflicts • Define Composition Rules • Repeat (if necessary) [7]

7. Integrating AORE into ICSM • Identify Concerns • Include a “System Quality” WinBook tag • Manage Concerns • Done! thanks to WinWin negotiation, Planning Poker, and the SSRD • Specify Concerns • Add a “System Qualities” tab to the SSRD where each row represents information like the following template Template to specify concerns (derived from [8])

8. Integrating AORE into ICSM (cont.) • Specify Concerns (cont.) • Capture functional and non-functional relationships in SSAD use case diagrams • Identify Crosscutting Concerns • Use “System Quality” SSRD tabs and SSAD use case diagrams Integrated UML Diagram [8]

9. Integrating AORE into ICSM (cont.) • Resolve Conflicts • Include a matrix in the SSRD that maps relationships between system qualities and requirements. • Use matrix along with priorities and contributions during stakeholder conflict resolution discussions. (See matrix and match point discussion in [8])

10. Integrating AORE into ICSM (cont.) • Define composition rules • Capture the relationships between system qualities and use cases in SSAD sequence diagrams Composing qualities with use cases [9]

11. Integrating AORE with Agile • Agile is flexible! Use the aforementioned techniques as much or as little as desired • But where can NFR be captured? • In their own user stories • Advantages: Homogeneity, understandability, visibility, helpful to business stakeholders • Disadvantages: Not as helpful to the development team, de-prioritization • In functional user story exit criteria • Advantages: Easy to capture and impossible to miss • Disadvantages: Estimation difficulties

12. Integrating AORE with Agile (cont.) • Where can NFR be captured? (cont.) • In “hidden” technical user stories • Advantages: No de-prioritization • Disadvantages: No visibility to user stakeholders. Some advise against using this technique [10]

13. Conclusions • Traditional requirements engineering techniques (including conventional, agile user stories) often fail to handle crosscutting concerns • AORE provides ways to document and trace cross-cutting concerns • Easier to reason about all functional and non-functional attributes of a system at the same time • Fewer risks of having “tangled specifications and code” [11] • Integrating AORE into ICSM means more documentation activities in Valuation and Foundations phases, but it may result in more comprehensive documentation • Integrating into Agile requires thought and may mean more documentation activities

14. References [1] A. Mohamed, A. Hegazy, A. Dawood, “Aspect Oriented Requirements Engineering”, Computer and Information Science (CCSECIS) 2010, 3(4):136. [2] A. Moreira, J. Araújo, and I. Brito, “Crosscutting Quality Attributes for Requirements Engineering”, SEKE, 2002, ACM, 167. [3] A. Rashid, “Aspect-Oriented Requirements Engineering: An Introduction,” IEEE International Conference on Requirements Engineering, vol. 0, pp. 306–309, September 2008. [4] A. Rashid, A. Moreira, and J. Araújo, “Modularisation and Composition of Aspectual Requirements,” Proc. 2nd Int’l Conf. Aspect-Oriented Software Development (AOSD 03), ACM Press, 2003, 12. [5] A. Mohamed, A. Hegazy, A. Dawood, “Aspect Oriented Requirements Engineering”, Computer and Information Science (CCSECIS) 2010, 3(4):152. [6] A. Moreira, J. Araújo, A. Rashid "A Concern-Oriented Requirements Engineering Model", Proc. CAiSE 2005, LNCS, Vol. 3520, pp 296. [7] N. Singh and N. Singh Gill. “Towards an Integrated AORE Process Model for Handling Crosscutting Concerns” International Journal of Computer Applications 37(3):18-24, January 2012. [8]I. Brito, and A. Moreira. “Towards a composition process for aspect-oriented requirements.” In: Proceedings of the Early-Aspects Workshop at AOSD2002, 2002 [9] A. Moreira, J. Araújo, and I. Brito, “Crosscutting Quality Attributes for Requirements Engineering”, SEKE, 2002, ACM, 172. [10] R. Davies (n.d.). Non-Functional Requirements: Do User Stories Really Help?. In Methods and Tools. Retrieved April 19, 2012, from http://www.methodsandtools.com/archive/archive.php?id=113 [11] A. Moreira, J. Araújo, and I. Brito, “Crosscutting Quality Attributes for Requirements Engineering”, SEKE, 2002, ACM, 173.