The Use of Cognitive Maps for Requirements Elicitation in Product Development

ABSTRACT

This article approaches Engineering Requirements concepts and proposes the use of cognitive maps as support to the problem identification of the stakeholders during the requirements elicitation process. It presents a case study of the aerospace cluster of São José dos Campos, State of São Paulo. The cognitive map technique was developed to represent the views of the individuals, generating cognitive maps, which, in an aggregated way, express graphically the collective vision to support the decision-making process. Applied to Engineering Requirements, it has revealed the potential to promote the convergence of different points of view on the actual stakeholders’ needs in innovative fashion. This technique has demonstrated effectiveness when approaching the stated requirements early in the development process implemented throughout the life cycle of the system/product.

Keywords
Cognitive map; Engineering Requirements; Decision making; Knowledge representation

INTRODUCTION

Engineering Requirements (ER) emphasizes the use of systems and techniques that ensure the completeness, consistency, and relevance of the system requirements (Sommerville 2006). It is a comprehensive area for product development, especially software, which has proven a sensible growth resulting from the valuation requirement, and it is an essential element of the development process (Martins 2001).

The main phase of the product development cycle is the survey of stakeholder’s needs, in which the problems are identified involving them and the developers. Most difficulties are associated with the understanding among these individuals, being the developers responsible for the elicitation of the requirements of the future product. It is common to find rework, schedule delays, changed costs, and dissatisfaction on both sides, caused by a deficiency in the elicitation phase requirements. During the validation phase, developers confirm that the specified requirements correspond to the stakeholders’ demands and their real needs. Revisions and checklists, as techniques to support the validation process, are performed. The requirements will be reviewed, and the problems, identified and remedied.

Some common problems are (Kotonya and Sommerville 1998):

• Lack of compliance with quality standards

• Poorly designed, ambiguous, and confusing requirements.

• Errors in the system model

• Conflicts between the requirements, which have not been detected and treated in the analysis phase

The detailed analysis phase allows obtaining the complete awareness of the problems and the most important requirements, although there is the possibility of changes over the development process, demanding intense interaction in the process to impact as little as possible the activity of later stages. Structuring the decision-making environment to identify problems of aeronautical products that developers face — during the requirements gathering with stakeholders — was highly motivating because we glimpse the possibility of creating a scenario that would allow extracting a model to minimize the deficiencies that generally occur at this stage.

The cognitive map is a very useful tool to structure problems in decision-making processes (Gomes et al. 2010) as well as to organize and represent knowledge (Novak and Cañas 2008). The survey of requirements for product development demands effective representation of knowledge in order to not produce errors throughout the development cycle. Santos et al. (2011) reported that the cognitive map has been widely applied in various types of problems: academic, environmental, research project management and others.

The issue addressed in this paper is focused on the difficulty in solving problems related to the elicitation of knowledge during the survey of requirements for product development targeted at the aerospace sector in São José dos Campos, State of São Paulo. The cognitive maps were used for the structuring of knowledge in order to identify the problems that occur in the elicitation of requirements for product development. A cognitive map lends itself to the detection of problems, profiles, and requirements for product development in general.

The development of targeted products for aerospace is complex, and cognitive maps, in such contexts, serve to assist in the elicitation of issues and problem convergence points in the development cycle of these products, particularly the requirements definition. The study was directed to the Aerospace Cluster at São José dos Campos. This sector is the most contributing to the Gross Internal Product (GIP) of the city, and it is important to assess the applicability of the tool in unconventional products. The GIP of São José dos Campos is the largest in the Paraíba Valley and northern coast region, the eighth largest in the State of São Paulo and occupies the 19th nationwide position. The industrial sector, a predominant feature in the city, accounts for 70.52% of the total municipal economic profitability. São José dos Campos is an important technopole of ordnance, metallurgy and home to the largest aerospace complex in Latin America (Agoravale 2012). The city has great participation in foreign trade, being the second largest municipal exporter of manufactured products of Brazil. The Embraer Company appears as one of the main exporters of São José dos Campos.

The aim of this study was to demonstrate the efficiency of cognitive maps as a support to ER for identification and problem structuring associated with surveys of requirements in the development of products for the aerospace sector.

METHODOLOGY

Regarding the preparation and analysis of the maps, we followed the theories and recommendations described in the literature published by the authors Ensslin and Montibeller.

Initially, an individual approach was carried out through interviews with each decision maker separately. The interviews were conducted in a neutral environment for both the decision makers and the facilitator, lasting between 60 and 90 minutes. Besides the interviews, additional information was requested to the suppliers about the description of the main difficulties faced by them concerning aerospace products in clustered environment in the city of São José dos Campos. It was asked to all decision makers to establish label(s) to the relevant problem(s), with total freedom of expression.

The interviews took place in an atmosphere of spontaneity, collaboration, and trust in everyone involved. The facilitators, taking into account the issues and the environment in which the cognitive process was carried out, concluded that:

• Freedom of expression and informality contributed greatly to the rapid development of the work

• During initial interviews, it was necessary to refocus in order to keep the line of reasoning in the issues raised by decision makers

The hypothesis is that the cognitive maps lend themselves to improve the survey of process requirements, identifying impactful problems. The understanding of the systematic development was confirmed, as it was possible to identify and structure the difficulties encountered during the requirements elicitation process.

THEORETICAL FOUNDATION

ENGINEERING REQUIREMENTS

The purpose of ER is to capture, analyze, validate, and refine requirements for the development of a system using tools that assist in the identification and management of requirements detailing process.

There are dictated guidelines for ER, such as the Electronic Industries Alliance standard (ANSI 632) and that of the Institute of Electrical and Electronics Engineers (IEEE 1220-2005), among others.

The requirements are attributes of a system to identify the capacity and quality factors that prove the usefulness of the product to the customer or user (Young 2004). The classification of ER can be:

