1. GOORE Method Engineering Presentation Sander Knape

2. AUTHORS GOORE: Goal-Oriented and Ontology Driven Requirements Elicitation Method (2007)  Authors: Masayuki Shibaoka, Haruhiko Kaiya and Motoshi Saeki

3. AUTHORS GOORE: Goal-Oriented and Ontology Driven Requirements Elicitation Method (2007)  Authors: Masayuki Shibaoka, Haruhiko Kaiya and Motoshi Saeki Gene Networks

4. AUTHORS GOORE: Goal-Oriented and Ontology Driven Requirements Elicitation Method (2007)  Authors: Masayuki Shibaoka, Haruhiko Kaiya and Motoshi Saeki AGORA Using domain-ontology for requirements engineering Semantic processing

5. AUTHORS GOORE: Goal-Oriented and Ontology Driven Requirements Elicitation Method (2007)  Authors: Masayuki Shibaoka, Haruhiko Kaiya and Motoshi Saeki Meta-modelling for situational method engineering (with Sjaak) AGORA (With Kaiya) Using domain-ontology for requirements engineering (With Kaiya) Gene networks (with Shibaoka)

6. AUTHORS GOORE: Goal-Oriented and Ontology Driven Requirements Elicitation Method (2007)  Authors: Masayuki Shibaoka, Haruhiko Kaiya and Motoshi Saeki Tokyo Institute of Technology Shinshu University

7. AUTHORS GOORE: Goal-Oriented and Ontology Driven Requirements Elicitation Method  Authors: Masayuki Shibaoka, Haruhiko Kaiya and Motoshi Saeki Tokyo Institute of Technology Shinshu University Japan

8. AUTHORS GOORE: Goal-Oriented and Ontology Driven Requirements Elicitation Method  Authors: Masayuki Shibaoka, Haruhiko Kaiya and Motoshi Saeki Tokyo Institute of Technology Shinshu University

9. GOORE  GOORE utilizes a domain ontology for requirements elicitation through goal-oriented modeling.

10. GOORE  GOORE utilizes a domain ontology for requirements elicitation through goal-oriented modeling.

11. GOORE  GOORE utilizes a domain ontology for requirements elicitation through goal-oriented modeling. 123

12. GOORE  GOORE utilizes a domain ontology for requirements elicitation through goal-oriented modeling. Requirements Elicitation  Elicitating requirements for software systems  Many projects with inadequate requirements  Hard – if not impossible – to list all requirements at the start  Many different methods exist  Social techniques (interviews, questionairres, introspection)  Technological methods (goal-oriented modeling) 1

13. GOORE  GOORE utilizes a domain ontology for requirements elicitation through goal-oriented modeling. Domain Ontology  Formally represented knowledge about a certain domain  Possible to do computational (e.g. morphological) analysis  Paper does not focus on creating or requiring a domain ontology  Will come back to this in related literature 2

14. GOORE  GOORE utilizes a domain ontology for requirements elicitation through goal-oriented modeling. Goal-oriented Modeling  User needs are modeled as goals (play/pause/stop song) within a Goal Graph  Tree-like structure: goals get more concrete with subgoals 3

15. PHASES 1. Set up goal graph and acquire domain ontology (requirements analyst) Initial Goal Graph 2. Find new goals (GOORE) List of suggested goals 3. Review goals (requirement analyst) Final Goal Graph

16. Review suggested goals, add viable goals to the goal graph and repeat step 2. If there are no viable goals, end the process Review Analyze current goal graph, find new goals based on relations within domain ontology Update Create intial goal graph and acquire domain ontology Initial PHASES Domain Ontology

17. EXAMPLE  Let’s create a simple calculator InitialUpdateReview

18. EXAMPLE  Acquire a “Calculator Ontology”  Add two initial goals: “the calculator can add numbers” and “copy to clipboard”  Deliverables: Ontology and Initial Goal Graph InitialUpdateReview By: Requirements Analyst

