**3.1. Knowledge transfer and transformation process**

The knowledge transfer process is carried out when the knowledge of a person is transformed into natural language, and in non-verbal channels of human communication in order to be transferred to another person, who then decodes this knowledge according to their own interpretation. Any transfer of knowledge is inherently bound to acknowledge transformation, so there will always be some degree of ambiguity. Ambiguity affects the elicitation of correct requirements because people involved in the project could build different and possibly incompatible interpretations of the concepts, relations and processes of the domain. Linguists point to several sources of ambiguity such as lexical, syntactic, semantic and pragmatic. ISD produce an additional kind of ambiguity named nocuous when two people mutually ignore that they have their own different interpretation. In this situation, they end up talking about different concepts while they think that they are talking about the same topic. According to Gacitua et al. [18], any person involved in the process can be aware of this phenomenon, because they do not have access to the tacit knowledge of each other.

### **3.2. Conversion of tacit knowledge to explicit**

Nonaka and Takeuchi [7] propose a model of conversion of knowledge in organizations based on Polany's theory of tacit knowledge. For them, knowledge creation in an organization is the result of social interaction where tacit and explicit knowledge is transferred. The model postulates four iterative conversion modes such as socialization, externalization, combination and internalization (SECI) which are described as follows:


According to Nonaka, if this cycle is done consciously, looping through this knowledge spiral may evolve the overall knowledge held collectively. The spiral of knowledge can be applied to requirements elicitation in order to face the inherent knowledge management challenges of the process. Despite that, we found just a few researches that explore this possibility. Wan et al. [21] proposed a model of knowledge conversion to the requirements elicitation process with the aim to minimize the symmetry of ignorance between developers and domain specialists. The authors base their model on the SECI model and consider the knowledge flowing between domain specialists and developers. They introduced a new agent in the process: the *requirements specialist*. This person would act as an intermediary between the domain specialists and the developers, so he or she must earn the trust of those involved in the process. The authors use their model to analyse a requirements elicitation process of a real software development project. In conclusion, the authors argue that the proposed model can reduce the symmetry of ignorance and facilitate the elicitation of tacit requirements. Nevertheless, to be successful in the process they suggest that the requirement specialists must have enough domain knowledge. We consider that it is difficult, if not impossible, that a person knows about every domain, so the incorporation of this new agent could hinder the, complex by itself, elicitation process. On other hand, Vásquez-Bravo et al. [22] proposed a classification of elicitation techniques to facilitate their selection in an RE process based on the phases of Nonaka's model. However, they do not propose how to use these techniques and how to elicit tacit knowledge.

### **3.3. Knowledge sharing**

In order to implement the knowledge spiral property, it is crucial to facilitate the exchange of knowledge among all involved in the project [16]. It implies focusing on the knowledge holders, especially in ISD where knowledge is mostly tacit. This task may become difficult to handle because requirements engineers can be confronted with several persons whom they do not know. KM offers the concept of knowledge map [5], an artefact that points to knowledge but does not contain it. The artefact could be a table or a matrix indicating which person has what knowledge. The knowledge map should be created and initialized at the beginning of the process and continually be updated as the spiral of knowledge evolves. A knowledge map is also useful to discover for which knowledge a knowledge holder might be missing. In ISD, we assume that a knowledge map would also be useful for indicating the tacitness level of the knowledge holders. Thus, we propose the piece of knowledge (PoK) matrix, an artefact to fulfil the functions mentioned above and to be used in the KMoS-RE© strategy.

The PoK matrix is a data structure that stores the relation of every individual (solution solver or domain specialist) involved in the project with every piece of knowledge about the domain. A piece of knowledge can be a concept, a relationship or behaviour. The PoK matrix is used as a reference to figure out which concepts, relationships or behaviours had been made explicit and which of them remain tacit. The aim of the KMoS-RE© strategy is to look for the transformation, from 0 to 1, of the most possible values in the PoK matrix. This is in order to make explicit the most possible quantity of tacit knowledge. It would be ideal if the requirements engineers could make explicit all pieces of knowledge. However, there will always be knowledge that it cannot be converted to explicit; therefore, the requirements engineers must propose the most suitable solution with the explicit knowledge obtained at a particular moment.

