Eliciting Requirements for Industrial Design Using the Knowledge Management Strategy for Requirements Engineering Karla Olmos-Sánchez Jorge Rodas-Osollo Alberto Ochoa Universidad Autónoma de Ciudad Universidad Autónoma de Ciudad Universidad Autónoma de Ciudad Juárez Juárez Juárez Av. del Charro 450 Av. del Charro 450 Av. Del Charro 450 Chihuahua, MX Chihuahua, MX Chihuahua, MX kolmos@uacj.mx jorge.rodas@uacj.mx alberto.ochoa@uacj.mx ABSTRACT and processes with the aim of eliciting, analyzing, evaluating, consolidating and managing the requirements of a product or Eliciting sufficient high-quality knowledge from individuals to solution. Through time there have been various successful design a new product or solution is a very time-consuming and proposals that have helped to understand the requirements expensive activity, especially in domains where the knowledge is engineering area and facilitated the different tasks involved in it. informally stated, partially complete, implicitly assumed, tacit and However, the interest of this work is on some kind of situation with unstructured. The KMoS-RE strategy has the aim of acquiring and a higher level of complexity, named Informally Structured structuring the most quantity of knowledge, either tacit or explicit, Domains (ISD) [17]. In this kind of domains, besides the in order to incorporate it into a specification that cover the needs characteristics mentioned above, the products or solutions are and expectations of clients and users. The goal of this paper is to designed according to specific demands of clients, namely they are present the application of the KMoS-RE strategy in an industrial designed ad hoc. Thus, they must be developed according the design real case. The case study showed that the strategy is experience and knowledge of domain specialists. This knowledge effective eliciting and structuring knowledge of an informally depends on the role and experience of domain specialists; therefore structured and complex domain, that the artifacts proposed by the it is partial, informal, no homogeneous, unstructured, implicit and strategy act as an effective means of communication among the tacit. In addition, the product or solution requires of high quantities involved, and that the strategy evolves the knowledge of all of specialized knowledge that cannot be possibly for a person to involved in any application domain in a short time, which leads to have; thus, a specialized team with distributed knowledge is better design decisions. necessary. In general, in ISD not all concepts and their relationships are formally defined, the solutions are diverse, consensual and Keywords unverifiable and domain specialists use large amounts of tacit Informally Structured Domains; Requirements Elicitation Strategy, knowledge in order to attend the everyday situations. Tacit Industrial Design; Knowledge Management knowledge is personal and context-specific knowledge, generated by experience and therefore, difficult to communicate and 1. INTRODUCTION formalize [20] and could cause that critical expectations, Developing new products or solutions that required specialized knowledge and needs of the stakeholders remain hidden [6]. All of technical knowledge is a complex task, especially when application these ISD characteristics difficult the RE’s tasks causing that the domain knowledge has to be incorporated in their specifications set of requirements and in consequence the product or solution (This work considers that the application domain is the domain developed would result inadequate and/or increase the cost and where the product or solution will be deployment). This complexity development time. increases when the product developers or solution-solver are not immerse in the application domain. In these situation, the efficient According to Hansen et al [8] this situation is present in several and effective functionality of new products or solutions depends on areas such as software design, industrial design, graphical design, eliciting, discovering, specifying, verifying and validating their instructional design, and business process design. We consider that requirements [4][9]. However, this task presents serious and it is also present in other areas such as developing intelligent inherent difficulties in the process of eliciting and discovering the systems or intelligent data analysis [17]. In general, every problem correct and appropriate requirements due to the complexity of the that requires a complex, highly creative solution, in which the requirement task, the intricate interaction between solution-solvers problem solver is not part of the application domain, and that needs and the intended users, and the limits of human information eliciting sufficient high-quality knowledge through a cognitive processing [5]. Usually, clients and users do not have a clear idea dialogue to understand the clients' need and expectations faces this of the product or solution they require; even when they have it, they challenge generally are unable to describe it. In most cases, they are so Although all of these areas share the challenges of RE, the major immersed in the application domain that takes important source of RE research comes from software engineering. In this information for granted. area the critical role of requirements has been recognized for In order to attend this problematic, Requirements Engineering (RE) decades because software systems are always embedded in an emerges as a research area that proposes theories, techniques, tools application domain and their usefulness depends on the problems they can solve and on the objectives they can achieve in those – The SlRS is a document that contains the greatest domains [3]. Therefore, the research of this work started analyzing possible amount of correct, appropriate and unambiguous software engineering proposal in order to select the most suitable, requirements. and integrating them in a strategy that can be applied to elicit – The SlRS development will require great quantities of requirements in ISD. In order to reach this goal a perspective that domain and technical knowledge about the solution. embraces the elicitation requirements problems of all areas – In order to develop the SlRS, a cognitive dialogue is mentioned above is necessary. We assume that a Knowledge necessary among all involved in the project, either Management (KM) perspective of RE that emphasizes the solution-solvers or domain specialists. importance of knowledge is a useful approach for addressing certain RE inherent problems, due to the characteristics of ISD. Based on the previous characteristics, the problem can be This idea is not new [19][23][11], but only few efforts provide a formulated as follows. full KM perspective of RE [22]. This perspective involves 1) seeing Given: RE as a KM process where the knowledge is transferred and ISD = (DS, SS, KT, KH, K, Nc) a well-defined area represented as transformed in a spiral of knowledge evolution, 2) distinguishing a sextuplet, where: between explicit and tacit knowledge 3) emphasizing the application domain knowledge, and 4) facilitating the knowledge – DS = {ds1 . . . dsm} is a set of domain specialists ds, where dsm exchange among all involved in the project, either domain represents the value taken by the variable ds in the m−th unit. specialists or solution-solvers. – 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. The KMoS-RE strategy [16] has been developed as a pattern in a A solution-solver is an individual, generally not involved in stream of decisions, oriented to the transfer or transformation of the domain, with knowledge and experience to propose a knowledge, specially designed to be applied in the context of ISD, suitable solution S to the necessity Nc. The SS members must with the aim of acquiring and structuring the most quantity of know the features of the necessity Nc. knowledge, either tacit or explicit, and incorporate it into a – KT = C ∪ R is the union set of concepts and relationships, specification that cover the needs and expectations of clients and namely the knowledge that where: users. As we mentioned above, the strategy is based in software • C = {c1 . . . cq} is a set of concepts c, where cq requirements research, but it is designed for using in ISD, either represents the value taken by the variable c in the software system development or industrial design, among others. q−th unit. A concept is knowledge about objects The goal of this paper is to present the application of the KMoS- sharing similar properties. RE strategy in an industrial design real case. The strategy was • Rdf= {rdf1 (c1 . . . ck) . . . rdfr (c1 . . . ck)} is a set of evaluated to be used as the requirement process of HVAC (Heating relationships rdf defined formally, where rdfr Ventilation and Air Conditioning) modules design with the aim of represents the value taken by the variable rdf in the obtaining a product specification the closest to the clients’ needs r−th unit. and expectations. HVAC module design is a complex task because • Rdc = {rdc1 (c1 . . . ck) . . . rdcs (c1 . . . ck)} is a set of it includes a lot of cognitive activities, such as establishing the basic relationships rdc defined by consensus, where rdcs specifications for the provided application, analyzing the building represents the value taken by the variable rdc in the characteristics, selecting the appropriate air conditioning system s−th unit. and its components, and analyzing the control system, among • R = Rdf ∪ Rdc is the union set of Rdf and Rdc being others. The remainder of this document is as follows: Section 2 a relationship a representation of the k concepts in a provides a formalization of ISD. Section 3 explains the KMoS-RE relationship in the domain, with k >= 2. strategy. Section 4 describes the real case study. Finally, in section – KH = Bs ∪ Bns is the union set of Bs and Bns, namely knowing 5, conclusions and future work are provided. how, where: • Bs = {bs1 ...bsu} is a set of situated behaviors bs, 2. ISD Formalization where bsu represents the value taken by the variable ISD are located in the field of Knowledge Engineering and bs in the u−th unit. A behavior is a set of observable Requirements Engineering and has the following characteristics and measurable interactions; a situated behavior [17]: depends on the context and does not have solution – Presence of multiple Domain Specialists (DS) who have algorithms, so depends on the knowledge of the different experience, point of view, interests and domain specialists to be accomplished. expectations, and whose knowledge of the application • Bns = {bns1 ...bnsv} is a set of non-situated domain varies depending on their role and function in the behaviors bns, where bnsv represents the value taken domain. Domain specialists generally have a vague idea by the variable bns in the v–th unit. A non-situated about the product or solution. behavior has at least one algorithmic solution. – Presence of a group of Solution Solvers (SS) who – K = [kijω](m+n)t a matrix, i = {1 . . . m + n}, j ={1 . . . t}, where generally are unfamiliar with the application domain. m + n is the sum of domain specialists plus the solution solvers They have technical knowledge about the solution and and t is the sum of the number of concepts, relationships must know the solution requirements. defined formally, relationships defined by consensus, situated behaviors and non-situated behaviors, i.e. t = q + r + s + u – The Solution (S) has a unique design and solves or addresses a particular situation. The Solution (S) could + v where: be a product or a solution and must be developed • kijω is the degree of tacitness of the domain specialist according to a Solution Requirements Specification dsi or the solution-solver ssi about the concept cj , the relationship rj or the behavior bj. (SlRS). • ω a membership degree, with ω = f (p, pk), where f : (DS∪SS)× (C∪R∪B) → [−1, 0, 1] requirements will be used to build the Solution is an intuitionistic membership function of the tacitness Requirements Specification (SlRS) document. of pi about the piece of knowledge pkj, being p a domain The strategy is supported by the Knowledge Evolution Model for specialist or a solution solver and pk the knowledge about Requirements Engineering (KEM- RE) (section 3.1) and includes a concept, a relationship or a behavior, and transversal activities to make explicit the tacit knowledge, such as ∀(p) ∀(pk)[ω(p, pk) = 0 → pk ϵ tacit ∧ pk ϵ p], 1) recording the wrong beliefs and 2) keeping track in the PoK (Piece of Knowledge) matrix, the tacitness level of concepts, ∀(p) ∀(pk)[ω(p, pk) = 1 → pk ϵ explicit ∧ pk ϵ p] and relationships and behaviors by every involved in the project. The ∀(p) ∀(pk)[ω(p, pk) = −1 → pk ϵ p] goal of the matrix is showing what pieces of knowledge should be made explicit. – Nc ⊂ (B ∪ C ∪ R) and Nc represents a necessity of the clients and users. Sometimes the necessity corresponds to a problem Fig. 1 shows a structural perspective of the KMoS-RE strategy, in the domain, but not always. In both cases, the necessity or phases are represented by redounded rectangles and artifacts are problem demands a suitable solution S. represented by square rectangles. The labeled arrow shows that the – S is defined as a suitable solution. It means an any-time activities of tacit knowledge identification must be done solution that satisfies the clients and users’ necessities or transversely. 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. 3. KMoS-RE Strategy 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 [16]. Following to [21], the Fig. 1. Structural Perspective of the KMoS-RE Strategy strategy is composed by three sequential phases: Domain Modeling, System Modeling and Specification Developing. Below, 3.1 Knowledge Evolution Model for a brief explanation of each phase is provided: Domain Modeling Phase (DM). The first phase of the Requirements Engineering strategy aims to formalize the domain properties. It In ISD, understanding the problem and the structure of the solution means to describe concepts, attributes, relationships are intertwined [13]; the solution-solvers must explore different between concepts, and basic integrity restrictions. The areas of the problem to find a solution; they should dialogue with Language of Extended Lexicon (LEL) [10] is used to the diverse domain specialists, who have their own domain identify, classify and define the terms of the domain. knowledge, and possibly, their own perspective of the possible Once the LEL is developed, it is used to build a graphical solution. By performing this task, the knowledge of the solution- entity-relationship conceptual model. The externalization solvers about the application domain increases. If necessary, they of this knowledge will enable achievement a consensus can return to previous states of the project but with additional about the domain among all involved in the process; knowledge that allows them to explore new possibilities of hence to minimize the asymmetry of knowledge. The solution. In summary, the knowledge of the problem and its concepts and relationships identified in this phase will solution gradually evolves as requirements engineers gain more generate the first version of the Piece of Knowledge knowledge of the domain due to social interaction and their (PoK) matrix. involvement with the business processes. In order to model that behavioral, the Knowledge Evolution Model System Modeling Phase (SM). Requirements engineers for Requirements Engineering (KEM-RE) was developed based on should model two versions of the system: the system as the SECI model proposed by Nonaka [14][15]. The author proposes it exists before deployment a solution (current system), a model of knowledge conversion in organizations based on and the system as it should be when the solution will be Polany’s theory about tacit knowledge [20]. For him, knowledge operated in it (future system). The aim of this phase is to creation in an organization is the result of social interactions that formalize the current and future system processes. The involves tacit and explicit knowledge. The SECI model postulates Use Cases Model [7] is used to model the system, both four iterative conversion modes: 1) Socialization, the process of current and future. The information used to develop this transferring tacit knowledge between individuals by sharing mental model is derived from the LEL and the conceptual model. models and technical skills; 2) Externalization, the process of The behaviors identified in this phase will transform the converting tacit knowledge to explicit through the development of PoK matrix. models, protocols and guidelines; 3) Combination, the process of Specification Development Phase (SD). In this phase, the recombining or reconfiguring existing bodies of explicit knowledge requirements engineers derive the set of requirements to create new explicit knowledge; and 4) Internalization, the from the Uses Cases of the future system. These process of learning by task repetition. Some of these tasks could have been defined by explicit knowledge. Whatever the case, the values of the PoK matrix are recorded according the knowledge individuals will absorb the knowledge as tacit knowledge again. tacitness level. 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 [12]:  Knowledge Elicitation and Creation (KE&C) Stage. 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 Fig. 3. UML Activity Flow Diagram of the KMoS-RE Strategy specialists validate the models. In order to develop this activity, an arduous negotiation process is Once the IA is concluded, the requirements engineers begin to necessary since they must internalize the knowledge develop the artifacts to model the domain. Then, the requirements behind the models. This process leads to the elicitation engineers discuss the models with the domain specialist in order to of new knowledge. Then the cycle starts again. 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 [18]. 4. INDUSTRIAL DESIGN CASE STUDY Fig. 2. Knowledge Evolution Flow for Requirements FLUTEC Design + Build Company is a manufacturing company Engineering 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 3.2 KMoS-RE Activity Flow the demands of its clients on a case-by-case basis. In other words, The Fig. 3 depicts the activity flow of the KMoS- RE strategy at a FLUTEC offers a customized build for every single project they global level in UML notation. Every activity of the strategy undertake. corresponds to one state of the KEM-RE: Model Validations (MV) HVAC module design is a complex task [2] because it includes a is related to Knowledge Validation (KV), Knowledge Elicitation lot of cognitive activities, such as 1) establishing the basic (KE) is related with Knowledge Elicitation and Creation (KE&C), specifications for the provided application, 2) analyzing the Model Discussion (MD) corresponds to Knowledge Sharing and building characteristics, 3) selecting the appropriate air Exchange (KS&E), and Domain Modeling (DM), System Modeling conditioning system and its components, and 4) analyzing the (SM) and Specification Development (SD) corresponds to control system, among others. HVAC design becomes even more Knowledge Integration and Application (KI&A). The swim lanes in difficult because there is a lot of information and restrictions about the figure represent the activities developed by each type of actor. the domain where the HVAC will be installed and this knowledge The KMoS-RE strategy begins with an Initialization Activity (IA) belongs to the domain specialists, a group of specialists from in which an initial interview is conducted. This information can be different fields, such as mechanical engineers, control engineers, completed with formal documents such as user manuals, policies, electrical engineers and architects; therefore it is incomplete and business processes, and even legacy systems. After the interview, vague. Moreover, there could be multiple and controversial the requirements engineers initialize the PoK matrix by identifying solutions, so that the criteria to determine the goal are complex and domain specialists, concepts, relationships and behaviors. Finally, imprecise. To deal with the challenges of eliciting requirements to design – The product or solution must be deployed according to a HVAC modules, the company has developed an artifact in which Solution Requirements Specification (SlRS). the basic necessary information of every project is included. They – The SlRS development significantly requires great have called “DNA” to this document, as a metaphor for the quantities of domain knowledge and technical knowledge deoxyribonucleic acid. To facilitate the DNA document building about the building and the solution. process, the company developed a generic DNA; a guideline – In order to develop the SlRS, an arduous negotiation composed of general attributes. For each project, a person is process between the requirements engineers and the assigned to elicit requirements and assign values to these attributes. domain specialists, and even among the domain The DNA document is used in two ways: as a guide to elicit specialists is required. requirements and, once it is completed, as a guide to design the HVAC module. It is a bridge between the domain requirements and The second step of the case study was to analyze the current the HVAC design. Since a requirements engineering perspective, requirements elicitation process. As explained before, the HVAC the DNA acts as a specification document. design activity is a complex process; thus, it was decided to use the Domain Modeling Phase of the KMoS-RE strategy to structure and Although the DNA document had given some structure and order make explicit the HVAC domain. At the end of the domain to the requirement process, there are still some associated problems modeling phase the research team generated the LEL and the entity- that cause delays, reworks and elevated costs. Therefore, FLUTEC relationship conceptual model, both validated by the domain needs to improve its elicitation process in order to facilitate the specialists. negotiation between the requirements engineers and the domain The LEL and the conceptual model were used to analyze the specialists and to obtain a specification document closest to the generic DNA document. After the analysis, it was confirmed that needs of clients. the generic DNA document was disorganized, incomplete, and 4.1 Case Study Design incorrect. Moreover, it had ambiguous information. The case study was an explorative research and had the objective The third step in the case study aimed to empower the FLUTEC of providing evidence that the KMoS-RE strategy could be requirements engineers with the theoretical foundations about the implemented as the requirements elicitation process of FLUTEC. KMoS-RE strategy, such as requirements engineering process, Therefore, the research question was formulated as follow: Is it knowledge transference process, symmetry of ignorance and tacit feasible to implement the KMoS-RE strategy to elicit requirements knowledge. The observations of every concept and their application of an HVAC module in order to obtain a specification as close as in the FLUTEC environment are explained below: possible to the client’s needs? To answer the research question, the  Requirements Engineering Process. The FLUTEC following steps were performed: engineers empirically understood the importance of the requirements elicitation and the problems caused 1. Verify is the problem is an ISD according the formulation by it. This was the reason they created the DNA guide given in section 2. document. However, they did not have the knowledge 2. Analyze the current requirements elicitation process with that this activity could be viewed as a systematic the domain modeling phase of the KMoS-RE strategy. process. Thus, the application of the DNA guide was 3. Empower the FLUTEC requirements engineers with the conditional on the personal judgment of the FLUTEC theoretical foundations about the KMoS-RE strategy. project personnel. 4. Determine, in collaboration with FLUTEC engineers, the  Knowledge Transference Process. It was explained to feasibility of implementing the strategy in the company the FLUTEC engineers that the requirements engineering could be viewed as a knowledge 4.2 Case Study Development transference process. This was a new concept for The first step of the case study was to determinate if the problem is FLUTEC engineers. Also, it was explained that one of an ISD. According section 2 the problem belongs to ISD because the main implications of this view is to be aware of the next characteristics: the human limitation of information transference. So, – Presence of multiple domain specialists. FLUTEC offers the FLUTEC engineers realized that they could a custom build for each project they undertake. Thus, it minimize the ambiguous and incomplete is necessary to elicit the requirements from the domain requirements by being aware of this phenomenon. specialists; that is, everyone with knowledge about the  Tacit Knowledge. The goal of the explanation about domain. In this case, the domain is the building in which tacit knowledge was to sensitize and raise awareness the HVAC module will be installed. The group of domain of the problems caused by this phenomenon. It was specialists will be formed by the technical team observed that it is a very confusing term. However, responsible for designing and constructing the building. once it was explained with examples, it was fully – Presence of a group of solver-solutions responsible for understood. As an example, FLUTEC engineers said eliciting the requirements. In order to build a HVAC that once a module was designed without the external module, a multidisciplinary team composed by electrical, ladder, because nobody asked the client if it was mechanical, electronic and control engineers work required. The mistake was evident only when they together and share their knowledge to arrive at a solution. delivered the product and the product had to be Therefore, the solution-solvers will be all the specialists redesigned. involved in the project.  Symmetry of Ignorance. The concept of symmetry of – The product or solution has a unique design and solves or ignorance and the consequences of not being aware of addresses a particular situation. As it was said above, it was explained. FLUTEC engineers realized that FLUTEC offers a build-to-suit approach for every when they did not know the building environment project. (application domain), it was more difficult to design they consider that the implementation of the strategy as their the HVAC module. requirement process would have the advantage of better The final step of the case study was determine, in conjunction with understanding of the clients’ application domain. FLUTEC engineers, the feasibility of applying the KMoS-Re Another result was that the FLUTEC engineers obtained awareness strategy as the company requirements elicitation process. An about the importance of requirements engineering, and of the analysis by every phase of the strategy was then performed, as it is problems that tacit knowledge and the symmetry of ignorance can explained below: cause. However, the most meaningful result was to validate the  Domain Modeling Phase. The first phase of the feasibility of implementing the KMoS-RE strategy as the strategy aims to formalize the domain properties. The requirements engineering process. LEL would be used to identify, classify and define the terms of the application domain. In the HVAC module 5. CONCLUSIONS AND FUTURE WORK design, the application domain would be composed of Since the advent of RE as a research area, the view of this discipline knowledge of the building, its use and the has changed from being considered a craft to being considered a environment. Once the LEL was developed, it would critical and influential factor in implementing a solution in any be used to build the conceptual model. The application domain. Although the research work in RE has been externalization of this knowledge will enable to good and productive, it has not been enough. Nowadays, there is achieve a consensus among the stakeholders hence not a universally accepted methodology or strategy for approaching minimizing the symmetry of ignorance. RE problems. This is even more so if the problem belongs to an  System Modeling Phase. In software development Informally Structured Domain (ISD), i.e. domain with a high projects, requirements engineers should model two degree of informality, where the knowledge is informally stated, versions of the system: the system as it exists before partially complete, implicitly assumed, tacit and unstructured. the deployment of a solution (current system), and the The KMoS-RE strategy confronts the problem of eliciting, system as it should be when the solution will be structuring and creating knowledge in order to achieve a solution operated in it (future system). In the HVAC module or a product closest to the needs of the clients or users and avoiding design case, it is not possible to develop the current incorrect, inappropriate and ambiguous requirements in the context system. Thus, the FLUTEC requirements engineers of ISD. The strategy was addressed from the knowledge would proceed to develop the future use cases. The transference and transformation perspective. This view led us to information used to develop this model would be consider knowledge management theories to make the knowledge derived from the LEL and the conceptual model. In transference and transformation process more efficient and to make [1], a case study of a HVAC design using UML is explicit the largest possible amount of tacit knowledge. presented. The paper explains how a HVAC system is The case study showed that the KMoS-RE strategy is effective modeled using use cases; it shows that it is feasible to eliciting and structuring knowledge of an informally structured and use the case use model in a HVAC module design. complex domain, such as the HVAC module design, which does  Specification Development Phase. In this phase, the not belong to software development. This result shows that the requirements engineers would derive the set of perspective of engineering requirements from the point of view of requirements from the Uses Cases of the future the characteristics of the domain led to a generic strategy that can system. These requirements would be used to build be applied in different contexts. The case study also showed that the Solution Requirements Specification (SlRS) the artifacts proposed by the strategy act as an effective means of document. communication among the involved. Finally, it shows that the 4.3 Case Study Results strategy evolves the knowledge of any application domain in a short There were several significant results of this case study. The first time, which leads to better design decisions. one is that the KMoS-RE strategy helped to structure the As future work, it is necessary to continue applying the KMoS-RE knowledge domain of the HVAC module design. The HVAC strategy in several contexts in order to get an ever closer generic domain is very complex: it is composed of a large quantity of proposal for requirements engineering, as well as, developing concepts and relationships, and it involves several knowledge software tools to automate some activities of the strategy. areas. The domain was structured and done explicated by the LEL and the entity-relationship conceptual model. These models also 6. REFERENCES helped to visualize the domain from a global perspective. It was [1] T Bahill and J Daniels. 2003. Using objected oriented and noticed that every domain specialist knew the information about his UML tools for hardware design: A case study. Systems or her area, but they ignored information about others. The research Engineering. Retrieved September 20, 2016 from team realized that in order to design the DNA guide document, http://onlinelibrary.wiley.com/doi/10.1002/sys.10033/full every specialized area proposed the attributes they considered [2] Arthur A Bell. 2000. HVAC equations, data, and rules of important, but there was no global vision of the document. thumb. McGraw-Hill. According to FLUTEC engineers, a global perspective of the module would reduce errors caused by side effects. [3] Manfred Broy. 2013. Domain modeling and domain engineering: Key tasks in requirements engineering. In The strategy also helped to reduce the symmetry of ignorance Perspectives on the Future of Software Engineering, Jürgen between the FLUTEC engineers and the research team in a short Münch and Klaus Schmid (eds.). Springer Berlin Heidelberg, time. Reducing the symmetry of ignorance was a key factor in order 15–30. http://doi.org/10.1007/978-3-642-37395-4_2 to improve the communication between the teams and ensure that the analysis of feasibility was effective. Moreover, FLUTEC [4] Betty H C Cheng and Joanne M Atlee. 2007. Research engineers recognized that the research team's knowledge about the directions in requirements engineering. In Proceedings of the design of HVAC modules evolved in a very short time. Therefore, 2007 Future of Software Engineering, 285–303. [5] Gordon B Davis. 1982. Strategies for information foster creativity and innovation for competitive advantage. requirements determination. IBM systems journal 21, 1: 4– Harvard Business Review 69, 6: 96–104. 30. [15] Ikujiro Nonaka, Ryoko Toyama, and Noboru Konno. 2000. [6] R Gacitua, L Ma, B Nuseibeh, et al. 2009. Making Tacit SECI, Ba and Leadership: a Unified Model of Dynamic Requirements Explicit. In Proceedings of the Second Knowledge Creation. Long Range Planning 33, 1: 5–34. International Workshop on Managing Requirements http://doi.org/10.1016/S0024-6301(99)00115-6 Knowledge (MARK) 2009, 40–44. [16] Karla Olmos and Jorge Rodas. 2014. KMoS-RE Knowledge http://doi.org/10.1109/MARK.2009.7 Management on a Strategy to Requirements Engineering. [7] Shivani Goel. 2012. Transformation from LEL to UML. Special Issue on Requirements Engineering in Software International Journal of Computer Applications 48, 12: 975– Product Line Engineering, Requirements Engineering 888. Journal 19, 4: 421–440. [8] Sean Hansen, Nicholas Berente, and Kalle Lyytinen. 2009. [17] Karla Olmos-Sánchez and Jorge Rodas-Osollo. A Strategy of Requirements in the 21st century: Current practice and Requirements Engineering for Informally Structured emerging trends. In Design Requirements Engineering: A Domains. International Journal of Combinatorial Ten-Year Perspective. Springer, 44–87. Optimization Problems and Informatics 7, 2: 49–56. [9] Matthias Jarke, Pericles Loucopoulos, Kalle Lyytinen, John [18] Karla Olmos-Sánchez and Jorge Rodas-Osollo. 2015. KMoS- Mylopoulos, and William Robinson. 2011. The brave new RE: knowledge management on a strategy to requirements world of design requirements. Information Systems 36, 7: engineering. Requirements Engineering. 992–1008. http://doi.org/10.1007/s00766-013-0178-3 [10] J C S do Leite, Ana P M Franco, and others. 1993. A strategy [19] Lukas Pilat and Hermann Kaindl. 2011. A knowledge for conceptual model acquisition. In Proceedings of IEEE management perspective of requirements engineering. In International Symposium on Requirements Engineering Proceedings of the Fifth International Conference on 1993, 243–246. Research Challenges in Information Science (RCIS), 2011, [11] W. Maalej and A. K. Thurimella. 2013. An Introduction to 1–12. Requirements Knowledge. In Managing Requirements [20] Michael Polanyi. 1966. The tacit dimension. University of Knowledge. Springer Berlin Heidelberg, Berlin, Heidelberg, Chicago Press, Chicago, United States of America. 1–20. http://doi.org/10.1007/978-3-642-34419-0_1 [21] Julio Cesar Sampaio do Prado Leite, Jorge Horacio Doorn, [12] Yoshitero Nakamori. 2011. Knowledge science: modeling the Graciela D S Hadad, and Gladys N Kaplan. 2005. Scenario knowledge creation process. CRC Press, USA. Retrieved inspections. Requirements Engineering 10, 1: 1–21. September 20, 2016 from [22] Alistair Sutcliffe and Pete Sawyer. 2013. Requirements https://books.google.com.mx/books?hl=es&lr=&id=jO0Puvp elicitation: Towards the unknown unknowns. In 2013 21st XXygC&oi=fnd&pg=PP1&dq=knowledge+science+modelin IEEE International Requirements Engineering Conference, g+the+knowledge+creation+process&ots=it0iNR0QVg&sig RE 2013 - Proceedings, 92–104. =2jNpJRNNNacjDT4tIamu4d9WGiQ http://doi.org/10.1109/RE.2013.6636709 [13] Lemai Nguyen and Graeme Shanks. 2009. A framework for [23] Diana-Marcela Vásquez-Bravo, Maria-Isabel Sánchez- understanding creativity in requirements engineering. Segura, Fuensanta Medina-Domínguez, and Antonio Information and Software Eechnology 51, 3: 655–662. Amescua. 2012. Combining software engineering elicitation [14] Ikujiro Nonaka and Horitaku Takeuchi. 1995. The technique with the knowledge management lifecycle. knowledge-creating company: How Japanese companies International Journal of Knowledge Society Research 3, 1: 1–13.