Eliciting sufficient high-quality knowledge from individuals to design a new product or solution is a very time-consuming and expensive activity, especially in domains where the knowledge is informally stated, partially complete, implicitly assumed, tacit and unstructured. The KMoS-RE strategy has the aim of acquiring and structuring the most quantity of knowledge, either tacit or explicit, in order to incorporate it into a specification that cover the needs and expectations of clients and users. The goal of this paper is to present the application of the KMoS-RE strategy in an industrial design real case. The case study showed that the strategy is effective eliciting and structuring knowledge of an informally structured and complex domain, that the artifacts proposed by the strategy act as an effective means of communication among the involved, and that the strategy evolves the knowledge of all involved in any application domain in a short time, which leads to better design decisions.
Developing new products or solutions that required specialized
technical knowledge is a complex task, especially when application
domain knowledge has to be incorporated in their specifications
(This work considers that the application domain is the domain
where the product or solution will be deployment). This complexity
increases when the product developers or solution-solver are not
immerse in the application domain. In these situation, the efficient
and effective functionality of new products or solutions depends on
eliciting, discovering, specifying, verifying and validating their
requirements [
In order to attend this problematic, Requirements Engineering (RE)
emerges as a research area that proposes theories, techniques, tools
and processes with the aim of eliciting, analyzing, evaluating,
consolidating and managing the requirements of a product or
solution. Through time there have been various successful
proposals that have helped to understand the requirements
engineering area and facilitated the different tasks involved in it.
However, the interest of this work is on some kind of situation with
a higher level of complexity, named Informally Structured
Domains (ISD) [
According to Hansen et al [
The KMoS-RE strategy [
ISD are located in the field of Knowledge Engineering and
Requirements Engineering and has the following characteristics
[
Presence of multiple Domain Specialists (DS) who have different experience, point of view, interests and expectations, and whose knowledge of the application domain varies depending on their role and function in the domain. Domain specialists generally have a vague idea about the product or solution.
Presence of a group of Solution Solvers (SS) who generally are unfamiliar with the application domain. They have technical knowledge about the solution and must know the solution requirements.
The Solution (S) has a unique design and solves or addresses a particular situation. The Solution (S) could be a product or a solution and must be developed according to a Solution Requirements Specification (SlRS).
The SlRS is a document that contains the greatest possible amount of correct, appropriate and unambiguous requirements.
The SlRS development will require great quantities of domain and technical knowledge about the solution.
In order to develop the SlRS, a cognitive dialogue is necessary among all involved in the project, either solution-solvers or domain specialists.
Based on the previous characteristics, the problem can be formulated as follows.
Given: ISD = (DS, SS, KT, KH, K, Nc) a well-defined area represented as a sextuplet, where: – – – – –
DS = {ds1 . . . dsm} is a set of domain specialists ds, where dsm represents the value taken by the variable ds in the m−th unit. SS = {ss1 . . . ssn} is a set of solution-solvers ss, where ssn represents the value taken by the variable ss in the n−th unit. A solution-solver is an individual, generally not involved in the domain, with knowledge and experience to propose a suitable solution S to the necessity Nc. The SS members must know the features of the necessity Nc.
KT = C ∪ R is the union set of concepts and relationships, namely the knowledge that where: • C = {c1 . . . cq} is a set of concepts c, where cq represents the value taken by the variable c in the q−th unit. A concept is knowledge about objects sharing similar properties. • Rdf= {rdf1 (c1 . . . ck) . . . rdfr (c1 . . . ck)} is a set of relationships rdf defined formally, where rdfr represents the value taken by the variable rdf in the r−th unit. • Rdc = {rdc1 (c1 . . . ck) . . . rdcs (c1 . . . ck)} is a set of relationships rdc defined by consensus, where rdcs represents the value taken by the variable rdc in the s−th unit. • R = Rdf ∪ Rdc is the union set of Rdf and Rdc being a relationship a representation of the k concepts in a relationship in the domain, with k >= 2.
KH = Bs ∪ Bns is the union set of Bs and Bns, namely knowing how, where: • Bs = {bs1 ...bsu} is a set of situated behaviors bs, where bsu represents the value taken by the variable bs in the u−th unit. A behavior is a set of observable and measurable interactions; a situated behavior depends on the context and does not have solution algorithms, so depends on the knowledge of the domain specialists to be accomplished. • Bns = {bns1 ...bnsv} is a set of non-situated behaviors bns, where bnsv represents the value taken by the variable bns in the v–th unit. A non-situated behavior has at least one algorithmic solution.
K = [kijω](m+n)t a matrix, i = {1 . . . m + n}, j ={1 . . . t}, where m + n is the sum of domain specialists plus the solution solvers and t is the sum of the number of concepts, relationships defined formally, relationships defined by consensus, situated behaviors and non-situated behaviors, i.e. t = q + r + s + u + v where: • kijω is the degree of tacitness of the domain specialist dsi or the solution-solver ssi about the concept cj , the relationship rj or the behavior bj. • ω a membership degree, with ω = f (p, pk), where – – – –
f : (DS∪SS)× (C∪R∪B) → [
S is defined as a suitable solution. It means an any-time solution that satisfies the clients and users’ necessities or expectations. An any-time solution is the best current solution that generates a process at the time it stops.
SlRS = {sr1 . . . srw} is a set of solution requirements sr where srw represents the value taken by variable srw in the w−th unit. A solution requirement is a natural language statement to be enforced by the solution, possibly in cooperation with other system components, and formulated in terms of the application domain.
ANP is informally defined as an Arduous Negotiation Process by which domain specialists and solution-solvers settle the features of the S while avoiding arguments.
The KMoS-RE strategy is designed to provide a systematic way to
elicit structure and create knowledge that can be incorporated into
a product or solution specification [
Domain Modeling Phase (DM). The first phase of the
strategy aims to formalize the domain properties. It
means to describe concepts, attributes, relationships
between concepts, and basic integrity restrictions. The
Language of Extended Lexicon (LEL) [
System Modeling Phase (SM). Requirements engineers
should model two versions of the system: the system as
it exists before deployment a solution (current system),
and the system as it should be when the solution will be
operated in it (future system). The aim of this phase is to
formalize the current and future system processes. The
Use Cases Model [
Specification Development Phase (SD). In this phase, the requirements engineers derive the set of requirements from the Uses Cases of the future system. These requirements will be used to build the Solution Requirements Specification (SlRS) document.
The strategy is supported by the Knowledge Evolution Model for Requirements Engineering (KEM- RE) (section 3.1) and includes transversal activities to make explicit the tacit knowledge, such as 1) recording the wrong beliefs and 2) keeping track in the PoK (Piece of Knowledge) matrix, the tacitness level of concepts, relationships and behaviors by every involved in the project. The goal of the matrix is showing what pieces of knowledge should be made explicit.
In ISD, understanding the problem and the structure of the solution
are intertwined [
In order to model that behavioral, the Knowledge Evolution Model
for Requirements Engineering (KEM-RE) was developed based on
the SECI model proposed by Nonaka [
The KEM-RE is an iterative cycle (Fig. 2) composed by four stages
that include the four kinds of knowledge processes in the
innovation of complex problem solving [
The requirements engineers (filled circles) elicit knowledge from domain specialists (empty circles) and vice versa. The socialization mode (empty bar) predominates. Knowledge Integration and Application (KI&A) Stage. The requirements engineers integrate the acquired knowledge and their own experience into models. This is a complex activity in which combination and externalization modes are presented. In addition, as the requirement engineers develop models they internalize (clouds) the domain knowledge. Knowledge Sharing and Exchange (KS&E) Stage.
The models developed by requirements engineers will be shared with the domain specialists. This phase takes place through socialization. Knowledge Validation (KV) Stage. The domain specialists validate the models. In order to develop this activity, an arduous negotiation process is necessary since they must internalize the knowledge behind the models. This process leads to the elicitation of new knowledge. Then the cycle starts again.
The Fig. 3 depicts the activity flow of the KMoS- RE strategy at a
global level in UML notation. Every activity of the strategy
corresponds to one state of the KEM-RE: Model Validations (MV)
is related to Knowledge Validation (KV), Knowledge Elicitation
(KE) is related with Knowledge Elicitation and Creation (KE&C),
Model Discussion (MD) corresponds to Knowledge Sharing and
Exchange (KS&E), and Domain Modeling (DM), System Modeling
(SM) and Specification Development (SD) corresponds to
Knowledge Integration and Application (KI&A). The swim lanes in
the figure represent the activities developed by each type of actor.
The KMoS-RE strategy begins with an Initialization Activity (IA)
in which an initial interview is conducted. This information can be
completed with formal documents such as user manuals, policies,
business processes, and even legacy systems. After the interview,
the requirements engineers initialize the PoK matrix by identifying
domain specialists, concepts, relationships and behaviors. Finally,
Once the IA is concluded, the requirements engineers begin to
develop the artifacts to model the domain. Then, the requirements
engineers discuss the models with the domain specialist in order to
validate them. By doing this process, more domain knowledge is
elicited, and the requirements engineers can decide to improve the
previous models or to continue with the artifacts of the next phase,
that is, the requirements engineers can work in parallel with several
models but it is necessary to start in the established order. The
above is represented in Fig. 3 with a bold line. These activities will
be repeated until those involved in the project reach a consensus
about the set of requirements for the solution. Each phase is
composed by a set of tasks that will guide the requirements
engineers to the development of the artifacts; the details of the
KMoS-RE strategy can be consulted in [
FLUTEC Design + Build Company is a manufacturing company located in the city of Juarez, Chihuahua, on the US-Mexican Border. This company designs and builds Heating Ventilation and Air Conditioning (HVAC) modules specifically designed to meet the demands of its clients on a case-by-case basis. In other words, FLUTEC offers a customized build for every single project they undertake.
HVAC module design is a complex task [
To deal with the challenges of eliciting requirements to design HVAC modules, the company has developed an artifact in which the basic necessary information of every project is included. They have called “DNA” to this document, as a metaphor for the deoxyribonucleic acid. To facilitate the DNA document building process, the company developed a generic DNA; a guideline composed of general attributes. For each project, a person is assigned to elicit requirements and assign values to these attributes. The DNA document is used in two ways: as a guide to elicit requirements and, once it is completed, as a guide to design the HVAC module. It is a bridge between the domain requirements and the HVAC design. Since a requirements engineering perspective, the DNA acts as a specification document.
Although the DNA document had given some structure and order to the requirement process, there are still some associated problems that cause delays, reworks and elevated costs. Therefore, FLUTEC needs to improve its elicitation process in order to facilitate the negotiation between the requirements engineers and the domain specialists and to obtain a specification document closest to the needs of clients.
The case study was an explorative research and had the objective of providing evidence that the KMoS-RE strategy could be implemented as the requirements elicitation process of FLUTEC. Therefore, the research question was formulated as follow: Is it feasible to implement the KMoS-RE strategy to elicit requirements of an HVAC module in order to obtain a specification as close as possible to the client’s needs? To answer the research question, the following steps were performed:
Verify is the problem is an ISD according the formulation given in section 2.
Analyze the current requirements elicitation process with the domain modeling phase of the KMoS-RE strategy. Empower the FLUTEC requirements engineers with the theoretical foundations about the KMoS-RE strategy.
Determine, in collaboration with FLUTEC engineers, the feasibility of implementing the strategy in the company
The first step of the case study was to determinate if the problem is an ISD. According section 2 the problem belongs to ISD because the next characteristics: – Presence of multiple domain specialists. FLUTEC offers a custom build for each project they undertake. Thus, it is necessary to elicit the requirements from the domain specialists; that is, everyone with knowledge about the domain. In this case, the domain is the building in which the HVAC module will be installed. The group of domain specialists will be formed by the technical team responsible for designing and constructing the building. – Presence of a group of solver-solutions responsible for eliciting the requirements. In order to build a HVAC module, a multidisciplinary team composed by electrical, mechanical, electronic and control engineers work together and share their knowledge to arrive at a solution. Therefore, the solution-solvers will be all the specialists involved in the project. – The product or solution has a unique design and solves or addresses a particular situation. As it was said above, FLUTEC offers a build-to-suit approach for every project. – – –
The product or solution must be deployed according to a Solution Requirements Specification (SlRS).
The SlRS development significantly requires great quantities of domain knowledge and technical knowledge about the building and the solution.
In order to develop the SlRS, an arduous negotiation process between the requirements engineers and the domain specialists, and even among the domain specialists is required.
The second step of the case study was to analyze the current requirements elicitation process. As explained before, the HVAC design activity is a complex process; thus, it was decided to use the Domain Modeling Phase of the KMoS-RE strategy to structure and make explicit the HVAC domain. At the end of the domain modeling phase the research team generated the LEL and the entityrelationship conceptual model, both validated by the domain specialists.
The LEL and the conceptual model were used to analyze the generic DNA document. After the analysis, it was confirmed that the generic DNA document was disorganized, incomplete, and incorrect. Moreover, it had ambiguous information.
The third step in the case study aimed to empower the FLUTEC requirements engineers with the theoretical foundations about the KMoS-RE strategy, such as requirements engineering process, knowledge transference process, symmetry of ignorance and tacit knowledge. The observations of every concept and their application in the FLUTEC environment are explained below:
Requirements Engineering Process. The FLUTEC engineers empirically understood the importance of the requirements elicitation and the problems caused by it. This was the reason they created the DNA guide document. However, they did not have the knowledge that this activity could be viewed as a systematic process. Thus, the application of the DNA guide was conditional on the personal judgment of the FLUTEC project personnel.
Knowledge Transference Process. It was explained to the FLUTEC engineers that the requirements engineering could be viewed as a knowledge transference process. This was a new concept for FLUTEC engineers. Also, it was explained that one of the main implications of this view is to be aware of the human limitation of information transference. So, the FLUTEC engineers realized that they could minimize the ambiguous and incomplete requirements by being aware of this phenomenon.
Tacit Knowledge. The goal of the explanation about tacit knowledge was to sensitize and raise awareness of the problems caused by this phenomenon. It was observed that it is a very confusing term. However, once it was explained with examples, it was fully understood. As an example, FLUTEC engineers said that once a module was designed without the external ladder, because nobody asked the client if it was required. The mistake was evident only when they delivered the product and the product had to be redesigned.
Symmetry of Ignorance. The concept of symmetry of ignorance and the consequences of not being aware of it was explained. FLUTEC engineers realized that when they did not know the building environment (application domain), it was more difficult to design the HVAC module.
The final step of the case study was determine, in conjunction with FLUTEC engineers, the feasibility of applying the KMoS-Re strategy as the company requirements elicitation process. An analysis by every phase of the strategy was then performed, as it is explained below:
Domain Modeling Phase. The first phase of the strategy aims to formalize the domain properties. The LEL would be used to identify, classify and define the terms of the application domain. In the HVAC module design, the application domain would be composed of knowledge of the building, its use and the environment. Once the LEL was developed, it would be used to build the conceptual model. The externalization of this knowledge will enable to achieve a consensus among the stakeholders hence minimizing the symmetry of ignorance.
System Modeling Phase. In software development
projects, requirements engineers should model two
versions of the system: the system as it exists before
the deployment of a solution (current system), and the
system as it should be when the solution will be
operated in it (future system). In the HVAC module
design case, it is not possible to develop the current
system. Thus, the FLUTEC requirements engineers
would proceed to develop the future use cases. The
information used to develop this model would be
derived from the LEL and the conceptual model. In
[
Specification Development Phase. In this phase, the requirements engineers would derive the set of requirements from the Uses Cases of the future system. These requirements would be used to build the Solution Requirements Specification (SlRS) document.
There were several significant results of this case study. The first one is that the KMoS-RE strategy helped to structure the knowledge domain of the HVAC module design. The HVAC domain is very complex: it is composed of a large quantity of concepts and relationships, and it involves several knowledge areas. The domain was structured and done explicated by the LEL and the entity-relationship conceptual model. These models also helped to visualize the domain from a global perspective. It was noticed that every domain specialist knew the information about his or her area, but they ignored information about others. The research team realized that in order to design the DNA guide document, every specialized area proposed the attributes they considered important, but there was no global vision of the document. According to FLUTEC engineers, a global perspective of the module would reduce errors caused by side effects.
The strategy also helped to reduce the symmetry of ignorance between the FLUTEC engineers and the research team in a short time. Reducing the symmetry of ignorance was a key factor in order to improve the communication between the teams and ensure that the analysis of feasibility was effective. Moreover, FLUTEC engineers recognized that the research team's knowledge about the design of HVAC modules evolved in a very short time. Therefore, they consider that the implementation of the strategy as their requirement process would have the advantage of better understanding of the clients’ application domain.
Another result was that the FLUTEC engineers obtained awareness about the importance of requirements engineering, and of the problems that tacit knowledge and the symmetry of ignorance can cause. However, the most meaningful result was to validate the feasibility of implementing the KMoS-RE strategy as the requirements engineering process.
Since the advent of RE as a research area, the view of this discipline has changed from being considered a craft to being considered a critical and influential factor in implementing a solution in any application domain. Although the research work in RE has been good and productive, it has not been enough. Nowadays, there is not a universally accepted methodology or strategy for approaching RE problems. This is even more so if the problem belongs to an Informally Structured Domain (ISD), i.e. domain with a high degree of informality, where the knowledge is informally stated, partially complete, implicitly assumed, tacit and unstructured. The KMoS-RE strategy confronts the problem of eliciting, structuring and creating knowledge in order to achieve a solution or a product closest to the needs of the clients or users and avoiding incorrect, inappropriate and ambiguous requirements in the context of ISD. The strategy was addressed from the knowledge transference and transformation perspective. This view led us to consider knowledge management theories to make the knowledge transference and transformation process more efficient and to make explicit the largest possible amount of tacit knowledge. The case study showed that the KMoS-RE strategy is effective eliciting and structuring knowledge of an informally structured and complex domain, such as the HVAC module design, which does not belong to software development. This result shows that the perspective of engineering requirements from the point of view of the characteristics of the domain led to a generic strategy that can be applied in different contexts. The case study also showed that the artifacts proposed by the strategy act as an effective means of communication among the involved. Finally, it shows that the strategy evolves the knowledge of any application domain in a short time, which leads to better design decisions.
As future work, it is necessary to continue applying the KMoS-RE strategy in several contexts in order to get an ever closer generic proposal for requirements engineering, as well as, developing software tools to automate some activities of the strategy.