05 Making Tacit Requirements Explicit
- 1. Making Tacit Requirements Explict 1 Lancaster University 2 The Open University Gacitua, R. 1 , Ma, L. 2 , Nuseibeh, B. 2 , Piwek, P. 2 , de Roeck, A. 2 , Rouncefield, M. 1 , Sawyer, P. 1 , Willis, A. 2 and Yang, H. 2
- 2. Tacit knowledge Knowing more than we can tell ( Polanyi ) Tacit knowledge Explicit knowledge Some tacit knowledge may never be articul able Some articulated knowledge can, over time, become not articulated Not articulated Articulated Externalisation (Nonaka, Takeuchi and Umemoto )
- 3. Tacit Knowledge in RE We rely on tacit knowledge to communicate effectively There are practical limits to what we can elicit Yet as engineers, we’re taught to make our specification precise, explicit and complete
- 4. Tacit Knowledge in RE We need a workable definition of TK for RE Maiden and Rugg † distinguish between: Tacit knowledge essentially Polanyi’s knowledge acquired by a process of tacit knowing. Being able to enact the ‘performance’ not the same as being able to articulate what is known. Semi-tacit knowledge knowledge that is tractable to recovery using cues, e.g.: Menu items in a spreadsheet Taken-for-granted knowledge Concealed knowledge † Maiden, N, Rugg, G.: AC RE: selecting methods for requirements acquisition, Software Engineering Journal, 11 (3) May 1996.
- 5. Tacit Knowledge in RE Maybe because stakehodlers share cognitive TK Maybe because developers worked in this domain before Maybe because the analysts are creative Problem domain Req. spec n . Development Analysts Stakeholders Developers
- 6. Requirements discoverable. Requirements discovered. Stakeholder Semi-tacit Explicit Requirements discoverable. Requirements discoverable with difficulty. Requirements not discoverable. Tacit Analyst Knows domain New to domain Traditional techniques - e.g. interviews Indirect via observable phenomena in domain: ethnography in artifacts: MaTREx Discovery Active techniques - e.g. use cases, goal workshops, prototyping, modeling
- 7. Tracing requirements provenance Knowledge can be lost during the synthesis of requirements. Upstream tracing between sources and requirements important for understanding how and why user requirements formulated. Post-hoc recovery of trace links is typically necessary, but difficult.
- 8. PROSPECT
- 10. Where do unprovenanced requirements come from? Sources are lost Sources in non-text media Sources in peoples’ heads Analyst assumptions Symptom of missing domain knowledge? Symptom of tacit knowledge? Analyst invention ?
- 11. Concept identification with OntoLancs - the outer cycle Ensemble methods are compositions of “primitive” NLP techniques
- 12. Concept identification with OntoLancs - the inner cycle Assembly and evaluation of ensemble methods
- 15. Conclusions Our existing work on tracing requirements provenance turns out to have some relevance to identifying evidence for the presence of tacit knowledge. Now we want to see how to understand what effect that has in the downstream requirements. See how work from others in RE and from knowledge management, ontology engineering and organisational memory be used to better understand tacit knowledge and tacit requirements.