Skip to main content
SpringerLink
Log in

Ambiguity and tacit knowledge in requirements elicitation interviews

  • RE 2015
  • Published:
Requirements Engineering Aims and scope Submit manuscript

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.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3
Fig. 4

Similar content being viewed by others

Notes

  1. Three professionals in different subfields, namely Bio-medical Devices, Heath-care Management and General Medicine.

  2. For example, one of the goals of the General Medicine domain is to provide treatments for the patients. A system whose goal is to support a physician in the diagnosis of a disease (as, e.g., in Example 3.3) only contributes to the domain goal of treating the patients. Satisfying this domain goal requires other sub-goals to be addressed (e.g., selecting medications), which are outside the scope of the system.

  3. Gervasi et al. [28] have i refer to the whole interview. Here, i is associated with the specific piece of the interview (i.e., the speech fragment) in which k is articulated.

  4. The speech fragment in this example could be seen as inconsistent with the commonsense knowledge of the analyst. However, deciding whether something is commonsense knowledge or domain knowledge is arguable. For this reason, we adopted the convention that any ambiguity that is driven by different views of the domain shall be apportioned to the domain knowledge dimension.

  5. We do not show the different sub-categories, to give evidence of the dominance of the domain component with respect to the other types of unclarity.

  6. This latter case is only speculative, since we were not able to see these cases in practice.