19. EXAMPLE  Parse the received goals through a morphological analyzer. E.g. convert “the calculator can add numbers” to “add numbers”  Map the goals to the domain ontology. We find the ‘addition’ concept within the ontology  Deduce new candidate goals based on the relations the ‘addition’ concept has with other concepts (the antonym is ‘substraction’) InitialUpdateReview By: GOORE

20. EXAMPLE InitialUpdateReview By: GOORE

21. EXAMPLE  Prioritize the found concepts based on the relations  Relation exampes: antonym, require, contradict, has-a  Suggest the list with concepts (not too much)  Deliverable: visual presentation of prioritized list of concepts InitialUpdateReview By: GOORE

22. EXAMPLE  Select concepts that are viable to be added to the goal graph (we can add ‘substraction’)  This new goal can also have interesting sub-goals, go back to the ‘update’ step and let GOORE suggest more concepts  If no viable concepts are suggested, end the process  Deliverable: Final Goal Graph InitialUpdateReview By: Requirements Analyst

23. RELATED LITERATURE  Requirements Elicitation  Social – interviews, questionairres (Goguen & Linde, 1992)  Technological – computational analysis  GOORE  AGORA (Kaiya, Horai, & Saeki, 2002)  KAOS (van Lamsweerde, Dardenne, Delcourt, & Dubisy, 1991)  Many technological methods only provide guidance to find new goals  GOORE automates this process, using the domain ontology

24. RELATED LITERATURE  Domain ontology  Formally specifies entities and relationships within a certain domain (Gruber, 1993)  Stems from the field of artificial intelligence and philosophy (Chandrasekaran, Josephson, & Benjamins, 1999; Noy & McGuinness, 2001).  The domain ontology can be considered as the weak part of the GOORE method  The paper does not focus on how to require such an ontology  Later papers attest this, they provide methods to;  More easily create a domain ontology (Omoronyia et al., 2010)  Make it possible to use existing ontologies (Gailly, España, Poels, and Pastor (2008)

25. PROCESS-DELIVERABLE DIAGRAM

27.  Phase 1: Acquire domain ontology and create initial goal graph

28. PROCESS-DELIVERABLE DIAGRAM  Phase 2: generate new goals

29. PROCESS-DELIVERABLE DIAGRAM  Phase 3: review goals and request new goals or end the process

30. REFERENCES  Goguen, J. A., & Linde, C. (1993, January). Techniques for requirements elicitation. In Proceedings of IEEE International Symposium on Requirements Engineering (pp. 152-164). IEEE.  Kaiya, H., Horai, H., & Saeki, M. (2002). AGORA: Attributed goal-oriented requirements analysis method. In IEEE Joint International Conference on Requirements Engineering, 2002. Proceedings. (pp. 13-22). IEEE.  van Lamsweerde, A., Dardenne, A., Delcourt, B., & Dubisy, F. (1991, March). The KAOS project: Knowledge acquisition in automated specification of software. In Proceedings AAAI Spring Symposium Series (pp. 59-62).  Gruber, T. R. (1993). A translation approach to portable ontology specifications. Knowledge acquisition, 5(2), 199-220.  Chandrasekaran, B., Josephson, J. R., & Benjamins, V. R. (1999). What are ontologies, and why do we need them?. Intelligent Systems and Their Applications, IEEE, 14(1), 20-26.  Noy, N. F., & McGuinness, D. L. (2001). Ontology development 101: A guide to creating your first ontology. http://liris.cnrs.fr/alain.mille/enseignements/Ecole_Centrale/What%20is%20an%20ontology%20 and%20why%20we%20need%20it.htm http://liris.cnrs.fr/alain.mille/enseignements/Ecole_Centrale/What%20is%20an%20ontology%20  Omoronyia, I., Sindre, G., Stålhane, T., Biffl, S., Moser, T., & Sunindyo, W. (2010). A domain ontology building process for guiding requirements elicitation. Requirements Engineering: Foundation for Software Quality, 188-202.  Gailly, F., España, S., Poels, G., & Pastor, O. (2008). Integrating business domain ontologies with early requirements modelling. Advances in Conceptual Modeling–Challenges and Opportunities, 282- 291.

31. QUESTIONS?