**2.2. Formality and informality**

Grant [11] provides a graphical representation of knowledge degradation as it is expressed by Polanyi's work (**Figure 1**). The bar represents how the knowledge is flowing in a continuum between tacit and explicit. The continuum ranges from knowledge inherently tacit to knowledge that can be easily expressed by words. The knowledge that can be expressed by words ranges from explicit to experts to explicit to most people. The knowledge explicit to experts requires specialized language. Most of this knowledge is also implicit, i.e. knowledge that can be expressed by words, but that for some reason it has not made explicit. The tacit knowledge ranges from ineffable to highly personal. Much of this knowledge is related to the use of

To Gourlay [12], Polanyi's work has been misunderstood. He argued that some tacit knowledge does become amenable to analysis and decomposition, allowing recording it in an explicit form. Likewise, tacit knowledge in requirements elicitation has been misused. For example, Janik [12] has identified that the concept of tacit knowledge is used in two ways:

**1.** Concerning to knowledge that can be expressed, but for some reasons, it remains hidden. Janik identified three reasons why knowledge tends to remain tacit: (1) concern for secrecy and power, (2) because no one has bothered to recognize it or tried to explain it and (3) because it concerns presuppositions, we all generally hold. These situations can be aware, as the first one, or unaware, as the second and third ones. However, there are non-

**2.** Concerning to knowledge gained through familiarity and practice, which is inexpressible in words, or knowledge gained by perception as sight, smell or know-how. A wine taster or identifying an instrument when listening to a sound, are some examples of this

What is really important in requirements elicitation is making the most possible quantity of knowledge explicit. Whether it is tacit, implicit or that for some reason remains hidden, even

instruments, such as playing piano or using a specialized machine.

88 Knowledge Management Strategies and Applications

insuperable barriers to make this knowledge explicit.

knowledge.

because nobody asks.

**Figure 1.** Granularity of knowledge.

Intuitively, a domain is a well-defined area of human activity with formal and informal issues in which a *universe of discourse* occurs. According to Webster's Dictionary, 'formal' means definite, orderly and methodical. In computer science, to be formal does not necessarily require the use of formal logic, or even mathematics, but the use of a formal notation to represent system models. Everything that computers do is formal because the syntactic structures in a program are manipulated according to well-defined rules [13]. In domains with a significant social context, much of the information is embedded in the social world of domain specialists; it is informal (not susceptible to be formalized or not yet formalized) and depends on the context for its interpretation [16]. These kinds of domains share characteristics such as informally defined concepts and lack of absolute verification of the processes; therefore, the domains specialists should use a great quantity of tacit knowledge to solve everyday situations.

Every domain is susceptible to be formalized to a certain level, but there will always be issues that remain informal. If a domain is mainly formal, the domain specialists can build, in a relative easy way, formal structures to solve problems. On the other hand, if a domain is mainly informal, it does not mean that domain specialists cannot build a structure; definitely they do. In some way, it is possible to solve diagnostic or design problems; however, these structures are informal, i.e. they depend on the context and the domain specialists' experience and knowledge. When informal characteristics prevail, the process and effort to solve problems can be extremely costly and time consuming.

Nguyen and Shanks [17] describe requirements elicitation as an ill-structured problem due to its openness, its context poorly understood and the existence of multiple domains. For Nguyen, solving problems in requirements elicitation requires a complex and dynamic social interaction between domain specialists and developers. The knowledge of both actors evolves as the project advances: the domain specialists get involved with software-solution and the developers with the organizational structure and business processes, i.e. the application domain. According to Nguyen, to solve ill-structured problems, understanding the problem and the structure of the solution are interleaved. The problem solvers, i.e. the requirements engineers, must explore different areas of the problem to find a solution. To accomplish this task, they communicate with the diverse actors who have domain knowledge or another perspective of the possible solution. By performing this task, their domain knowledge increases and they can return to previous stages of the problem, but with additional knowledge that allows them to explore new possibilities of solution. Therefore, the knowledge of the problem and its solution gradually evolves as the requirements engineers gain more knowledge of the domain, mainly due to social interactions and involvement of business processes.

We go further and assume that the grade of informality of the domain application influences the complexity of the process, as **Figure 2** depicts. Our focus is on the requirements elicitation process for domains with a high degree of informality, where knowledge is informally stated, partially complete, implicitly assumed, tacit and unstructured.

### **2.3. Characteristics of ISD**

In order to effectively deal with ISD, we assume that they are located in the intersection of knowledge engineering and requirements engineering, and have the following characteristics [2]:

• Presence of multiple *domain specialists* who have different backgrounds, perspectives, interests and expectations, and whose knowledge, either tacit or explicit, of the application domain varies depending on their experience and their role in the domain. Usually, domain specialists are not aware of the details of the product or solution and only have a vague idea of its general functionality.

**Figure 2.** Complexity of domains.


**Figure 3** depicts the characteristics described above; the figure represents *explicit knowledge* by puzzle pieces and *tacit knowledge* by clouds. The *requirements specification* is formed by pieces of knowledge of the domain specialists and requirements engineers. The requirements engineers must make the greatest possible amount of tacit knowledge explicit, synthesize the

**Figure 3.** Informally structured domains.

Nguyen and Shanks [17] describe requirements elicitation as an ill-structured problem due to its openness, its context poorly understood and the existence of multiple domains. For Nguyen, solving problems in requirements elicitation requires a complex and dynamic social interaction between domain specialists and developers. The knowledge of both actors evolves as the project advances: the domain specialists get involved with software-solution and the developers with the organizational structure and business processes, i.e. the application domain. According to Nguyen, to solve ill-structured problems, understanding the problem and the structure of the solution are interleaved. The problem solvers, i.e. the requirements engineers, must explore different areas of the problem to find a solution. To accomplish this task, they communicate with the diverse actors who have domain knowledge or another perspective of the possible solution. By performing this task, their domain knowledge increases and they can return to previous stages of the problem, but with additional knowledge that allows them to explore new possibilities of solution. Therefore, the knowledge of the problem and its solution gradually evolves as the requirements engineers gain more knowledge of the

domain, mainly due to social interactions and involvement of business processes.

partially complete, implicitly assumed, tacit and unstructured.

**2.3. Characteristics of ISD**

90 Knowledge Management Strategies and Applications

of its general functionality.

**Figure 2.** Complexity of domains.

We go further and assume that the grade of informality of the domain application influences the complexity of the process, as **Figure 2** depicts. Our focus is on the requirements elicitation process for domains with a high degree of informality, where knowledge is informally stated,

In order to effectively deal with ISD, we assume that they are located in the intersection of knowledge engineering and requirements engineering, and have the following characteristics [2]:

• Presence of multiple *domain specialists* who have different backgrounds, perspectives, interests and expectations, and whose knowledge, either tacit or explicit, of the application domain varies depending on their experience and their role in the domain. Usually, domain specialists are not aware of the details of the product or solution and only have a vague idea disperse knowledge and reconcile the diverse beliefs and necessities of the domain specialists. In addition, they need to incorporate their own technical knowledge in order to generate the set of requirements of the solution. In the figure, this process is represented by the solved puzzle. The cloud in the solved puzzle means that there will always be knowledge that is not susceptible to be formalized.