References

  1. Agarwal R, Tanniru MR (1990) Knowledge acquisition using structured interviewing: an empirical investigation. JMIS 7(1):123–140

    Google Scholar 

  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–134

  3. Ambriola V, Gervasi V (2006) On the systematic analysis of natural language requirements with Circe. ASE 13

  4. Aristotle (1984) On sophistical refutations. In: Barnes J (ed) The complete works of Aristotle: the revised Oxford translation. Princeton University Press, Princeton, New Jersey

  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–968

    Article  Google Scholar 

  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–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–44

  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–217

  9. Berry DM, Kamsties E (2005) The syntactically dangerous all and plural in specifications. IEEE Softw 22(1):55–57

    Article  Google Scholar 

  10. Berry DM, Kamsties E, Krieger MM (2003) From contract drafting to software specification: linguistic sources of ambiguity

  11. Browne GJ, Rogich MB (2001) An empirical investigation of user requirements elicitation: comparing the effectiveness of prompting techniques. JMIS 17(4):223–249

    Google Scholar 

  12. Chantree F, Nuseibeh B, Roeck AND, Willis A (2006) Identifying nocuous ambiguities in natural language requirements. In: RE’06, pp 56–65

  13. Cimatti A, Roveri M, Susi A, Tonetta S (2011) Formalizing requirements with object models and temporal constraints. SoSyM 10(2):147–160

    Google Scholar 

  14. Clark HH (1996) Using language. Cambridge University Press, Cambridge

    Book  Google Scholar 

  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–135

    Google Scholar 

  16. Coughlan J, Macredie RD (2002) Effective communication in requirements elicitation: a comparison of methodologies. Requir Eng 7(2):47–60

    Article  Google Scholar 

  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–188

  18. Distanont A, Haapasalo H, Vaananen M, Lehto J (2012) The engagement between knowledge transfer and requirements engineering. IJKL 1(2):131–156

    Google Scholar 

  19. Empson W (1966) Seven types of ambiguity. New Directions Paperbook, New York

    Google Scholar 

  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–38

  21. Ferrari A, Gnesi S (2012) Using collective intelligence to detect pragmatic ambiguities. In: RE’12. IEEE, pp 191–200

  22. Ferrari A, Lipari G, Gnesi S, Spagnolo GO (2014) Pragmatic ambiguity detection in natural language requirements. In: AIRE’14. IEEE, pp 1–8

  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–35

  24. Friedrich WR, Van Der Poll JA (2007) Towards a methodology to elicit tacit domain knowledge from users. IJIKM 2(1):179–193

    Google Scholar 

  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–44

  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

    Article  Google Scholar 

  27. Gause D, Weinberg G (1989) Exploring requirements: quality before design. Dorset House Pub

  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–47

  29. Gervasi V, Zowghi D (2005) Reasoning about inconsistencies in natural language requirements. ACM Trans Softw Eng Methodol 14(3):277–330

    Article  Google Scholar 

  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–232

  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. Glinz M, Fricker SA (2014) On shared understanding in software engineering: an essay. CSRD, pp 1–14

  33. Gnesi S, Lami G, Trentanni G (2005) An automatic tool for the analysis of natural language requirements. IJCSSE 20(1)

  34. Grant KA (2007) Tacit knowledge revisited—we can still learn from Polanyi. Electron J Knowl Manag 5(2):173–180

    MathSciNet  Google Scholar 

  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, 8pp

  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–159

    Article  Google Scholar 

  37. Harwell R, Aslaksen E, Mengot R, Hooks I, Ptack K (1993) What is a requirement? INCOSE Int Symp 3(1):17–24

    Google Scholar 

  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 Group

  39. Hickey AM, Davis AM (2004) A unified model of requirements elicitation. J Manag Inf Syst 20(4):65–84

    Google Scholar 

  40. Horvath JA (2000) Working with tacit knowledge. Knowl Manag Yearb 2000–2001:34–51

    Google Scholar 

  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–40

    Google Scholar 

  42. Kamsties E (2005) Understanding ambiguity in requirements engineering. In: Engineering and managing software requirements. Springer, Berlin, pp 245–266

  43. Karten N (2013) Managing expectations: working with people who want more, better, faster, sooner, Now! Addison-Wesley

  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–206

  45. Kof L (2010) From requirements documents to system models: a tool for interactive semi-automatic translation. In: RE’10

  46. Kogut B, Zander U (1992) Knowledge of the firm, combinative capabilities, and the replication of technology. Org Sci 3(3):383–397

    Article  Google Scholar 

  47. van Lamsweerde L (2009) Requirements engineering—from system goals to UML models to software specifications. Wiley, London

    Google Scholar 

  48. Maiden N, Rugg G (1996) ACRE: selecting methods for requirements acquisition. Softw Eng J 11(3):183–192

    Article  Google Scholar 

  49. Massey AK, Rutledge RL, Anton AI, Swire PP (2014) Identifying and classifying ambiguity for regulatory requirements. In: RE’14. IEEE, pp 83–92

  50. Mich L (1996) NL-OOPS: from natural language to object oriented requirements using the natural language processing system LOLITA. NLE 2(2):161–187

    Google Scholar 

  51. Mich L, Franch M, Inverardi PN (2004) Market research for requirements analysis using linguistic tools. Requir Eng 9(1):40–56

    Article  Google Scholar 

  52. Mich L, Garigliano R (2000) Ambiguity measures in requirements engineering. In: ICS’00, 16th IFIP WCC, pp 39–48

  53. Mühlhäusler P (1986) Pidgin and creole linguistics. Blackwell, Oxford

  54. Neumann PG (1986) Only his only grammarian can only say only what only he only means. ACM SIGSOFT SE Notes 9(1):6

    Google Scholar 

  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–190

  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–283

  57. Nonaka I (1991) The knowledge-creating company. Harvard Bus Rev 69(6):96–104

    Google Scholar 

  58. Osborne M, MacNish CK (1996) Processing natural language software requirement specifications. pp 229–236

  59. Pitts MG, Browne GJ (2004) Stopping behavior of systems analysts during information requirements elicitation. J Manag Inf Syst 21(1):203–226

    Google Scholar 

  60. Polanyi M (1966) The tacit dimension. Doubleday, Garden City

    Google Scholar 

  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–124

  62. Portugal S (2013) Interviewing users: how to uncover compelling details. Louis Rosenfeld

  63. Riege A (2005) Three-dozen knowledge-sharing barriers managers must consider. J Knowl Manag 9(3):18–35

    Article  Google Scholar 

  64. Robertson S, Robertson J (2012) Mastering the requirements process: getting requirements right. Addison-Wesley, Boston

    Google Scholar 

  65. Rugg G, McGeorge P, Maiden N (2000) Method fragments. Expert Syst 17(5):248–257

    Article  Google Scholar 

  66. Rupp C, Goetz R (2000) Linguistic methods of requirements-engineering (nlp). In: Proceedings of European software process improvement conference (EuroSPI)

  67. Ryan K (1993) The role of natural language in requirements engineering. In: Proceedings of IEEE international symposium on requirements engineering, 1993, pp 240–242

  68. Saiedian H, Dale R (2000) Requirements engineering: making the connection between the software developer and customer. Inf Softw Technol 42(6):419–428

    Article  Google Scholar 

  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–204

    Article  Google Scholar 

  70. Sennet A (2015) Ambiguity. In: Zalta EN (ed) The Stanford encyclopedia of philosophy, spring 2015 edition

  71. Shah US, Jinwala DC (2015) Resolving ambiguities in natural language software requirements: a comprehensive survey. SIGSOFT Softw Eng Notes 40(5):1–7

    Article  Google Scholar 

  72. Sirius Requirements: http://www.sirius-requirements.com

  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 Society

  74. Sommerville I, Sawyer P (1997) Viewpoints: principles, problems and a practical approach to requirements engineering. Ann Softw Eng 3(1):101–130

    Article  Google Scholar 

  75. Sutcliffe A, Sawyer P (2013) Requirements elicitation: towards the unknown unknowns. In: RE’13. IEEE, pp 92–104

  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–95

  77. Wilson WM, Rosenberg LH, Hyatt LE (1997) Automated analysis of requirement specifications. In: ICSE’97, pp 161–171

  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–34

  79. Yang H, Roeck AND, Gervasi V, Willis A, Nuseibeh B (2011) Analysing anaphoric ambiguity in natural language requirements. Requir Eng 16(3):163–189

    Article  Google Scholar 

  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–259

  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–46

  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–140

Download references

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.

Author information

Authors and Affiliations

  1. CNR-ISTI, Pisa, Italy

    Alessio Ferrari & Stefania Gnesi

  2. Kennesaw State University, Kennesaw, GA, USA

    Paola Spoletini

Authors
  1. Alessio Ferrari
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Paola Spoletini
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Stefania Gnesi
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Alessio Ferrari.

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Ferrari, A., Spoletini, P. & Gnesi, S. Ambiguity and tacit knowledge in requirements elicitation interviews. Requirements Eng 21, 333–355 (2016). https://doi.org/10.1007/s00766-016-0249-3

Download citation

  • Received:

  • Accepted:

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s00766-016-0249-3

Keywords

Search

Navigation