A METHODOLOGICAL PROPOSAL TO IMPROVE COMMUNICATION REQUIREMENTS ENGINEERING

UNA PROPUESTA METODOLÓGICA PARA MEJORAR LA COMUNICACIÓN EN INGENIERÍA DE REQUISITOS¹

UMA PROPOSTA METODOLÓGICA PARA MELHORAR A COMUNICAÇÃO EM ENGENHARIA DE REQUISITOS

Jenny C. Ramírez-Leal², William J. Giraldo-Orozco³, Raquel Anaya-Hernández⁴

1 Artículo de investigación científica y tecnológica. Apropiación de técnicas de elicitación de conocimiento y de comunicación personalizadas para potenciar el proceso de Ingeniería de Requisitos, Mayo del 2011 a Agosto del 2013, Universidad EAFIT.
2 Ingeniera de Sistemas y Computación. Magíster en Ingeniería. Profesora de planta del Departamento de Pedagogía y Mediaciones Tecnológicas. Universidad del Tolima. Calle 57 4a 53 Torre B Torreon de Piedrapintada Etapa 1, Ibagué, Colombia / Tel.: 3207190167. Correo electrónico: jcramirezle@ut.edu.co.
3 Ingeniería Eléctrica. Doctor en Arquitectura y gestión de la información y del conocimiento en sistemas en red. Profesor de planta del Programa de Ingeniería de Sistemas y Computación. Universidad del Quindío.
4 Ingeniería de Sistemas. Doctorado en Ingeniería de la programación e inteligencia artificial. Profesor de planta de la Universidad EAFIT.

Paper received: 12-V-2016 / Approved: 12-XI-2016
Available online: February 30, 2017
Open discussion until April 2018

ABSTRACT

Requirements Engineering (RE) involves the knowledge of individuals' situational needs in order to enhance comprehension of leading problems, goals and solution alternatives. This engineering follows a series of stages and tasks which require constant cooperation, coordination and communication among the different stakeholders, while maintaining a variety of perspectives and points of view. Consequently, it poses great communication challenges. This paper proposes a methodological approximation in order to foster better communication among stakeholders during the RE processes. The framework of this approximation is process engineering and communication strategies, yet from the perspective of knowledge elicitation techniques (KET), as well as communication techniques (CT). Given the highly human nature of RE, we will show how this proposal enables the upgrade of communication processes through four stages, namely: (1) identification techniques that contribute to communication, (2) formal specifications of said techniques to understand them in their use, (3) definition of a methodological approximation for RE, (4) application of this proposal on a random sample of a software development companies.

KEY WORDS: Communication; Elicitation of requirements; Communication Strategy; Requirements Engineering; Communication problem.

RESUMEN

La ingeniería de requisitos (IR) involucra el entendimiento de las necesidades de los individuos y sus formas de organización para tener una mayor comprensión de sus principales problemas, metas y alternativas de solución. Esta ingeniería pasa por una serie de etapas y tareas en las que constantemente se requiere colaborar, coordinar y comunicar los distintos stakeholders, entre sí, pero manteniendo distintas perspectivas y puntos de vista lo que plantea grandes retos de comunicación. Este trabajo propone una aproximación metodológica para promover una mejor comunicación entre los stakeholders durante el proceso de IR. Esta aproximación se enmarca en la ingeniería de procesos y las estrategias de comunicación pero desde la óptica de las técnicas de elicitación de conocimiento (TEC) y las técnicas de comunicación (TC). Dada la naturaleza altamente humana de la IR, se mostrará cómo esta propuesta permite potencializar los procesos de comunicación pasando por cuatro etapas, a saber: (1) identificación de las técnicas que aportan a la comunicación; (2) especificación formal de dichas técnicas para comprenderlas en su uso; (3) definición de una aproximación metodológica para la IR; y (4) aplicación de la propuesta en una muestra aleatoria de empresas de desarrollo de software.

PALABRAS CLAVE: Comunicación; elicitación de requisitos; estrategia de comunicación; ingeniería de requisitos; problema de comunicación.

