Advertisement

Requirements Engineering

, Volume 21, Issue 3, pp 333–355 | Cite as

Ambiguity and tacit knowledge in requirements elicitation interviews

  • Alessio Ferrari
  • Paola Spoletini
  • Stefania Gnesi
RE 2015

Abstract

Interviews are the most common and effective means to perform requirements elicitation and support knowledge transfer between a customer and a requirements analyst. Ambiguity in communication is often perceived as a major obstacle for knowledge transfer, which could lead to unclear and incomplete requirements documents. In this paper, we analyze the role of ambiguity in requirements elicitation interviews, when requirements are still tacit ideas to be surfaced. To study the phenomenon, we performed a set of 34 customer–analyst interviews. This experience was used as a baseline to define a framework to categorize ambiguity. The framework presents the notion of ambiguity as a class of four main sub-phenomena, namely unclarity, multiple understanding, incorrect disambiguation and correct disambiguation. We present examples of ambiguities from our interviews to illustrate the different categories, and we highlight the pragmatic components that determine the occurrence of ambiguity. Along the study, we discovered a peculiar relation between ambiguity and tacit knowledge in interviews. Tacit knowledge is the knowledge that a customer has but does not pass to the analyst for any reason. From our experience, we have discovered that, rather than an obstacle, the occurrence of an ambiguity is often a resource for discovering tacit knowledge. Again, examples are presented from our interviews to support this vision.

Keywords

Requirements engineering Requirements elicitation  Interviews Ambiguity Natural language 

Notes

Acknowledgments

The authors would like to thank Daniel M. Berry for his precious recommendations and all the anonymous reviewers who helped improving this paper. This work was partially supported by the LearnPAd FP7-ICT-2013.8.2 European Project.