• Business: line product/system for the stakeholder’s business goals

• High-level: reveals the stakeholders’ vision and is described in their language

• Function: defines the functions that the system/product should meet

• Performance: defines the performance standard required by the customer

• Interface: defines the operability standard

• Verification and validation: defines the degree of compliance with the stakeholders’ requests

The requirements specification comprises the list of features that stakeholders wish to see implemented in the system. The specification is developed using the stakeholder’s language. It is necessary that the requirements submitted for analysis are translated into technical language (low level), expressing the role of each component of the system to meet the stakeholders’ needs (Azevedo Junior and Campos 2008).

The ER process consists of four main steps: survey and elicitation, analysis and negotiation, modeling, and validation. These steps occur iteratively and recursively due to changes that occur during the development process, as can be seen in the spiral model shown in Fig. 1.

Figure 1
Spiral Engineering Requirements process (Alves 2007).

The requirements which are translated from the original form to technical jargon are called “transferred requirements”; in the case of new requirements, they will be called “derived requirements”. The characteristics of the requirements are:

• Traceability: checking and validation of the low-level requirements, identifying the service for client’s requests

• Evolution: changes over detailing and change of status at each new modification, making the requirement defined, approved, allocated, designed, implemented, tested, and verified

• Allocation: requirements must be allocated where they are needed in the system

Requirements analysis consists of activities to fulfill the initial phase of the system’s life cycle. The following activities are part of this phase (Kotonya and Sommerville 1998).

Identification and Survey Requirements

In this phase, it is carried out the extraction of requirements through consultations with stakeholders, as well as of documents, domain knowledge, and market studies. The activities involved include:

• Understanding of the domain: effective communication between the developer and the stakeholders

• Capture: extraction of the desired requirements through interaction with stakeholders

• Identification and analysis of problems: joint description of problems and solutions

Analysis and Negotiation of Requirements

The detailing and analysis activity may be rejected or accepted. It is possible to use description of use cases based on templates that list the relevant information required for each user (Kulak and Guiney 2000). Some of the activities involved in requirements analysis include:

• Rating: grouping requirements in “modules” to facilitate global vision of the desired operation of the system

• Conflict resolution: resolving conflicts in the requirements found during the identification of the same process

• Prioritization: assignment of “priority” to each requirement.

• Confirmation: confirmation of completeness, consistency, and validity with stakeholders

González et al. (2007) suggest the decomposition of goals from business models trees that will guide the extraction of requirements while maintaining alignment with the business strategy of the institution.

Modeling the Requirements

Specification and documentation formalize the requirements accepted at a level of appropriate detail. In all specification types, there are two kinds of requirements:

• Functional requirements: describe the features that one would expect for the system to operate fully and consistently, meeting the purposes for which it was developed

• Non-functional requirements: describe the non-functional aspects of the system, such as restrictions in which the system must operate, or its emergent properties. They are divided into non-functional utility, confidence, performance, support, and scalability

The specification results in the requirements specification document include a combination of requirements of the several stakeholders. The usefulness of this document can vary, as each one involved in the process (Kotonya and Sommerville 1998; Sommerville 2006):

• Customers: confirm the completeness and request changes

• Managers: budget the planning and the development system

• Development engineers: understand the system that is being developed

• Test engineers: design and implement tests for validation

• Maintenance engineers: understand the system and the interdependence of its parts

Validation of Requirements

At this stage of validation, the specified requirements are checked and confirmed by decision makers in order to perfectly reflect the stakeholder’s requests. Reviews and checklists assist in the implementation of the validation process, which involves all stakeholders in order to identify the description of problems and ambiguities. Completed this phase, it is possible to admit that there is a leveling of knowledge related to system requirements, although modifications may be required throughout the development process (Alves 2007). The identification and analysis of requirements is an iterative process that begins with the familiarization with the domain of the future system and culminates in confirmation requirements by increasing the understanding level of the system at every stage of the development cycle. The management of the requirements deals with the control of environmental changes throughout the development. The requirements specification precedes the scoping and cost estimates as well as timelines, so obviously the changes in the requirements basis cause impacts and provide the critical situations in the project. The requirements are continuously changing, either by incomplete definition of the problem addressed prior to completion of the requirements document or by changes in the requirements during the project, due to technological developments or due to the organization changes in which it will be used.

The resolution of conflicts between the requirements seeks balance in meeting the needs of different stakeholders. Planning is an important part of the requirements management. The policies for the aspects described next shall be defined at the outset of the project:

• Change management: a set of procedures to assess the cost and impact of the changes

• Treatment of requirements: procedures for processing requirements iteratively throughout the system’s development cycle

The requirements validation activity culminates in the requirements document, which has the contract value in the form of client-supplier “service-level agreement”. This document will guide all efforts of the following stages of the product’s life cycle. It should be objective and clear to avoid rework, cost increases, and implementation effort. The identification of system characteristics has as main difficulty the communication factor. Roger Pressmann (2006) illustrates this problem with a statement from a client to an analyst: “I know you believe that you understand what you think, I said, but I’m not sure we realize that what you heard is not what I meant”.

COGNITIVE MAP

The methods of problem structuring emerged in the 1980s, in order to reduce the difficulties and limitations inherent to the use of quantitative tools available for operational research (Mingers and Rosenhead 2004; Rosenhead 2006; Mingers 2011; Ackermann 2012).

Several methods of problem structuring appeared to support the lifting process and representation of the views of those involved in a particular problem, in search of a consensus to improve the negotiation and decision-making processes (Manso et al. 2015).

The Strategic Options Development and Analysis (SODA) (Ackermann et al. 1989, 2002, 2010) is a method of structuring and problem identification (Ackermann et al. 2004). The cognitive map is one of the SODA tools whose purpose is to identify and elucidate problematic situations through a record of concepts and their meanings, in a hierarchical structure, grouping them according to similarities in individual’s views (Ackermann et al. 2002; Ackermann 2012).