RESUMO

A engenharia de requisitos (IR) envolve o entendimento das necessidades dos indivíduos e suas formas de organização para ter um maior entendimento de seus principais problemas, metas e alternativas de solução. Esta engenharia passa por uma série de etapas e tarefas nas que constantemente se requer colaborar, coordenar e comunicar os diferentes stakeholders, entre si, mas mantendo diferentes perspectivas e pontos de vista o que propõe grandes desafios de comunicação. Este trabalho propõe uma aproximação metodológica para promover uma melhor comunicação entre os stakeholders durante o processo de IR. Esta aproximação se enquadra na engenharia de processos e as estratégias de comunicação mas desde a óptica das técnicas de elicitação de conhecimento (TEC) e as técnicas de comunicação (TC). Dada a natureza altamente humana da IR, mostrar-se-á como esta proposta permite potencializar os processos de comunicação passando por quatro etapas: (1) identificação das técnicas que contribuem à comunicação; (2) especificação formal das técnicas para compreendâ-las em seu uso; (3) definição de uma aproximação metodológica para a IR; e (4) aplicativo da proposta numa mostra aleatória de empresas de desenvolvimento de software.

PALAVRAS-CHAVE: Comunicação; Elicitação de requisitos; Estratégia de Comunicação; Engenharia de Requisitos; Problema de comunicação.

1. INTRODUCTION

Requirements Engineering (RE) is the backbone of the software development cycle involving both technical aspects (Goguen, 2009; Diaper, 1989), and human ones, wherein complex communication dynamics are generated among stakeholders to elicit, specify, negotiate and validate requirements of the system to be constructed (Durán et al., 2003).

Consequently, it is vitally important to improve communication strategies among stakeholders in order to identify and validate correctly and in a timely manner the real needs of the customers and users, thus, avoiding the postponement of defect/error identification that come up from requirements in later stages, which carry a greater correction cost (Boehm, 1984).

There are numerous research projects which have proposed strategies for communication enhancement in RE in order to achieve greater knowledge of requirements of the system to be constructed. Each one of these researchers has his own perceptions and proposes several models from different focuses in order to improve communication problems. Some of these proposals only describe techniques in a general manner (Pytel et al., 2012). In contrast, others compile a conglomerate of techniques without specifying how they are (Carrizo, 2012; Gil, 2010).Finally, other authors have transcended in this type of research, achieving the proposal of technique formalization processes from different contexts, for example (Méndez et al., 2010; Jiang et al., 2008; Hossian, 2013; Carrizo, 2009 y Gómez, 2013).

This research is addressed from software engineering, under the RE context, taking into account the focus of communication enhancement. Each RE phase is analyzed (elicitation - analysis - specification - validation) to identify which knowledge elicitation techniques (KET) and communication techniques (CT) can complement or replace traditional requirements engineering techniques (RET).

To carry out this research, we analyzed problems that come up in the RE process, and subsequently identified which KETs to use to support the process. In addition, we studied the KETs in knowledge engineering whose objective is to elicit, structure and formally represent knowledge extracted from a specific domain for the construction of expert systems or SBC2 (Palma et al., 2000). CTs are also studied. Once these techniques are compiled, they are analyzed to identify how they've demonstrated solving problems via the use of communication strategies. Lastly, a methodological framework is defined which enables integrating KETs and CTs for the enhancement of the communication process in RE.

This paper is organized as follows: section 2 deals with related works. Section 3 depicts the work context. Section 4 addresses the methodological framework of the research. Section 5 defines the conceptual framework. Section 6 describes the methodological proposal for requirements engineering. Section 7 shows the results obtained and the discussion of said results. Finally, there are conclusions, future works and the bibliography.

2. RELATED RESEARCHES

Some authors such as Intille, Zapata, Potts, Maiden, Leite, France and Laguna, among others, have proposed strategies to improve the communication process in RE in order to achieve a better understanding of the requirements of the system to be constructed. Each one of the researchers had his own perceptions and proposed different models from various focuses to improve communication problems. The following solutions are mentioned:

