=Paper=
{{Paper
|id=Vol-1784/w3
|storemode=property
|title=Eliciting Requirements for Industrial Design Using the Knowledge Management Strategy for Requirements Engineering
|pdfUrl=https://ceur-ws.org/Vol-1784/w3.pdf
|volume=Vol-1784
|authors=Karla Olmos-Sanchez,Jorge Rodas-Osollo,Alberto Ochoa
}}
==Eliciting Requirements for Industrial Design Using the Knowledge Management Strategy for Requirements Engineering==
https://ceur-ws.org/Vol-1784/w3.pdf
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.