According to Cossette and Audet (1992), cognitive maps are graphical expressions of speeches made by individuals or groups of individuals in order to demonstrate objects in contexts of particular interactions. The graphical representation is the result of mental interpretation of the individual’s viewpoints captured through conversations with stakeholders about a particular problem. The facilitator should remain neutral throughout the discursive-reflective-recursive process, in order to not interfere in the map development, although the total neutrality is virtually impossible. This is because the facilitator needs to interpret and build events based on his concepts of values and subjective view. In the cognitive approach, the problem is identified, detailed and analyzed through an interaction process between the facilitator and the stakeholders, in search of a precise definition, admitting the intersubjectivity of the individual or group. Thus, cognitive maps can be used to resolve conflicts of views in the requirements of the systems development process and are shown to be very useful both as a product and as a tool. These maps have dynamic character and are adjusted to each change requested by stakholders.

Ackermann et al. (2004) suggest that the cognitive map can be built through transcripts of interviews as well as other documents for review and understanding of the information. Iederan et al. (2011) recommend that the transcripts of the interviews are analyzed based on five dimensions: organization, processes, causes, consequences, and obstacles.

According to Cossette and Audet (1992), the components of cognitive maps can be:

• Identity: determination of the key of the problem (events, processes, and actors)

• Categorization: definition of scales and profiles revealing the relationships between the entities

• Cause or reasoning: presentation of alternatives to change the status or position on the map (argument lines)

Cognitive maps can be:

• Organizational: collective map that represents a support tool for organizational actions

• Individual: individual map, isolated, used for the construction of collective maps

Construction of Individual Cognitive Map

The construction of a cognitive map depends on two factors:

• Initial approach by the facilitator, demonstrating empathy

• Establishment of a negotiation process

Interviews should be spontaneous, with the interviewed exposing his viewpoints and all information about the problem. This is because the body language and reactions constitute relevant information for the facilitator with regard to the problem. The cognitive map is a hierarchy of concepts related by connections between the means and ends which represent the decision makers’ value system in the form of strategic objectives located at the top of the hierarchy.

The process of knowledge extraction is exhausting; for this reason, it should not exceed 90 minutes per meeting. The mapping process consists of four steps as described next (adapted from Eden and Ackermann 1998; Ensslin et al. 1998; Montibeller Neto 1996; Montibeller Neto and Belton 2009):

• Step 1: definition of a label for the problem. Meetings between facilitator and decision makers should occur to define a label for the problem based on material issues raised by decision makers

• Step 2: definition of the primary elements of evaluation. The Primary Elements Assessment (PEA) represents the objectives, goals, values, actions, alternatives, as well as decision makers’ worries, and are defined from interviews between facilitator and decision makers

• Step 3: construction of the concepts from the PEAs. The concepts are transformed into actions and organized by similarities and hierarchical constructs by subordinates and superiors

The structure is represented by individual constructs hierarchically organized. To guarantee the correctness of the facilitator’s perception about the respondents’ information, it should be used the psychological opposite pole, explicitly or not, to construct the maps. In general, the facilitator adopts the decision makers’ description obtained from the first perception that comes to mind, whether positive or not. Some guidelines can provide orientation throughout the process of constructing concepts, constituting a good strategy (Eden and Ackermann 1998):

• Each concept must be clear, concise, action-oriented, and expressed by a sentence

• Decision makers’ words and expressions should be preserved in the stakeholder’s language

• The values, options, means, and ends should be identified

• The decision makers should be stopped whenever the facilitator cannot log their perceptions, but the reasoning line should be preserved

• The concepts that represent strategic objectives and/ or the most important goals for the decision makers, which may represent strategic actions, must be identified on the top of the map

• The concepts and their relations with another concept, as well as others expressed by emotionally decision makers, should be explained and justified

• These words should be avoided: how, can, must, and shall

• The validation of the map should be done as soon as possible

• Step 4: The concepts hierarchy and analysis of the map

The structure of cognitive maps is composed of concept purposes, identified by the question “Why this concept is important?”, and concepts identified by means of the question: “What are the reasons that explain this concept? How can it be achieved?”. The process continues until decision makers answer that the concept is important because it is essential, revealing that the highest hierarchical level of the map was achieved.

The concept related through links of causality, peer-topeer, is represented by arrows. A situation may arise where an objective order can be explained by more than one intermediate, conflicting goal. In this case, Ensslin recommends the use of multi-criteria analysis.

Clusters Identification

The cluster is a graph composed of a set of interconnected nodes. Its identification provides a macro view of the map and reduces the complexity. The strongest links are highlighted and provide a view of grouping of concepts in specific areas of interest, allowing an analysis of each cluster, alone. The detection of Fundamental Points of View (FPV) is performed by observing the map topography. It is noted the set of lines in the graph. These lines form the axes of the problem evaluation. The branches analysis of the graph structure searches for paths that lead to the end-concept of the problem. These paths, called argument lines, are composed of concepts that are influenced and are in a hierarchical position superior to a mean-concept. The map branches are composed of argument lines representing content similarity in relation to the decision environment (Ensslin et al. 1998, 2001).

Identification of Fundamental Points of View

The FPV are the basis for actions that culminate in decision making, as the choices between alternative options. They bring the most important figures in the environment, for decision makers, anticipating the consequences of the actions. The definition of FPV, taken from the environment map, determines for each branch:

• The concepts location related to strategic thinking of decision makers

• The concepts location that reveals potential actions

• The location of the concepts that reveal ideas related to the FPV candidate

As one increases the degree of control over the view of decision makers, it is important to take into account actions that influence such FPV in that branch. The controllability and completeness concepts must be verified in the analysis of the ends-means objectives.