The incorporation of Communication Analysis (Ruiz et al., 2010) methods, a method that proposes a requirement structure based on 5 levels which enable an approximation because of successive refinements. Level 1 breaks down the problem. Level 2 identifies the main business objectives and models each process of the organization by means of diagrams of communication events. Level 3 describes each communication event by means of a specification sheet, and simultaneously, the business objects are specified in greater detail. Level 4 designs the interface to support the communication associated to the events. Level 5 proceeds to develop the logical design and the components for the implementation phase.

Dialogue Model (Zapata & Carmona, 2009). This model specifically attempts to generate a structure for the dialogue in the interview process in order to mitigate time restraint problems, information redundancy, lack of clarity as to what the customer wants, irrelevant information and lack of tools. This way, the model eases oral interaction among people, through information systems.

Creativity workshops though the RESCUE system (Madein y Robertson, 2005). RESCUE is based on the brainstorming technique known as CPS (creative problem solving), which is divided into 3 groups, each one having 2 phases. Group (1) is understanding of the problem: finding the disorder, finding the data. Group (2) is the generation of ideas: finding problems, finding ideas. Group (3) is the action plan: finding solutions, accepting findings. In this project, RESCUE workshops were used succesfully to discover the needs of the intersted parties of the future European air traffic.

"Image-Based Experience Sampling and Reflection" (Intille et al., 2002) methodology. This study proposes this new methodology to assist users at the time of eliciting their needs. In this process, a photo camera is installed in the user's environment in order to capture images, which will later be shown at the time of elicitation in order to help said user describe his processes via a generation of feelings. The aim is to generate a better dialogue among stakeholders.

DDT diagrams (Laguna et al., 2001) are used to elicit verbal information from the domain experts which will enable working with users who do not know how to express their real needs. In this paper, Laguna states it is easier for the expert to structure his daily work through DDT (diagrams-documentstasks) diagrams wherein the different tasks he performs are shown, as well as his production of deliverables. This is not possible in cases of use since they are efficient but only when stakeholders know perfectly how the system will be in the future.

Metaphor use methodology (Potts, 2001) to enhance understanding customer requirements due to cognitive linguistic issues that prove the metaphor is a phenomenon generated in comprehension and communication of all types of abstractions. This paper explains two types of fundamental metaphors that repeat themselves along requirements engineering: (1) rectification of mental abstractions as material substances and containers, (2) specializations of abstractions such as locations, trajectories, relations of space and anthropomorphisms.

All these projects, among others, have improved the communication process in different aspects, such as the mitigation of problems due to time restraints, the removal of redundant information, the increase in clarity of the customer's wants, reduction of irrelevant information, the supply of support tools. In contrast to these proposals, this research proposes a systemic method to incorporate KETs and CTs to the RE process in order to improve communication. Said method is flexible and will be able to be applied in other contexts to incorporate any other type of knowledge acquisition techniques.

3. CONTEXT

This section presents the conceptual model depicted in Figure 1, which expresses key concepts of this project through the use of companies. Each concept is represented in a set of previously identified information within the RE and it is necessary to precise them for clear understanding.

Figure 1

The ontological model of Figure 1 shows that the RE process has 4 activities, which in turn is made up of tasks. The tasks present communication problems (see Table 1) and are supported through RE techniques that can be complemented or replaced by other techniques stemming from of the context of elicitation techniques and the communication techniques (see Table 2) that can help in a certain measure to improve communication problems presented in the tasks.

Table 1

Table 2