References

  1. 1.
    Agarwal R, Tanniru MR (1990) Knowledge acquisition using structured interviewing: an empirical investigation. JMIS 7(1):123–140Google Scholar
  2. 2.
    Alves CF, Pereira S, Valença G, Pimentel J, de Andrade RV (2007) Preliminary results from an empirical study in market-driven software companies. In: WER’07, pp 127–134Google Scholar
  3. 3.
    Ambriola V, Gervasi V (2006) On the systematic analysis of natural language requirements with Circe. ASE 13Google Scholar
  4. 4.
    Aristotle (1984) On sophistical refutations. In: Barnes J (ed) The complete works of Aristotle: the revised Oxford translation. Princeton University Press, Princeton, New JerseyGoogle Scholar
  5. 5.
    Arora C, Sabetzadeh M, Briand L, Zimmer F (2015) Automated checking of conformance to requirements templates using natural language processing. IEEE Trans Softw Eng 41(10):944–968CrossRefGoogle Scholar
  6. 6.
    Berry D (2008) Ambiguity in natural language requirements documents. In: Paech B, Martell C (eds) Innovations for requirement analysis. From stakeholders needs to formal designs, LNCS, vol 5320. Springer, Berlin, pp 1–7Google Scholar
  7. 7.
    Berry D, Kamsties E (2004) Ambiguity in requirements specification. In: Sampaio do Prado Leite JC, Doorn JH (eds) Perspectives on software requirements. The Springer International Series in engineering and computer science, vol 753. Springer, New York, pp 7–44Google Scholar
  8. 8.
    Berry DM, Gacitua R, Sawyer P, Tjong SF (2012) The case for dumb requirements engineering tools. In: Regnell B, Damian D (eds) REFSQ, LNCS, vol 7195. Springer, pp 211–217Google Scholar
  9. 9.
    Berry DM, Kamsties E (2005) The syntactically dangerous all and plural in specifications. IEEE Softw 22(1):55–57CrossRefGoogle Scholar
  10. 10.
    Berry DM, Kamsties E, Krieger MM (2003) From contract drafting to software specification: linguistic sources of ambiguityGoogle Scholar
  11. 11.
    Browne GJ, Rogich MB (2001) An empirical investigation of user requirements elicitation: comparing the effectiveness of prompting techniques. JMIS 17(4):223–249Google Scholar
  12. 12.
    Chantree F, Nuseibeh B, Roeck AND, Willis A (2006) Identifying nocuous ambiguities in natural language requirements. In: RE’06, pp 56–65Google Scholar
  13. 13.
    Cimatti A, Roveri M, Susi A, Tonetta S (2011) Formalizing requirements with object models and temporal constraints. SoSyM 10(2):147–160Google Scholar
  14. 14.
    Clark HH (1996) Using language. Cambridge University Press, CambridgeCrossRefGoogle Scholar
  15. 15.
    Corvera Charaf M, Rosenkranz C, Holten R (2013) The emergence of shared understanding: applying functional pragmatics to study the requirements development process. ISJ 23(2):115–135Google Scholar
  16. 16.
    Coughlan J, Macredie RD (2002) Effective communication in requirements elicitation: a comparison of methodologies. Requir Eng 7(2):47–60CrossRefGoogle Scholar
  17. 17.
    Davis A, Dieste O, Hickey A, Juristo N, Moreno AM (2006) Effectiveness of requirements elicitation techniques: empirical results derived from a systematic review. In: RE’06. IEEE, pp 179–188Google Scholar
  18. 18.
    Distanont A, Haapasalo H, Vaananen M, Lehto J (2012) The engagement between knowledge transfer and requirements engineering. IJKL 1(2):131–156Google Scholar
  19. 19.
    Empson W (1966) Seven types of ambiguity. New Directions Paperbook, New YorkGoogle Scholar
  20. 20.
    Ferrari A, dell’Orletta F, Spagnolo GO, Gnesi S (2014) Measuring and improving the completeness of natural language requirements. In: REFSQ’14, LNCS, vol 8396. Springer, pp 23–38Google Scholar
  21. 21.
    Ferrari A, Gnesi S (2012) Using collective intelligence to detect pragmatic ambiguities. In: RE’12. IEEE, pp 191–200Google Scholar
  22. 22.
    Ferrari A, Lipari G, Gnesi S, Spagnolo GO (2014) Pragmatic ambiguity detection in natural language requirements. In: AIRE’14. IEEE, pp 1–8Google Scholar
  23. 23.
    Ferrari A, Spoletini P, Gnesi S (2015) Ambiguity as a resource to disclose tacit knowledge. In: 2015 23rd IEEE international requirements engineering conference (RE). IEEE, pp 26–35Google Scholar
  24. 24.
    Friedrich WR, Van Der Poll JA (2007) Towards a methodology to elicit tacit domain knowledge from users. IJIKM 2(1):179–193Google Scholar
  25. 25.
    Gacitua R, Ma L, Nuseibeh B, Piwek P, De Roeck A, Rouncefield M, Sawyer P, Willis A, Yang H (2009) Making tacit requirements explicit. In: MARK’09. IEEE, pp 40–44Google Scholar
  26. 26.
    Gacitua R, Sawyer P, Gervasi V (2011) Relevance-based abstraction identification: technique and evaluation. Requir Eng 16(3):251–265. doi: 10.1007/s00766-011-0122-3 CrossRefGoogle Scholar
  27. 27.
    Gause D, Weinberg G (1989) Exploring requirements: quality before design. Dorset House PubGoogle Scholar
  28. 28.
    Gervasi V, Gacitua R, Rouncefield M, Sawyer P, Kof L, Ma L, Piwek P, De Roeck A, Willis A, Yang H et al (2013) Unpacking tacit knowledge for requirements engineering. In: Maalej W, Thurimella AK (eds) Managing requirements knowledge. Springer, pp 23–47Google Scholar
  29. 29.
    Gervasi V, Zowghi D (2005) Reasoning about inconsistencies in natural language requirements. ACM Trans Softw Eng Methodol 14(3):277–330CrossRefGoogle Scholar
  30. 30.
    Gleich B, Creighton O, Kof L (2010) Ambiguity detection: towards a tool explaining ambiguity sources. In: REFSQ’10, LNCS, vol 6182. Springer, pp 218–232Google Scholar
  31. 31.
    Gleich B, Creighton O, Kof L (2010) Ambiguity detection: towards a tool explaining ambiguity sources. In: Requirements engineering: foundation for software quality. Lecture notes in computer science, vol 6182. Springer, Berlin, pp 218–232. http://dx.doi.org/10.1007/978-3-642-14192-8_20
  32. 32.
    Glinz M, Fricker SA (2014) On shared understanding in software engineering: an essay. CSRD, pp 1–14Google Scholar
  33. 33.
    Gnesi S, Lami G, Trentanni G (2005) An automatic tool for the analysis of natural language requirements. IJCSSE 20(1)Google Scholar
  34. 34.
    Grant KA (2007) Tacit knowledge revisited—we can still learn from Polanyi. Electron J Knowl Manag 5(2):173–180MathSciNetGoogle Scholar
  35. 35.
    Grunbacher P, Briggs RO (2001) Surfacing tacit knowledge in requirements negotiation: experiences using easywinwin. In: Proceedings of the 34th annual Hawaii international conference on system sciences, 2001. IEEE, 8ppGoogle Scholar
  36. 36.
    Hadar I, Soffer P, Kenzi K (2014) The role of domain knowledge in requirements elicitation via interviews: an exploratory study. Requir Eng 19(2):143–159CrossRefGoogle Scholar
  37. 37.
    Harwell R, Aslaksen E, Mengot R, Hooks I, Ptack K (1993) What is a requirement? INCOSE Int Symp 3(1):17–24Google Scholar
  38. 38.
    Hay D, Healy KA, Hall J et al (2000) Defining business rules—What are they really? Technical report Rev 1.3, the Business Rules GroupGoogle Scholar
  39. 39.
    Hickey AM, Davis AM (2004) A unified model of requirements elicitation. J Manag Inf Syst 20(4):65–84Google Scholar
  40. 40.
    Horvath JA (2000) Working with tacit knowledge. Knowl Manag Yearb 2000–2001:34–51Google Scholar
  41. 41.
    Ide N, Véronis J (1998) Introduction to the special issue on word sense disambiguation: the state of the art. Comput Linguist 24(1):2–40Google Scholar
  42. 42.
    Kamsties E (2005) Understanding ambiguity in requirements engineering. In: Engineering and managing software requirements. Springer, Berlin, pp 245–266Google Scholar
  43. 43.
    Karten N (2013) Managing expectations: working with people who want more, better, faster, sooner, Now! Addison-WesleyGoogle Scholar
  44. 44.
    Kiyavitskaya N, Zeni N, Mich L, Berry DM (2007) Requirements for tools for ambiguity identification and measurement in natural language requirements specifications. In: WER’07, pp 197–206Google Scholar
  45. 45.
    Kof L (2010) From requirements documents to system models: a tool for interactive semi-automatic translation. In: RE’10Google Scholar
  46. 46.
    Kogut B, Zander U (1992) Knowledge of the firm, combinative capabilities, and the replication of technology. Org Sci 3(3):383–397CrossRefGoogle Scholar
  47. 47.
    van Lamsweerde L (2009) Requirements engineering—from system goals to UML models to software specifications. Wiley, LondonGoogle Scholar
  48. 48.
    Maiden N, Rugg G (1996) ACRE: selecting methods for requirements acquisition. Softw Eng J 11(3):183–192CrossRefGoogle Scholar
  49. 49.
    Massey AK, Rutledge RL, Anton AI, Swire PP (2014) Identifying and classifying ambiguity for regulatory requirements. In: RE’14. IEEE, pp 83–92Google Scholar
  50. 50.
    Mich L (1996) NL-OOPS: from natural language to object oriented requirements using the natural language processing system LOLITA. NLE 2(2):161–187Google Scholar
  51. 51.
    Mich L, Franch M, Inverardi PN (2004) Market research for requirements analysis using linguistic tools. Requir Eng 9(1):40–56CrossRefGoogle Scholar
  52. 52.
    Mich L, Garigliano R (2000) Ambiguity measures in requirements engineering. In: ICS’00, 16th IFIP WCC, pp 39–48Google Scholar
  53. 53.
    Mühlhäusler P (1986) Pidgin and creole linguistics. Blackwell, OxfordGoogle Scholar
  54. 54.
    Neumann PG (1986) Only his only grammarian can only say only what only he only means. ACM SIGSOFT SE Notes 9(1):6Google Scholar
  55. 55.
    Niknafs A, Berry DM (2012) The impact of domain knowledge on the effectiveness of requirements idea generation during requirements elicitation. In: 2012 20th IEEE international requirements engineering conference (RE). IEEE, pp 181–190Google Scholar
  56. 56.
    Niknafs A, Berry DM (2013) An industrial case study of the impact of domain ignorance on the effectiveness of requirements idea generation during requirements elicitation. In: 2013 21st IEEE international requirements engineering conference (RE). IEEE, pp 279–283Google Scholar
  57. 57.
    Nonaka I (1991) The knowledge-creating company. Harvard Bus Rev 69(6):96–104Google Scholar
  58. 58.
    Osborne M, MacNish CK (1996) Processing natural language software requirement specifications. pp 229–236Google Scholar
  59. 59.
    Pitts MG, Browne GJ (2004) Stopping behavior of systems analysts during information requirements elicitation. J Manag Inf Syst 21(1):203–226Google Scholar
  60. 60.
    Polanyi M (1966) The tacit dimension. Doubleday, Garden CityGoogle Scholar
  61. 61.
    Popescu D, Rugaber S, Medvidovic N, Berry D (2008) Reducing ambiguities in requirements specifications via automatically created object-oriented models. In: Innovations for requirement analysis. From stakeholders needs to formal designs, lecture notes in computer science, vol 5320. Springer, Berlin, pp 103–124Google Scholar
  62. 62.
    Portugal S (2013) Interviewing users: how to uncover compelling details. Louis RosenfeldGoogle Scholar
  63. 63.
    Riege A (2005) Three-dozen knowledge-sharing barriers managers must consider. J Knowl Manag 9(3):18–35CrossRefGoogle Scholar
  64. 64.
    Robertson S, Robertson J (2012) Mastering the requirements process: getting requirements right. Addison-Wesley, BostonGoogle Scholar
  65. 65.
    Rugg G, McGeorge P, Maiden N (2000) Method fragments. Expert Syst 17(5):248–257CrossRefGoogle Scholar
  66. 66.
    Rupp C, Goetz R (2000) Linguistic methods of requirements-engineering (nlp). In: Proceedings of European software process improvement conference (EuroSPI)Google Scholar
  67. 67.
    Ryan K (1993) The role of natural language in requirements engineering. In: Proceedings of IEEE international symposium on requirements engineering, 1993, pp 240–242Google Scholar
  68. 68.
    Saiedian H, Dale R (2000) Requirements engineering: making the connection between the software developer and customer. Inf Softw Technol 42(6):419–428CrossRefGoogle Scholar
  69. 69.
    Schneider GM, Martin J, Tsai WT (1992) An experimental study of fault detection in user requirements documents. ACM Trans Softw Eng Methodol 1(2):188–204CrossRefGoogle Scholar
  70. 70.
    Sennet A (2015) Ambiguity. In: Zalta EN (ed) The Stanford encyclopedia of philosophy, spring 2015 editionGoogle Scholar
  71. 71.
    Shah US, Jinwala DC (2015) Resolving ambiguities in natural language software requirements: a comprehensive survey. SIGSOFT Softw Eng Notes 40(5):1–7CrossRefGoogle Scholar
  72. 72.
  73. 73.
    Software Engineering Technology Committee and Institute of Electrical and Electronics Engineers (1994) IEEE recommended practice for software requirements specifications. IEEE Std 830-1998. Institute of Electrical and Electronics Engineers. IEEE Computer SocietyGoogle Scholar
  74. 74.
    Sommerville I, Sawyer P (1997) Viewpoints: principles, problems and a practical approach to requirements engineering. Ann Softw Eng 3(1):101–130CrossRefGoogle Scholar
  75. 75.
    Sutcliffe A, Sawyer P (2013) Requirements elicitation: towards the unknown unknowns. In: RE’13. IEEE, pp 92–104Google Scholar
  76. 76.
    Tjong S, Berry D (2013) The design of SREE a prototype potential ambiguity finder for requirements specifications and lessons learned. In: Doerr J, Opdahl A (eds) Requirements engineering: foundation for software quality, lecture notes in computer science, vol 7830. Springer, Berlin, pp 80–95Google Scholar
  77. 77.
    Wilson WM, Rosenberg LH, Hyatt LE (1997) Automated analysis of requirement specifications. In: ICSE’97, pp 161–171Google Scholar
  78. 78.
    Yang H, De Roeck A, Gervasi V, Willis A, Nuseibeh B (2010) Extending nocuous ambiguity analysis for anaphora in natural language requirements. In: RE’10. IEEE, pp 25–34Google Scholar
  79. 79.
    Yang H, Roeck AND, Gervasi V, Willis A, Nuseibeh B (2011) Analysing anaphoric ambiguity in natural language requirements. Requir Eng 16(3):163–189CrossRefGoogle Scholar
  80. 80.
    Zhang Z, Thanisch P, Nummenmaa J, Ma J (2014) Detecting missing requirements in conceptual models. In: Dregvaite G, Damasevicius R (eds) Information and software technologies. Springer, Berlin, pp 248–259Google Scholar
  81. 81.
    Zowghi D, Coulin C (2005) Requirements elicitation: a survey of techniques, approaches, and tools. In: Engineering and managing software requirements. Springer, Berlin, pp 19–46Google Scholar
  82. 82.
    Zowghi D, Gervasi V, McRae A (2001) Using default reasoning to discover inconsistencies in natural language requirements. In: APSEC 2001 eighth Asia-Pacific software engineering conference, 2001, pp 133–140Google Scholar

Copyright information

© Springer-Verlag London 2016

Authors and Affiliations

  • Alessio Ferrari
    • 1
  • Paola Spoletini
    • 2
  • Stefania Gnesi
    • 1
  1. 1.CNR-ISTIPisaItaly
  2. 2.Kennesaw State UniversityKennesawUSA

Personalised recommendations