Construction of the Congregated Map

When the context requires more than one decision maker, it is necessary to build the collective cognitive map. Although the decision making power is shared, the interests may conflict due to representation of different areas as well as differences in profiles (Ensslin et al. 1998).

The collective cognitive map is called “aggregated cognitive map” and can be:

• Initiated directly with the group

• Started from individual cognitive maps

If the survey is incomplete, a quality loss will occur and will affect the analysis later.

The aggregated map can be drawn by observing the following steps:

• Aggregation of individual maps: through the union of similar concepts, it should be unified by the concepts with the widest sense (Eden and Ackermann 1998)

• Connection between concepts: connecting the concepts through influence links

The aggregated cognitive map is achieved through negotiation between the facilitator and stakeholders. Once the aggregated map is drawn, with the evidence of contribution of each individual decision maker, this should be submitted to the group which will negotiate the inclusion or exclusion of concepts as well as their respective influence links for the “new” setting until obtaining a representative map of the values of decision makers, which generates a collective cognitive structure called congregated cognitive map. The analysis of these elements can lead to the establishment of actions that converge to the solution of problems by improving the performance of product, processes, and systems development.

CASE STUDY

Minimizing problems must be an intense interaction among stakeholders in defining requirements, which is the basis for implementation of the entire system’s life cycle. The biggest challenge is the elicitation of knowledge in order to fully understand the stakeholder’s needs, translating them in the requirements form. Requirements that do not correspond to the actual customer’s needs, those incomplete, and changes in the already defined requirements are issues that provide reworks, dissatisfactions, and burden projects. In general, the requirements change during the system’s development, and, for this reason, it is necessary to set the standards very well, dominating, conceptually, the problem to be analyzed and solved (Dias et al. 2006).

Theories and recommendations described in the literature published by Ensslin and Montibeller, as well as individual approach, with the construction of the cognitive map by interviewing each decision maker, were used.

The research hypothesis was: the cognitive maps lend themselves to improve the process of gathering requirements, identifying impactful problems and allowing the problems structuring detected in the process of ER.

TOOL USED TO PRODUCE THE MAPS

The IHMC CmapTools software, a graphic organizer as well as a tool support to create, edit, share, browse, and comment on concept mapping, was used. It is software for authoring concept maps developed by the Institute for Human Machine Cognition, University of West Florida (Marinho 2008).

CONSTRUCTION OF THE MODEL

For this case study, two customers with demonstrated expertise in rockets and aircraft development were chosen. One of the customers, with experience as a contractor, was interviewed also in supplier condition. The other vendor acts on the development of aeronautic computation. External influences were represented by the professional market and competition with another company in the industry. Four cognitive maps were constructed. The profiles of the two clients and the two suppliers are described next.

• Client 1 – rocket: professional development area in products and systems engineering in the space. Systems development engineer for nine years, university professor of the discipline of Engineering and Management Requirements, and avionics engineer for two years. Master in Mechanical Engineering — production work in requirements specification.

• Client 2 – aircraft: Professional Products and Systems Engineering Development area in the aeronautics field. Experience in specification requirements in order to pay for the development.

• Supplier 1 – aircraft: professional development products and systems engineering in the aeronautic field. Significant experience in product development from customer’s requirements.

• Supplier 2 – aeronautical computers: professional development products and systems engineering in aerospace. PhD in Space Technology, Space Mechanics and Control, active in company focused on development of spacesystems for eight years, acting as a leader of avionics software development team and as engineer avionics systems. Expert in product development from customer’s requirements.

Context Decision

It is the phase of the survey requirements in the aerospace environment of São José dos Campos. The aerospace defense sector operates in the design, manufacturing, marketing and maintenance of aircraft, as well as spacecraft and defense rockets, characterized as an activity related to the economic sector of the aviation industry and space, connected to the activities of military equipment supply that cause high economic impact for the region in which it operates.

Structuring the Model

The individual meetings with the clients and the suppliers were performed. Each decision maker shared his experience about the problems that usually occur in the requirements elicitation process. The advantage of the individual interviews was that each decision maker was not influenced by the ideas of the others. Decision makers talked about their values, experiences and, although their vision on relevant aspects of ER was differentiated, all of them agreed in one main goal which is to develop the product to meet the stakeholders’ needs. Even with this same goal, the map was enriched due to the different concepts, as critical issues were addressed in ER, which is observed in the heterogeneity of the clusters. The result was to obtain a more comprehensive problem view in the area. This can be seen when one looks at the amount of concepts that were united with other similar, and, of a total of 81 concepts, only three were gathered (marked with gray boxes in the assembled map), in addition to the main objectives to produce a system and meet the stakeholder’s needs. The great majority of related concepts are influenced by links. To make the clusters, we chose to include the ultimate goal in each one, aiming to carry out the analysis as a single map

Step 1: define a problem label.

In the first meeting, it was asked to decision makers to inform a label aiming at defining the main objectives. It is important to note that one of the suppliers provided information through a text, since he did not have time to attend all meetings.

The following labels were chosen by the customers:

• Manage the requirements deployment from the beginning of the problem

• Satisfy customer’s needs

Regarding the developers, the chosen label was:

• Ensure quality requirements

Step 2: definition of the primary elements of evaluation.

At the end of the first meeting, it was requested to every decision maker to reflect on aspects they considered important when faced with problems in ER, allowing the preparation of the list of Primary Evaluation Elements (PEE), shown in Table 1.

Table 1
List of Primary Evaluation Elements.

Decision maker	Primary Evaluation Elements
Client 1: rocket	Different processes of requirements elicitation can be a problem if not properly managed Issues of communication Changes — management/impact of changes Requirements Management System
Client 2: aircraft	Not always the company captures the client’s wish The process dynamics — the customer wants something today and tomorrow (changes in the application) Cultural factor Requirements with errors
Supplier 1: aircraft	Poor quality requirements Non-specified requirements Errors in communication
Supplier 2: aeronautical computers	Training Improvement of the processes of requirements elicitation and integration with other business processes Choosing the right tool for the management and requirements management Basis of stable requirements