• Requirements Engineering Processes: is the process of developing a specification software. Specifications intend to communicate the needs of the client's system to system developers (Sommerville y Sawyer, 2005).
• RE Activity: Depicts the four stages in which the Requirements Engineering process takes place and are as follows: elicitation, analysis, specification and validation.
• Requirements Engineering tasks: is the finest grain of the RE process. The granulation of the process is divided in activities and there are tasks to be carried out for each activity. (SWEBOK, 2001).
• Techniques of Requirements Engineering: is a technique traditionally used in any activity of the RE process. (Sommerville & Ranson, 2005).
• Technique: is understood as a technique, a container of methods that has tasks, roles and artifacts that will be implemented as a pattern of capacity.
• Communication problem: is understood as a communication problem of RE, specifically, when the transfer of tacit knowledge among stakeholders is not satisfactory because of factors such as: poor language use, deficiencies of the environment (noise, discomfort, time, motivation and physical space) (Durán & Bernández, 2003). The consolidated lists of communication problems addressed for solution in this investigation are described in Table 1.
• Communication Strategy: external factor or elements of the communication context in which the technique applications arise and act as drivers to improve communication. They may be a circumstance, element, context or something else that promotes communication. The communication strategies worked on during this research are described in Table 2.
• Level of importance: Denotes the impact of a Requirements Engineering concept facing another one. This paper considers five levels of importance which are observed in the concept model of Figure 1. They are the following: the level of importance an RE technique has to complete an RE task, the affectation level of communication problems in an RE task, the improvement level of communication problems using communication strategies, the presence level of a communication strategy on one or more KETs or CTs, and lastly, the complement level of one KET or CT for an RET. A scale of three importance values is established: (1) to denote a high importance level, (2) medium importance level and (3) low importance level.
• Other techniques: knowledge acquisition techniques coming from contexts, different from Software Engineering. For this particular case, the contexts addressed in our research are knowledge management and communication.

4. METHODOLOGICAL FRAMEWORK

In order to carry out this research, 4 stages were performed as described below:

1. Initial identification of communication contributing techniques. This stage's purpose is to identify KET and CT techniques that will be incorporated in the resulting proposal. Toward that goal, we first identify routine problems of the RE for the purpose of identifying techniques which will significantly contribute to a solution. Subsequently, what each technique consists of is defined in detail and understood.
2. Formal specification of KET and CT techniques. Once all the information regarding each technique is found, a granulated scheme of techniques is defined for the purpose of achieving a formal specification scheme which will enable the understanding of how each one of the techniques will be used.
3. Definition of methodological proposal for RE discipline. An RE proposal is incorporated which includes KET and CT techniques. This enables requirements engineers or analysts to understand how to carry out RE with new techniques to achieve results more effectively at the time of identifying the needs of the software product to be constructed.
4. Application of software development proposals in companies. Once the RE proposal is developed, it is applied in 5 software development companies in the city, for the purpose of proving their validity to strengthen communication among stakeholders. The aforementioned is carried out so that Requirements Engineers can achieve a better understanding of the business domain and the needs thus derived in order to more exactly identify product requirements.

5. CONCEPTUAL FRAMEWORK

The proposed methodology in this research has two focuses. The first is related to the how, addressed from process engineering, in order to complement and/or replace requirements engineering techniques. The second focus is addressed from the research hypothesis (see Figure 1), identifying communication strategies associated to the KET and CT techniques context which can in some way be extrapolated to confront communication problems identified in RE.

Communication strategies are selected from compiled works in the state of the art. For that, two types of extractions are used: direct extraction, that is, directly studying the incidence of these communication strategies in problems found. The second type of extraction is indirect by means of studying how these communication strategies are being solved by CT and KET (see Figure 2).

5.1. Focus from process engineering

This focus comes from Process Engineering and is needed to formalize techniques for the purpose of identifying the technical contributions of KETs and CTs in the RE communication process (through the RETs). To do this, we identify when a method content (in terms of using SPEM to refer to the packaging of a specific process) enriches another (both being the same type). As such, if the source content is a technique, the contribution will strictly be made on another technique (not on a step or a task - STEM terms). Therefore, the RETs will be able to be complemented with other techniques, for this case, KETs and CTs.

Due to the above and knowing that techniques in general can be extrapolated because their origin lies in a specific context, these can be applied in another context. This enables their enhancement so that they can later be applied in their original environment, solving a problem with no previous solution (see Figure 3).

Figure 3

