How to Complete Customer Requirements

Using Concept Expansion for Requirement Refinement
  • Michaela GeierhosEmail author
  • Frederik Simon Bäumer
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 9612)


One purpose of requirement refinement is that higher-level requirements have to be translated to something usable by developers. Since customer requirements are often written in natural language by end users, they lack precision, completeness and consistency. Although user stories are often used in the requirement elicitation process in order to describe the possibilities how to interact with the software, there is always something unspoken. Here, we present techniques how to automatically refine vague software descriptions. Thus, we can bridge the gap by first revising natural language utterances from higher-level to more detailed customer requirements, before functionality matters. We therefore focus on the resolution of semantically incomplete user-generated sentences (i.e. non-instantiated arguments of predicates) and provide ontology-based gap-filling suggestions how to complete unverbalized information in the user’s demand.


Requirement refinement Concept expansion Ontology-based instantiation of predicate-argument structure 



This work was partially supported by the German Research Foundation (DFG) within the Collaborative Research Centre On-The-Fly Computing (SFB 901).


  1. 1.
    Albayrak, Ö., Kurtoglu, H., Biaki, M.: Incomplete software requirements and assumptions made by software engineers. In: Proceedings of the 9th Asia-Pacific Software Engineering Conference, pp. 333–339, December 2009Google Scholar
  2. 2.
    Baker, C.F., Fillmore, C.J., Lowe, J.B.: The Berkeley FrameNet project. In: COLING-ACL 1998: Proceedings of the Conference, Montreal, pp. 86–90 (1998)Google Scholar
  3. 3.
    Clarke, J., Srikumar, V., Sammons, M., Roth, D.: An NLP curator (or: How I Learned to Stop Worrying and Love NLP Pipelines). In: Proceedings of the 8th International Conference on Language Resources and Evaluation (LREC’12), Istanbul, Turkey, pp. 3276–3283, 23–25 May 2012Google Scholar
  4. 4.
    Fatwanto, A.: Software requirements specification analysis using natural language processing technique. In: Proceedings of the International Conference on Quality in Research QiR 2013, Yogyakarta, pp. 105–110, June 2013Google Scholar
  5. 5.
    Ferrari, A., dell’Orletta, F., Spagnolo, G.O., Gnesi, S.: Measuring and improving the completeness of natural language requirements. In: Salinesi, C., van de Weerd, I. (eds.) REFSQ 2014. LNCS, vol. 8396, pp. 23–38. Springer, Heidelberg (2014)CrossRefGoogle Scholar
  6. 6.
    Firesmith, D.G.: Are your requirements complete? J. Object Technol. 4(2), 27–43 (2005)CrossRefGoogle Scholar
  7. 7.
    Geierhos, M., Schulze, S., Bäumer, F.S.: What did you mean? Facing the challenges of user-generated software requirements. In: Loiseau, S., Filipe, J., Duval, B., van den Herik, J. (eds.) Proceedings of the 7th International Conference on Agents and Artificial Intelligence. Special Session on Partiality, Underspecification, and Natural Language Processing (PUaNLP 2015), pp. 277–283. SCITEPRESS - Science and Technology Publications, Lissabon (2015)Google Scholar
  8. 8.
    Ghazarian, A.: A case study of defect introduction mechanisms. In: van Eck, P., Gordijn, J., Wieringa, R. (eds.) CAiSE 2009. LNCS, vol. 5565, pp. 156–170. Springer, Heidelberg (2009)CrossRefGoogle Scholar
  9. 9.
    Grande, M.: 100 Minuten für Anforderungsmanagement - Kompaktes Wissen nicht nur für Projektleiter und Entwickler. Springer, Wiesbaden (2011)Google Scholar
  10. 10.
    HSE. Out of control: why control systems go wrong and how to prevent failure. (2003). Accessed 14 Feb 2016
  11. 11.
    Hsia, P., Davis, A., Kung, D.: Status report: requirements engineering. IEEE Softw. 10(6), 75–79 (1993)CrossRefGoogle Scholar
  12. 12.
    IEEE. IEEE Std 830-1998 - Recommended practice for software requirements specifications. Institute of Electrical and Electronics Engineers, New York (1998)Google Scholar
  13. 13.
    Kaiya, H., Saeki, M.: Ontology based requirements analysis: lightweight semantic processing approach. In: Proceedings of the 5th International Conference on Quality Software, pp. 223–230, September 2005Google Scholar
  14. 14.
    Kaiya, H., Saeki, M.: Using domain ontology as domain knowledge for requirements elicitation. In: 14th IEEE International Requirements Engineering Conference, pp. 189–198, September 2006Google Scholar
  15. 15.
    Kamata, M.I., Tamai, T.: How does requirements quality relate to project success or failure? In: Proceedings of the 15th IEEE International Requirements Engineering Conference, pp. 69–78, October 2007Google Scholar
  16. 16.
    Körner, S.J.: RECAA - Werkzeugunterstützung in der Anforderungserhebung. PhD thesis, Karlsruher Institut für Technologie (KIT), Karlsruhe, February 2014Google Scholar
  17. 17.
    Menzel, I., Mueller, M., Gross, A., Doerr, J.: An experimental comparison regarding the completeness of functional requirements specifications. In: Proceedings of the 18th IEEE International Requirements Engineering Conference, pp. 15–24, September 2010Google Scholar
  18. 18.
    Miller, G.A.: WordNet: a lexical database for English. Commun. ACM 38(11), 39–41 (1995)CrossRefGoogle Scholar
  19. 19.
    Naeem, M., Heckel, R., Orejas, F., Hermann, F.: Incremental service composition based on partial matching of visual contracts. In: Rosenblum, D.S., Taentzer, G. (eds.) FASE 2010. LNCS, vol. 6013, pp. 123–138. Springer, Heidelberg (2010)CrossRefGoogle Scholar
  20. 20.
    Palmer, M., Gildea, D., Kingsbury, P.: The proposition bank: an annotated corpus of semantic roles. Comput. Linguist. 31(1), 71–106 (2005)CrossRefGoogle Scholar
  21. 21.
    Platenius, M.C.: Fuzzy service matching in on-the-fly computing. In: Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering, ESEC/FSE 2013, pp. 715–718. ACM, New York (2013)Google Scholar
  22. 22.
    Platenius, M.C., Arifulina, S., Petrlic, R., Schäfer, W.: Matching of incomplete service specifications exemplified by privacy policy matching. In: Ortiz, G., Tran, C. (eds.) ESOCC 2014. CCIS, vol. 508, pp. 6–17. Springer, Heidelberg (2015)Google Scholar
  23. 23.
    Saeki, M., Horai, H., Enomoto, H.: Software development process from natural language specification. In: Proceedings of the 11th International Conference on Software Engineering, ICSE 1989, pp. 64–73. ACM, New York (1989)Google Scholar
  24. 24.
    Sommerville, I.: Web Chapter 27: formal specification. (2009). Zuletzt abgerufen am 19 Aug 2015
  25. 25.
    Standish Group International. The CHAOS report (1994). (1995). Accessed 14 Feb 2016
  26. 26.
    Tichy, W.F., Landhäußer, M., Körner, S.J.: nlrpBENCH: a benchmark for natural language requirements processing. In: Multikonferenz Software Engineering & Management 2015, March 2015Google Scholar
  27. 27.
    Verma, K., Kass, A.: Requirements analysis tool: a tool for automatically analyzing software requirements documents. In: Sheth, A.P., Staab, S., Dean, M., Paolucci, M., Maynard, D., Finin, T., Thirunarayan, K. (eds.) ISWC 2008. LNCS, vol. 5318, pp. 751–763. Springer, Heidelberg (2008)CrossRefGoogle Scholar
  28. 28.
    Yadav, S.B., Bravoco, R.R., Chatfield, A.T., Rajkumar, T.M.: Comparison of analysis techniques for information requirement determination. Commun. ACM 31(9), 1090–1097 (1988)CrossRefGoogle Scholar

Copyright information

© Springer International Publishing Switzerland 2016

Authors and Affiliations

  1. 1.Heinz Nixdorf InstituteUniversity of PaderbornPaderbornGermany

Personalised recommendations