Step 3: construction of the concepts from the PEE.

At the first meeting, initial concepts were developed for each PEE action in each trial, indicating important aspects for consideration in the decision context.

Step 4: hierarchy of concepts and analysis of the maps.

Facilitators conducted the first version of the individual maps based on the information gathered at the meeting. Four maps were constructed, two for customers and two for suppliers. Decision makers were asked about the importance and how to achieve the actions expressed by the informed concepts, revealing the sequences of means-ends actions and the relations of influence, formalizing the topography maps. If two or more concepts are positioned at the same horizontal line, it does not mean it will be the same hierarchical level. From the initial concepts were developed concepts “means” and “ends”, resulting in a total of 87 concepts, as shown in Table 2.

Table 2
Concepts drawn from the initial ones.

Decision maker	Number of elaborated concepts
Client 1: rocket	23
Client 2: aircraft	21
Supplier 1: aircraft	18
Supplier 2: aeronautical computers	25
Total	87

The maps were sent to each decision maker to confirm the orientation of the actions which agree with their views. For the second time, the maps were sent to the decision makers, but now they were sent for elimination of redundant concepts and identification of the resulting cluster. The analysis resuted in 79 concepts and eight clusters.

Collective Cognitive Maps or Aggregated Maps

The individual maps were validated, and their concepts were aggregated in clusters to represent what the group deemed important to observe in the analysis of the difficulties faced in the ER. The individual maps were unified to form the aggregated group maps, which were sent to the decision makers, resulting in the congregated map (Montibeller Neto 1996).

The decision makers were free to make changes in the concepts and in their influence relationships. The facilitators analyzed the changes inserted and the alterations made, sending the new aggregated map for the final validation group.

1. Analysis of the maps — identification of clusters

   The validated aggregated map was analyzed to identify strategic areas of the decision makers’ interest, forming the congregated map. The concepts were grouped by similarity. Table 3 shows cases of concepts belonging to more than one cluster and helped in the identification process of existing common clusters in each map. The result of this analysis is presented by the cognitive map shown in Fig. 2.

2. Argumentation lines on the congregated map

   The lines were identified through the composition of concepts respecting the organization of the map concerning the influences and hierarchies, taking, as starting point, the terminal concepts, called “tails”, and directing them to the ones that represent the main objectives, called “heads”. Table 4 shows the argumentation lines detected in the topology of the congregated map. These argumentation lines are shown also, by the branches denominated B1, B2, B3, B4, B5, B6, B7, B8, B9, B10, B11 and B12 in the Fig 2.

3. Branches on the congregated cognitive map

   Based on the argumentation lines, we seek to detect the branches of the map, i.e. the set of argumentation lines that congregates similar concerns in the context. Table 5 shows the branches identified in the analysis in the congregated cognitive map, and shown in the Fig. 2 as lines of argumentations.

4. Tree of Fundamental Points of View

   For identification and analysis of the FPV, we used Ensslin’s theory based on the type of cognitive map: “causal map or influence”. As mentioned earlier, the cognitive map is a hierarchy of concepts related by links of influence between means and ends (Montibeller Neto 1996). The clusters are essential and desirable aspects to be taken into account during the assessment of actions for prioritization of the problem. Thus the candidates for the FPV of the model were identified from the congregated map and have been validated through the identification of “clusters”. The candidates for FPV of the model were identified from the congregated map and validated, already with the identification of “clusters” (Montibeller Neto 1996; Ensslin et al. 1998).

Table 3
Common clusters on maps.

Cluster	Client 1	Client 2	Supplier 1	Supplier 2
Needs	X			X
Changes	X		X
Quality		X
Communication		X
Knowledge			X
Process			X
Tools			X	X
Management				X

Figure 2
Congregated cognitive map with the clusters definition.

Table 4
Argumentation lines.

Cluster	Argumentation lines	Sequence of concepts
Management	A1	C74 - C72 - C71 - C70 - C69 - C37- C36
	A2	C73 - C71 - C70 - C69 - C37- C36
	A3	C79 - C78 - C77 - C75 - C70 - C69 - C37 - C36
	A4	C79 - C78 - C77 - C75 - C68 - C37 - C36
	A5	C79 - C78 - C77 - C76 - C37 - C36
Knowledge	A6	C62 - C61 - [C57] - C75 - C68 - C37 - C36
	A7	C62 - C61 - [C57] - C75 - C70 - C69 - C37 - C36
	A8	C62 - C61- C58 - C56 - C37 - C36
	A9	C62 - C61 - C58 - C55 - C37 - C36
	A10	C62 - C61- C60 - C59 - C54 - C37 - C36
Tools	A11	C52 - C50 - C48 - C37 - C36
	A12	C52 - C50 - C49 - C37 - C36
	A13	C52 - C51 - C49 - C37 - C36
	A14	C52 - [C53] - C67 - C66 - C65 - C63 - C37 - C36
	A15	C52 - [C53] - C67 - C65 - C63 - C37 - C36
	A16	C52 - [C53] - C67 - C64 - C65 - C63 - C37 - C36
Process	A17	C67 - C66 - C65 - C63 - C37 - C36
	A18	C67 - C65 - C63 - C37 - C36
	A19	C67 - C64 - C65 - C63 - C37 - C36