6. FOCUS FROM THE RESEARCH HYPOTHESIS

Following this focus, we identify communication problems during the RE process, as well as communication strategies that can solve said communication problems so that instruments can subsequently be applied, in development companies, to RE experts with the objective of identifying relationships, such as, "supported by," "affects execution" and "is improved/resolved."

Lastly, a decision matrix which establishes the following correlations is proposed: "is present," whose purpose is to define the level of importance that exists among communication strategies and other techniques from the KET and TC contexts. The "complements or replaces" correlation whose purpose is to define the level of importance that exists between other techniques and the RETs.

The aforementioned is so that analysts and requirements engineers can have guidelines to select the KET or CT techniques that can be used during the different RE tasks, this way improving communication in the RE process.

5.2. Methodological proposal for Requirements Engineers

This section briefly presents the methodological proposal to improve the RE communication process from KET and CT techniques. The methodology is composed of 11 stages which show how to incorporate KET or CT techniques to the RE process to complement or replace the RETs. Each stage is described below:

Stage 1. Definition of work breakdown model: four granularity levels are established in this stage to define each technique (RET -KET - CT), one to establish the moment of occurrence (planning/execution/analysis of results), another to describe the technique and encapsulate it, the other two to manage two internal granularity levels (labor/sub-labor). These levels are for the purpose of managing similar patterns and behaviors within techniques which enable recognizing if a task present in 2 techniques with different names, actually corresponds to the same one (see Figure 4).

Figure 4

Stage 2: Identification of RETs. In this stage, the RETs that can be complemented or replaced through KETs and CTs are identified. The RETs are extracted in two ways, the first using the Business Model and Requirements models from the RUP framework and the second making use of literature identifying which is used, reason for which the name traditionals is assigned.

Stage 3: Formalization of RETs. In this stage, each RET is defined making use of the 4 granularity levels established in Stage 1.

Stage 4: Classification of RETs due to RE activities. In this stage, the consolidated RETs collected in Stage 2 are classified according to the 4 requirements engineering activities (elicitation - analysis - specification - validation) where each technique is used.

Stage 5: Identification of KETs and CTs. In this stage, KETs and CTs that might be incorporated in the RE process for communication enhancement are identified.

Stage 6: Formalization of KETs and CTs. This stage enables the consolidated KET/CT, which is defined making use of the 4 granularity levels established in Stage 1.

Stage 7: Elaboration of catalog. Once the RETs, KETs and CTs are formalized, they are included in the framework of SPEM to create a navigation framework over them.

Stage 8: Identification of communication problems. This stage carries out a review to identify communication problems that most greatly come up in the Requirements Engineering process and which are aimed to be resolved.

Stage 9: Identification of communication strategies. Stemming from the compiled work in the state of the art and experiences obtained in these investigations, the identification of communication strategies that can help mitigate communication problems generated during the Requirements Engineering process takes place.

Stage 10: Design and application of the instrument. The instrument is applied to expert personnel in RE in development companies to obtain 3 tables that will measure the importance level that exists among different concepts of requirements engineering.

The first table has to do with the correlation "supported by" and its purpose is to define the importance level that exists among RE tasks and requirements engineering techniques. The questions associated with this table are the following:

Question 1: What is the frequency with which the execution of generic tasks takes place in the RE process?

Question 2: What is/are the RE technique(s) you apply for task execution with an execution frequency of High or Medium?

The second table has to do with the correlation "affects execution" and its purpose is defining the importance level that exists between communication problems and RE tasks. The questions associated to this table are the following:

Question 3: What are the most frequent communication problems in your company?

Question 4: What are the RE tasks that are most greatly affected by said problems?

The third table deals with the correlation and its purpose is to define the importance level that exists between communication problems and communication strategies. The question/instruction associated with this table is the following:

Question 5: Determine, for problems that most frequently appear (identified in above table as A and B), which are the communication strategies that could contribute to the solution of said problems.