## **3.4. Knowledge evolution spiral**

the result of social interaction where tacit and explicit knowledge is transferred. The model postulates four iterative conversion modes such as socialization, externalization, combination

• **Socialization** is the process of transferring tacit knowledge among individuals by sharing

• **Externalization** is the process of converting tacit knowledge to explicit through the devel-

• **Combination** is the process of recombining or reconfiguring existing bodies of explicit

• **Internalization** is the process of learning by repetition of tasks that apply explicit knowl-

According to Nonaka, if this cycle is done consciously, looping through this knowledge spiral may evolve the overall knowledge held collectively. The spiral of knowledge can be applied to requirements elicitation in order to face the inherent knowledge management challenges of the process. Despite that, we found just a few researches that explore this possibility. Wan et al. [21] proposed a model of knowledge conversion to the requirements elicitation process with the aim to minimize the symmetry of ignorance between developers and domain specialists. The authors base their model on the SECI model and consider the knowledge flowing between domain specialists and developers. They introduced a new agent in the process: the *requirements specialist*. This person would act as an intermediary between the domain specialists and the developers, so he or she must earn the trust of those involved in the process. The authors use their model to analyse a requirements elicitation process of a real software development project. In conclusion, the authors argue that the proposed model can reduce the symmetry of ignorance and facilitate the elicitation of tacit requirements. Nevertheless, to be successful in the process they suggest that the requirement specialists must have enough domain knowledge. We consider that it is difficult, if not impossible, that a person knows about every domain, so the incorporation of this new agent could hinder the, complex by itself, elicitation process. On other hand, Vásquez-Bravo et al. [22] proposed a classification of elicitation techniques to facilitate their selection in an RE process based on the phases of Nonaka's model. However, they do not propose how to use these

In order to implement the knowledge spiral property, it is crucial to facilitate the exchange of knowledge among all involved in the project [16]. It implies focusing on the knowledge holders, especially in ISD where knowledge is mostly tacit. This task may become difficult to handle because requirements engineers can be confronted with several persons whom they do not know. KM offers the concept of knowledge map [5], an artefact that points to knowledge but does not contain it. The artefact could be a table or a matrix indicating which person has what knowledge. The knowledge map should be created and initialized at the beginning of the process and continually be updated as the spiral of knowledge evolves. A knowledge map is also useful to discover for which knowledge a knowledge holder might be missing. In

edge. Individuals will absorb the knowledge as tacit knowledge again.

and internalization (SECI) which are described as follows:

mental models and technical skills.

94 Knowledge Management Strategies and Applications

opment of models, protocols and guidelines.

knowledge to create new explicit knowledge.

techniques and how to elicit tacit knowledge.

**3.3. Knowledge sharing**

As was mentioned above, in ISD, understanding the problem and the structure of the solution are intertwined. The problem solvers, that is, the requirements engineers, must explore different areas of the problem to find a solution. In order to accomplish this task, they should dialogue with the domain specialists, who have their own domain knowledge and perspective of the possible solution. By performing this task, the knowledge of the problem solvers about the application domain evolves. If were necessary, they can return to previous states of the project, but their knowledge is not the same, they will have additional knowledge that allows them to explore new possibilities of solution. In summary, the knowledge of the problem and its solution gradually evolves as requirements engineers gain more knowledge of the application domain due to social interaction and their involvement with the business processes. In order to model that behaviour, the knowledge evolution model for requirements elicitation (KEM-RE) was developed based on the SECI model. The KEM-RE is an iterative cycle (**Figure 4**) that consists of four stages that include the four kinds of knowledge processes in the innovation of complex problem solving:


**Figure 4.** Knowledge evolution model for requirements elicitation.