Needs	A20	C29 - C26 - C24 - C23 - C33 - C21 - C20 - C19 - C18 - C37 - C36
	A21	C29 - C26 - C25 - C23 - C33 - C21 - C20 - C19 - C18 - C37 - C36
	A22	C31 - C26 - C24 - C23 - C33 - C21 - C20 - C19 - C18 - C37 - C36
	A23	C31 - C26 - C25 - C23 - C33 - C21 - C20 - C19 - C18 - C37 - C36
	A24	C30 - C26 - C24 - C23 - C33 - C21 - C20 - C19 - C18 - C37 - C36
	A25	C30 - C26 - C25 - C23 - C33 - C21 - C20 - C19 - C18 - C37 - C36
	A26	C28 - C26 - C24 - C23 - C33 - C21 - C20 - C19 - C18 - C37 - C36
	A27	C28 - C26 - C25 - C23 - C33 - C21 - C20 - C19 - C18 - C37 - C36
	A28	C27 - C26 - C24 - C23 - C33 - C21 - C20 - C19 - C18 - C37 - C36
	A29	C27 - C26 - C25 - C23 - C33 - C21 - C20 - C19 - C18 - C37- C36
	A30	C32 - C21 - C20 - C19 - C18 - C37 - C36
	A31	C35 - C34 - C33 - C21 - C20 - C19 - C18 - C38 - C37 - C36
	A32	C22 - C21 - C20 - C19 - C18 - C38 - C37- C36
Quality	A33	C16 - C14 - C13 - C1 - C37 - C36
	A34	C15 - C14 - C13 - C1 - C37 - C36
	A35	C17 - C14 - C13 - C1 - C37 - C36
	A36	C12 - C14 - C13 - C1 - C37 - C36
	A37	C8 - C7 - C1 - C37 - C36
	A38	C11 - C7 - C1 - C37 - C36
	A39	C9 - C7 - C1 - C37 - C36
	A40	C10 - C7 - C1- C37 - C36
Communication	A41	C5 - [C43] - C1 - C37 - C36
	A42	C6 - [C43] - C1 - C37 - C36
	A43	C3 - [C43] - C1 - C37 - C36
	A44	C4 - [C43] - C1 - C37 - C36
	A45	C2 - [C43] - C1 - C37 - C36
Changes	A46	C47 - C44 - C42 - C40 - C39 - C38 - C37 - C36
	A47	C45 - C42 - C40 - C39- C38 - C37 - C36
	A48	C46 - C42 - C40 - C39- C38 - C37 - C36
	A49	C41 - C39 - C38 - C37 - C36

• [Cx]: Connection to another cluster.

Table 5
Branches on the congregated cognitive map.

Cluster	Branches	Argument lines that make up the branch
Management	B1	A1, A2, A3
	B2	A4, A5
Knowledge	B3	A6, A7, A8, A9, A10
Tools	B4	A11,A12, A13, A14, A15, A16
Process	B5	A17, A18, A19
Needs	B6	A20, A21, A22, A23, A24, A25, A26, A27
	B7	A28, A29, A30, A31
	B8	A32
Quality	B9	A33, A34, A35, A36, A37
	B10	A38, A39, A40
Communication	B11	A41, A42, A43, A44, A45
Changes	B12	A46, A47, A48, A49

The transition of the maps for the development of the Tree of FPV was held without the presence of decision makers, as described by the Ensslin’s method. The branches of the map were searched in order to identify points of view towards meansends, observing the importance degree of the view expressed by the decision maker in the business analysis, and towards ends-means, the degree of controllability of the concepts that make up the branches. Thus, the elements have been identified for the composition of the tree of points of view presented in Fig. 3 (Ensslin et al. 2001).

Figure 3
Tree of Fundamental Points of View.

To determine the FPV, the facilitator should carry out an analysis of the aggregate map, from bottom up to the top of the tree structure, in order to check that the level of this structure, the area of concern has the following properties (Ensslin et al. 2010): Essential; Controllable; Complete; Measurable; Operational; Isolable; Non-redundant; Concise; Comprehensible.

When all these properties are attended, a fundamental point of view set is reached. All the points of view that are non-fundamental, but decompose one fundamental point of view, permitting a better evaluation of the potential action performance in the FPV, are denominated Elementary Points of View (EPV) (Ensslin et al. 2001).

Figure 3 shows the tree of FPV. Finally, the congregated map and the candidates for FPV were sent to the decision makers for joint analysis with the facilitators on the strategic actions that could reduce difficulties in requirements elicitation process. It was observed the achievement of the properties of FPV:

• Understandability: designed to be understood by all the individuals involved

• Consensually: represents the consensus of the decision makers group

• Acceptability: acceptance by all who participated in the decision making process

• Completeness: there are no actions punctuated by decision makers alike

• Cohesiveness: compatibility between the roles of each FPV in the preferences of decision makers around the objectives

• Non-redundancy: the FPV lend themselves to evaluation of different aspects.

CONCLUSIONS

The present study resulted in four individual cognitive maps and a congregated map that allowed identifying the difficulties in requirements elicitation process for building complex systems, in this case, directed to the development of aerospace products in São José dos Campos. The maps revealed eight areas of interest (clusters) which concentrated most of the difficulties detected. Table 6 shows the strategic actions, revealed by the map, to analyze impacting actions.

Table 6
Impact areas and strategic actions for each one.

Impact areas	Strategic actions
Management	Decision to exclude or not requirements Keeping the schedule Avoiding additional cost
Knowledge	Investing in training
Tools	Choosing a tool to assist in the implementation of procedures for requirements elicitation Choosing a tool that is integrated with other enterprise tools
Process	Decreasing process changes in Requirements Engineering Enhancing the process of Requirements Engineering
Needs	Giving solution options to the client Minimizing the subjectivity of concepts
Quality	Measuring the characteristics of the requirements
Changes	Having agility in development
Communication	Informing revisions of the requirements