Stage 11: Creation of decision matrix. In this stage we carry out the analysis of results obtained in stage 10, in which the correlation "is present" is established. Its purpose is to define the importance level that exists between the communication strategies and other techniques from the contexts of KET and CT and the correlation "complements or replaces," whose purpose is to define the importance level that exists between other techniques and the RETs.

Establishing these correlations, the analyst or requirements engineer can define the KET or CT techniques that can be used according to the needs the Requirements Engineering process has.

For synthesis, Figure 5 shows the definition of the 11 stages defined to achieve the incorporation of techniques to the RE process.

Figure 5

7. RESULTS AND DISCUSSION

Once the methodological proposal for the incorporation of KET and CT techniques is completed, 5 software development companies are defined in the city of Armenia for the purpose of applying the experiment that would validate the proposal. For sample selection, a random sample of 5 software development companies was used. These companies had to completely comply with certain characteristics favoring the application of the methodological proposal. These characteristics are described below:

• Development of custom made development software. It was necessary to make the development of a concrete product available in which a client is in charge of needs specifications to be incorporated. This enabled proving the KET/ CT techniques indicated by the methodological proposal, strengthening communication processes among stakeholders.
• For small companies to carry out the experiment, easy access to company personnel was needed in order to apply said experiment.
• Existence of requirements engineer or analyst. The proposal demands the leadership of a requirements engineer or analyst to be present in the different techniques being incorporated in order to control and define artifacts during the requirements engineering discipline.
• Experience in software product development. The companies chosen must have more than one-year experience in order to corroborate the validation of results obtained. This is done by providing a comparative scenario between acquired experiences in previous projects and the new experience.
• Application of requirements engineering techniques during the discipline. It is necessary to have people with experience in application of RE techniques for the development of a software product. This is necessary for the purpose of having a comparative reference marker with the proposed techniques regarding the veracity of the results obtained.
• Companies beginning the requirements engineering phase. Evidently, the proposal is designed for the RE discipline, for which projects are needed where this stage does not exist.
• Availability of client during experiment application. For the purpose of applying the proposed methodology and subsequently evaluating the veracity of results obtained, it was necessary to count on clients with enough time and interest in participating in the experiment, since, in large part, the initial phase of application of KET/CT techniques depends on the client, as well as the validation of results obtained.
• Companies with small developments. For the sake of carrying out a short term concrete experiment, it was necessary to select small, custom made development projects whose execution would not last more than 4 months. This allows total coverage of the requirements during the execution of the experiment.
• Unknown business domains. The fact that the project development team did not know the business domain tests, the KET/CT techniques demonstrates its strength in easing the communication process among stakeholders, making the experiment more appropriate.

More companies are not necessary, since the execution of the methodological proposal predominates in a random sample where stakeholders were available, this way proving the validity of the proposal and its potential to understand the clients' needs.

7.1. Experiment design

The design of the experiment is characterized by each selected software development company stemming from 7 criterion described in Table 3. The purpose is to identify with which KET and CT techniques the methodological proposal must be validated. To that end, an experiment consistent in six activities is designed for each company: (1) identification of development project, (2) filling out the KET/CT planning sheet, (3) establishment of execution plan, (4) definition of results, (5) group panel for feedback, (6) analysis of results. It must be noted that results obtained are not published, since companies express the need for confidentiality of said information, considering it competition sensitive.

Table 3

1. Identification of development project. Selection of a project from all other projects development company is responsible for. This project has the following characteristics: defined scope, execution of requirements engineering discipline and availability of clients.
2. Filling out KET/CT planning sheet. Each company identifies in the planning sheet (see Table 4), the specific communication problems they have had in Requirements Engineering in previous projects. Once each company's problems have been identified, the KET/CTs required to mitigate the problem are selected, taking into account the characterization of communication strategies each technique implements (see Table 5).

Table 4

Table 5

3. Establishment of execution plan. In this activity, we define sessions for the application of the methodology proposed (see Table 6). Each encounter must include: activities, duration, person responsible, observations found and stakeholder approval for the purpose of committing them to actively participate in the process.

Table 6

