Ontology-Driven Guidance for Requirements Elicitation

  • Stefan Farfeleder
  • Thomas Moser
  • Andreas Krall
  • Tor Stålhane
  • Inah Omoronyia
  • Herbert Zojer
Part of the Lecture Notes in Computer Science book series (LNCS, volume 6644)


Requirements managers aim at keeping their sets of requirements well-defined, consistent and up to date throughout a project’s life cycle. Semantic web technologies have found many valuable applications in the field of requirements engineering, with most of them focusing on requirements analysis. However the usability of results originating from such requirements analyses strongly depends on the quality of the original requirements, which often are defined using natural language expressions without meaningful structures. In this work we present the prototypic implementation of a semantic guidance system used to assist requirements engineers with capturing requirements using a semi-formal representation. The semantic guidance system uses concepts, relations and axioms of a domain ontology to provide a list of suggestions the requirements engineer can build on to define requirements. The semantic guidance system is evaluated based on a domain ontology and a set of requirements from the aerospace domain. The evaluation results show that the semantic guidance system effectively supports requirements engineers in defining well-structured requirements.


requirements elicitation domain ontology elicitation guidance requirements engineering 


  1. 1.
    IEEE Recommended Practice for Software Requirements Specifications. IEEE Std 830 (1998)Google Scholar
  2. 2.
    OWL 2 Web Ontology Language Direct Semantics. Tech. rep., W3C (2009),
  3. 3.
    Cobleigh, R., Avrunin, G., Clarke, L.: User Guidance for Creating Precise and Accessible Property Specifications. In: 14th International Symposium on Foundations of Software Engineering, pp. 208–218. ACM, New York (2006)Google Scholar
  4. 4.
    Denger, C., Berry, D., Kamsties, E.: Higher Quality Requirements Specifications through Natural Language Patterns. In: 2003 IEEE International Conference on Software - Science, Technology and Engineering, pp. 80–90. IEEE, Los Alamitos (2003)Google Scholar
  5. 5.
    Egyed, A., Grunbacher, P.: Identifying Requirements Conflicts and Cooperation: How Quality Attributes and Automated Traceability Can Help. IEEE Software 21(6), 50–58 (2004)CrossRefGoogle Scholar
  6. 6.
    Elazhary, H.H.: REAS: An Interactive Semi-Automated System for Software Requirements Elicitation Assistance. IJEST 2(5), 957–961 (2010)Google Scholar
  7. 7.
    Gotel, O., Finkelstein, C.: An Analysis of the Requirements Traceability Problem. In: 1st International Conference on Requirements Engineering, pp. 94–101 (1994)Google Scholar
  8. 8.
    Gottesdiener, E.: Requirements by Collaboration: Workshops for Defining Needs. Addison-Wesley, Reading (2002)Google Scholar
  9. 9.
    Hull, E., Jackson, K., Dick, J.: Requirements Engineering. Springer, Heidelberg (2005)zbMATHGoogle Scholar
  10. 10.
    Ibrahim, N., Kadir, W., Deris, S.: Propagating Requirement Change into Software High Level Designs towards Resilient Software Evolution. In: 16th Asia-Pacific Software Engineering Conference, pp. 347–354. IEEE, Los Alamitos (2009)Google Scholar
  11. 11.
    Jackson, J.: A Keyphrase Based Traceability Scheme. IEEE Colloquium on Tools and Techniques for Maintaining Traceability During Design, 2/1–2/4 (1991)Google Scholar
  12. 12.
    Kaindl, H.: The Missing Link in Requirements Engineering. Software Engineering Notes 18, 30–39 (1993)CrossRefGoogle Scholar
  13. 13.
    Kaiya, H., Saeki, M.: Ontology Based Requirements Analysis: Lightweight Semantic Processing Approach. In: 5th Int. Conf. on Quality Software, pp. 223–230 (2005)Google Scholar
  14. 14.
    Kitamura, M., Hasegawa, R., Kaiya, H., Saeki, M.: A Supporting Tool for Requirements Elicitation Using a Domain Ontology. Software and Data Technologies, 128–140 (2009)Google Scholar
  15. 15.
    Kotonya, G., Sommerville, I.: Requirements Engineering. John Wiley & Sons, Chichester (1998)Google Scholar
  16. 16.
    Matsuo, Y., Ogasawara, K., Ohnishi, A.: Automatic Transformation of Organization of Software Requirements Specifications. In: 4th International Conference on Research Challenges in Information Science, pp. 269–278. IEEE, Los Alamitos (2010)Google Scholar
  17. 17.
    Omoronyia, I., Sindre, G., Stålhane, T., Biffl, S., Moser, T., Sunindyo, W.: A Domain Ontology Building Process for Guiding Requirements Elicitation. In: 16th REFSQ, pp. 188–202 (2010)Google Scholar
  18. 18.
    Pedrinaci, C., Domingue, J., Alves de Medeiros, A.K.: A Core Ontology for Business Process Analysis. In: Bechhofer, S., Hauswirth, M., Hoffmann, J., Koubarakis, M. (eds.) ESWC 2008. LNCS, vol. 5021, pp. 49–64. Springer, Heidelberg (2008)CrossRefGoogle Scholar
  19. 19.
    Rupp, C.: Requirements-Engineering und -Management. Hanser (2002)Google Scholar
  20. 20.
    Ståhane, T., Omoronyia, I., Reichenbach, F.: Ontology-Guided Requirements and Safety Analysis. In: 6th International Conference on Safety of Industrial Automated Systems (2010)Google Scholar
  21. 21.
    Watkins, R., Neal, M.: Why and How of Requirements Tracing. IEEE Software 11(4), 104–106 (1994)CrossRefGoogle Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2011

Authors and Affiliations

  • Stefan Farfeleder
    • 1
  • Thomas Moser
    • 2
  • Andreas Krall
    • 1
  • Tor Stålhane
    • 3
  • Inah Omoronyia
    • 4
  • Herbert Zojer
    • 5
  1. 1.Institute of Computer LanguagesVienna University of TechnologyAustria
  2. 2.Christian Doppler Laboratory “Software Engineering Integration for Flexible Automation Systems”Vienna University of TechnologyAustria
  3. 3.Department of Computer and Information ScienceNorwegian University of Science and TechnologyNorway
  4. 4.Irish Software Engineering Research CentreUniversity of LimerickIreland
  5. 5.Infineon TechnologiesAustria

Personalised recommendations