The goals of this study were achieved, creating opportunity to establish actions that minimize the detected problems and sources of conflict between suppliers and customers of complex and specific aeronautical systems. The cognitive map has proved to be an efficient tool for capturing individuals’ subjective perceptions as regard the profile of each substrate involved, as well as their experiences, values formation, and decision making in the studied area.

The validation activity was considered the most important, and communication problems were seen as the main source of conflict and difficulties throughout the development process, sometimes causing significant changes that culminate in the specification of a new product.

This study revealed that the main difficulties faced in aerospace products development during the process of requirements elicitations have been the lack of knowledge of the entire life cycle of the system by developers, the lack of clarity in requests from clients, and poor communication hindering customer-developer interaction.

The main results include the following aspects:

• Commitment schedule and customer service requirements.

For the respondents, problems that have, as generating factor, lack of knowledge of developers about the entire development cycle, lack of clarity in customer’s requests and, especially, poor communication hindering developercustomer interaction were listed.

The technique allowed the participation of several decision makers, promoting collective learning by induction to reflection, and by the recursive nature dominant in the whole process. It was established a rich setting for rational and reliable decisions, relevant to the development of complex systems in a competitive, heterogeneous environment, in the presence of conflicting interests, with the different views of the decision-making process and of the impacts caused by poorly-defined ER.

The case study consisted on structuring the environment to identify issues that impact the development process of complex systems. The built cognitive map shows all the concepts and connections, in agreement with the feelings and views of decision makers. This information was used to build the tree of FPV, allowing the identification of problems. The facilitators, considering the aspects and the environment in which the cognitive process occurred, concluded that freedom of expression and informality helped to speed up the work and that decision makers proved differentiated visions, values and methods of operation, requiring the redirection of the focus of reasoning about the observed issues.

It is noted that, due to the large volume of concepts generated, the amount of respondents must not exceed a group of eight professionals, in order to not hinder the process of concepts aggregation, since the congregated map is the result of consensus among the participants. Thus, a very high number of participants may impair the validation process, including the difficulty of bringing together all stakeholders in one place. This research was developed with only four decision makers due to the fact that only these professionals agreed to participate, although many others have been invited.

The results presented correspond to an initial step to structure the detected problems, proving the efficiency of cognitive maps to identify those perceived during the capturing of the requirements to develop complex products.

As continuity, we recommend that such research is carried out with other groups of participants, so that a comparison of the results can be made in order to generalize the points of bottlenecks in the process of requirements elicitation, not only for complex products, but also for ER as a whole.

It is recommended, from the elaborated maps, the structuring of each detected problem and the use of multicriteria decision tool for choosing the most suitable alternatives for improvements in the process of gathering requirements and in the relationship between customer and supplier, generating a basis for making decisions throughout the development cycle of complex systems.

A multicriteria methodology to support constructivist decision MCDA-C is a good tool that can be used to structure the decision making environment in order to create models to support decisions in complex environments (Ensslin et al. 2010; Machado et al. 2012).

The use of cognitive map allowed achieving the proposed objective and proved to be an effective strategic tool to explain the structure of a problem and identify the points of view and the critical requirements in the survey process with the aerospace industry stakeholders.

The cognitive map was used to allow, through mental, individual and collective concepts, obtained from written statements and interviews, the identification and structure of the existing problems in the elicitation of requirements for development of aerospace products. The results obtained can be taken as a basis for possible corrective actions.

This research is relevant for presenting a contribution to ER, showing the efficiency of cognitive maps to identify the critical points of the requirements elicitation during the product development process, since, in general, a well-designed requirement reduces development cost, avoiding rework and ensuring the satisfaction of stakeholders.

ACKNOWLEDGEMENTS

We wish to thank the participants of this research for their efforts to provide us accurate information without which we coud not have achieved the proposed objectives.

REFERENCES

• Ackermann F (2012) Problem structuring methods ‘in the Dock’: arguing the case for Soft OR. Eur J Oper Res 219(3):652-658. doi: 10.1016/j.ejor.2011.11.014
  » https://doi.org/10.1016/j.ejor.2011.11.014
• Ackermann F, Eden C, Cropper S (2004) Getting started with cognitive mapping; [accessed 2016 Feb 9]. http://pkab.wordpress.com/2008/01/19/getting-started-with-cognitive-mapping/
  » http://pkab.wordpress.com/2008/01/19/getting-started-with-cognitive-mapping/
• Ackermann F, Eden C, SODA (1989) Mapping in practice. In: Rosenhead J, Mingers J, editors. Rational analysis for a problematic world: problem structuring methods for complexity, uncertainty and conflict. Chichester: John Wiley. p. 43-60.
• Ackermann F, Eden C, SODA (2002) Journey making and mapping in practice. In: Rosenhead J, Mingers J, editors. Rational analysis for a problematic world revisited: problem structuring methods for complexity, uncertainty and conflict. 2nd ed. London: Wiley. p. 43-61.
• Ackermann F, Eden C, SODA (2010) Strategic options development and analysis. In: Reynolds M, Holwell S, editors. System approaches to managing change: a practical guide. London: Springer. p. 135-190.
• Agoravale (2012) Economia; [accessed 2016 Feb 10]. http://www.webcitation.org/query?url=http%3A%2F%2Fwww.agoravale.com.br%2Fcidadesdaregiao%2Fdados.asp%3Fcidade%3D3%26topico%3D8&date=2012-05-14
  » http://www.webcitation.org/query?url=http%3A%2F%2Fwww.agoravale.com.br%2Fcidadesdaregiao%2Fdados.asp%3Fcidade%3D3%26topico%3D8&date=2012-05-14
• Alves CF (2007) Uma experiência de engenharia de requisitos em empresas de software. v. 488. Recife: UFPE; Publicações CEUR.
• Azevedo Junior DP, Campos R (2008) Definição de requisitos de software baseada numa arquitetura de modelagem de negócios. Production 18(1):26-46. doi: 10.1590/S0103-65132008000100003
  » https://doi.org/10.1590/S0103-65132008000100003