4. Definition of results. Describes in detail results reached in each session and the artifacts obtained from the focus of the technique: lotus flower, conceptual framework, incident description, storyboard, among others, or from a discipline focus: case use diagram, user history, requirement specification document, case use specification document, among others (see Table 7). The above, for the purpose of having evidence of artifacts that will be evaluated later with the requirements engineer and/or clients. When the evaluation of clients corresponds to several, it is necessary to execute a weighted average of each one.

Table 7

5. Carrying out of group panel feedback. The following topics are addressed with all stakeholders on board: pertinence of methodological proposal, application time and observations found during each one of the sessions. In order to obtain more concrete results during panel development, a moderator directs stakeholders to concrete questions, which stakeholders must respond by way of a quality scale: High (H), Medium (M) or Low (L) according to their experience in each one of the sessions. Later, at panel end, 10 minutes are allowed for stakeholders to present comments they considered pertinent, achieving a consolidated document per topic. See results on Table 8.

Table 8

6. Analysis of results. We proceed to analyze assigned scores in the following cells: validation of customer and validation of requirements engineer responsible for the table of results (see Table 8), which enables validating the exactitude of obtained artifacts during the application of the experiment, all with the intention of appropriately identifying the needs of the software product to be built. Each one of these classification focuses are oriented from a different perspective. On the one hand, requirements engineer leaders evaluated whether the artifacts were pertinent for the RE discipline. On the other hand, clients who are more suited, evaluated whether the identified requirements were what they really needed. These results are shown on Table 9.

Table 9

In the results of validation of obtained artifacts, once techniques have been applied, we can evidence that clients are more satisfied on a general level than requirements engineers. This may be because of the latters' greater cultural gaps regarding traditional methods.

It is satisfying to find that between 95 and 97% of customers from all companies gave high points to approximation and quality of results obtained at the end of the experiment, and that none gave results found low points. This enables us to conclude that the proposed methodology achieved the strengthening of communication processes among stakeholders to achieve quality results.

The aforementioned shows that the proposal achieves more efficiency than traditional methodologies to apply requirements engineering, since it enables both the use of new techniques and descriptively guides on how to apply them, as well as when to do so in terms of communication strategies. Additionally, this shows that stakeholders will commit more to the process using these techniques, feeling more satisfied with the obtained results.

8. CONCLUSIONS AND FUTURE WORK

The achievement of this paper shows, as a result, a new methodology approximation to incorporate knowledge acquisition techniques to the Requirements Engineering process, this way improving communication among stakeholders. Although, this paper only studies knowledge acquisition techniques from the contexts of knowledge management and communication, it is alsopossible to incorporate techniques from other contexts in this methodology, as long as those techniques favor communication.

By executing this methodology in software development companies, we intend to correctly guide the acquisition and transfer of clients' needs in the Requirements Engineering process, favoring the exchange of experiences in an adequate environment where all persons involved feel safe and freeto express their ideas, making use of communication strategies which will minimize communication problems that may present themselves.

It is important to take into account that a KET/CT can implement several strategies and that a strategy may contribute a solution to several problems. This way, we found that 50% of communication problems are solved with at least three communication strategies, which indicates that various alternatives exist to mitigate communication problems since several KET and/or CT techniques present these communication strategies.

This research achieved a consolidation of 24 knowledge elicitation and communication techniques with information with reference to the following: description, resources, artifacts, roles, objectives, tasks and sub-tasks. Thanks to this data collection, a public catalog of techniques for easy consultation was created, contributing to the general community and easing comprehension and communication among stakeholders who participate in the process, supplying requirements engineers from each company with a guide to support decision making regarding KET and/or CT.

Lastly, the use of KET and CT assumed considerable innovation for experts during the proposal's validation process. The experience can be considered positive since, although experts might not have learned what each technique consists of, they do know the importance of communication abilities in this process, as well as the existence of useful techniques to foster these abilities. Notwithstanding, the doubt persists whether the balance achieved is enough so that experts may, in practice, assertively select the technique to be applied in a project.

REFERENCES