• Cossette P, Audet M (1992) Mapping of an idiosyncratic schema. J Manag Stud 29(3):325-347. doi: 10.1111/j.1467-6486.1992.tb00668.x
  » https://doi.org/10.1111/j.1467-6486.1992.tb00668.x
• Dias F, Morgado G, Oscar P, Silveira D, Alencar A, Lima P, Schmitz E (2006) Uma abordagem para a transformação automática do modelo de negócio em modelo de requisitos. Proceedings of the Workshop em Engenharia de Requisitos; Rio de Janeiro; Brazil.
• Eden C, Ackermann F (1998) Making strategy. London: Sage Publications.
• Ensslin L, Montibeller Neto G, Zanella I J, Noronha SMD (1998) Metodologias multicritério em apoio à decisão. Florianópolis: Universidade Federal de Santa Catarina; LabMCDA.
• Ensslin L, Montibeller Neto IJ, Noronha SMD (2001) Apoio à decisão: metodologia para estruturação de problemas e avaliação multicritérios de alternativas. Florianópolis: Insular.
• Ensslin L, Giffhorn E, Ensslin SR, Petri SM, Vianna WB (2010) Avaliação do desempenho de empresas terceirizadas com o uso da metodologia multicritério de apoio à decisão-construtivista. Pesqui Oper 30(1):125-152. doi: 10.1590/S0101-74382010000100007
  » https://doi.org/10.1590/S0101-74382010000100007
• Gomes LFAM, Rangel LAD, Jerônimo RL (2010) A study of professional mobility in a large corporation through cognitive mapping. Pesqui Oper 30(2):331-334. doi: 10.1590/S0101-74382010000200005
  » https://doi.org/10.1590/S0101-74382010000200005
• González JLV, Alcolea DA, Díaz JS (2007) Descomposición de árboles de metas a partir de modelos de procesos. Proceedings of the Workshop em Engenharia de Requisitos (WER07); Toronto, Canada.
• Iederan OC, Curseu PL, Vermeulen PAM, Geurts JLA (2011) Cognitive representations of institutional change: similarities and dissimilarities in the cognitive schema of entrepreneurs. J Organ Change Manag 24(1):9-28. doi: 10.1108/09534811111102265
  » https://doi.org/10.1108/09534811111102265
• Kotonya G, Sommerville I (1998) Requirements engineering — processes and techniques. Chichester: John Wiley.
• Kulak D, Guiney E (2000) Use cases — requirements in context. Boston: Addison-Wesley.
• Machado TPSO, Ensslin L, Ensslin S (2012) Avaliação e desenvolvimento de produtos utilizando o método MCDA-C. Proceedings of the IX SEGeT — Simpósio de Excelência em Gestão e Tecnologia; Rio de Janeiro, Brazil.
• Manso DF, Suterio R, Belderrain MCN (2015) Estruturação do problema de gerenciamento de desastres do estado de São Paulo por intermédio do método Strategic Options Development and Analysis. Gest Prod 22(1):4-16. doi: 10.1590/0104-530X1105-13
  » https://doi.org/10.1590/0104-530X1105-13
• Marinho SPP (2008) IHMC CmapTools: manual de uso rápido. Belo Horizonte: UFMG.
• Martins LEG (2001) Uma metodologia de elicitação de requisitos de software baseada na teoria da atividade (PhD thesis). Campinas: Universidade Estadual de Campinas.
• Mingers J (2011) Soft OR comes of age — but not everywhere! Omega 39(6):729-741. doi: 10.1016/j.omega.2011.01.005
  » https://doi.org/10.1016/j.omega.2011.01.005
• Mingers J, Rosenhead J (2004) Problem structuring methods in action. Eur J Oper Res 152(3):530-554. doi: 10.1016/S03772217(03)00056-0
  » https://doi.org/10.1016/S03772217(03)00056-0
• Montibeller Neto G (1996) Mapas cognitivos: uma ferramenta de apoio à estruturação de problemas (Master’s thesis). Florianópolis: Universidade Federal de Santa Catarina.
• Montibeller Neto G, Belton V (2009) Qualitative operators for reasoning maps: evaluating multi-criteria options with networks of reasons. Eur J Oper Res 195(3):829-840. doi: 10.1016/j.ejor.2007.11.015
  » https://doi.org/10.1016/j.ejor.2007.11.015
• Novak JD, Cañas AJ (2008) The theory underlying concept maps and how to construct and use them. Technical Report of IHMC Cmap Tool 2006 - 01 Rev 01 2008; [accessed 2016 May 10]. http://cmap.ihmc.us/Publications/ResearchPapers/TheoryUnderlyingConceptMaps.pdf
  » http://cmap.ihmc.us/Publications/ResearchPapers/TheoryUnderlyingConceptMaps.pdf
• Pressmann RS (2006) Software engineering. 6th ed. New York: McGraw-Hill.
• Rosenhead J (2006) Past, present and future of problem structuring methods. J Oper Res Soc 57(7):759-765. doi: 10.1057/palgrave.jors.2602206
  » https://doi.org/10.1057/palgrave.jors.2602206
• Santos PR, Curo RSG, Belderrain MCN (2011) Aplicação do mapa cognitivo a um problema de decisão do setor aeroespacial de defesa do Brasil. J Aerosp Technol Manag 3(2):215-226. doi: 10.5028/jatm.2011.03021211
  » https://doi.org/10.5028/jatm.2011.03021211
• Sommerville I (2006) Software engineering. 8th ed. Boston: Addison-Wesley.
• Young RR (2004) The requirements engineering handbook. Norwood: Artech House.

Publication Dates

• Publication in this collection
  Apr-Jun 2016

History

• Received
  23 Nov 2015
• Accepted
  28 Apr 2016