1 Introduction

Part of the motivation in software development projects is to determine “what to build?”. This stage is performed in the phase of defining the requirements of the software life cycle, which is where the functionalities that the system should provide and that are related to the client’s needs are identified [5]. It is in the development of software requirements engineering processes that one must ensure that the analyst understands the premises, business rules, protocols, validations, restrictions and decisions indicated by users during the designing of the software [10]. Ensuring consistent communication promotes consistency between what the user knows and what the analyst ultimately represents in the software design [5, 16]. The purpose of the present work is to identify research studies in which the use of mind maps is proposed as part of the requirements engineering process and how they intervene in communications between users and analysts during elicitation, specification, analysis, validation and management of requirements [13, 15, 16]. After the present introduction, this work is structured as follows: Sect. 2 provides the theoretical framework regarding requirements engineering, mind maps and mind maps in requirements engineering; Sect. 3 presents the systematic mapping of the studies available in the literature during the years 2010 to 2016 and finally Sect. 4 lists the conclusions and suggests other studies or related future works that could prove useful.

2 Theoretical Framework

2.1 Requirements Engineering

Requirements engineering (RE) establishes the processes for defining the requirements. These processes must involve different actors and their different points of view. Among these actors, there is the analyst, responsible for the creation of models based on the information gathered from expert users in the business domain [16].

Among the processes considered in the RE are [3, 16]:

  • Elicitation of requirements

  • Specification of requirements

  • Requirements analysis

  • Verification, validation and evaluation of requirements

  • Requirements management

2.2 Mind Maps

A mind map is a diagram used to view, classify and organize concepts, and to generate new ideas. It is used to connect words, ideas and concepts to a central idea or concept [4].

The main benefits of the use of mind maps are [4]:

  • Organization of ideas and concepts

  • Emphasis on the relevant keywords

  • Association between the elements of the branches

  • Grouping of ideas

  • Support of visual memory and creativity, innovation ideas driver

An example of a mind map diagram developed by Buzan is shown in Fig. 1 [4].

Fig. 1.
figure 1

Buzan’s Mind map [4]

Full size image

2.3 Mind Maps in Requirements Engineering

The use of mind maps in RE contributes to improving the quality and traceability of the requirements. This is due to the fact that mind maps allow the capture of information in multiple layers, therefore, it provides the participants in the RE process with the information captured by others interested in the development of the software product. In addition, iterating the activities of the RE processes helps to gradually grow the knowledge and information captured and, consequently, facilitates the production of an initial set of better quality requirements [18].

3 Systematic Mapping

3.1 Reviewing Process

The objective of the systematic mapping of the literature is to provide information on the state of the art of the different methods or techniques used in the RE that consider the elaboration of mind maps as part of the activities of the process.

3.2 Research Questions

For this research, the following research questions have been defined:

Question 1: Is the development of mind maps in Requirements Engineering included in software development projects?

The objective of this question is to attain the state of the art of the total number of publications in the population of software development projects that mention the development of mind maps in the RE processes.

Question 2: Regarding the development of mind maps in Requirements Engineering, do they take into account functional and non-functional requirements?

Considering the previously obtained results, the question seeks to determine if mind maps consider the lifting of the functional requirements and non-functional requirements of the software development projects.

Question 3: Regarding the development of mind maps in Requirements Engineering, has this been validated or is it currently used in the industry?

The aim of this question is to limit the results obtained with question 1 and verify if these are in the categorization of publications to be evaluated, proposal of solution, validation, case studies applied to the industry, opinion and personal experiences. The answer to the question will allow determining if the development of mind maps in the RE has been validated within an academic environment or evaluated after its application in the industry.

To answer these questions, a search string was built based on the criteria of the PICOC method (Population, Intervention, Comparison, Outputs, and Context) that are shown in Table 1.

Table 1. PICOC
Full size table

3.3 Search Strategy

In order to carry out the search and selection of the research studies, 5 stages were defined, which are detailed in Table 2.

Table 2. Stages
Full size table

Search String.

The search string is defined in Table 3, which will be used as the input value in the search engines of the digital data sources listed in Table 4.

Table 3. Search string
Full size table

Search Process.

The search was performed using the data sources specified in Table 4, which contains the references of scientific articles and journals, conference proceedings and technical documents. The searches were performed on the titles, abstracts and keywords of the publications that provide the digital data sources.

Table 4. Consulted digital data sources
Full size table

3.4 Inclusion and Exclusion Criteria

A set of selection criteria classified as inclusive and exclusive has been defined in order to identify the most appropriate studies for the systematic mapping. The inclusion of the studies was determined by the following criteria:

Inclusion Criteria

  • The publications must be written in English or in Portuguese.

  • Access to the content of the publication must be available.

  • The published works should be reviews, solution proposals, validations or evaluations.

Exclusion Criteria

  • Publications that do not propose the development of mind maps in the RE.

  • Publications that do not validate or evaluate the development of mind maps in the RE.

  • Articles based on opinions.

  • Duplicate publications. In case there are duplicate results, those whose content can be accessed will be considered.

3.5 Synthesis Strategy

The search resulted in 144 publications between the years 2010 and 2016, of which six were duplicates. The list of selected studies is classified in Table 5.

Table 5. Studies selected according to data source
Full size table

After applying the inclusion and exclusion criteria, fifteen studies without duplication were selected which are listed in Table 6.

Table 6. Selected studies
Full size table

3.6 Quality Assessment of the Study

The 15 studies selected were subjected to a quality evaluation process. The evaluation instrument applied is based on the proposal of Zarour et al. [17], which uses a rating scale of 3 levels of compliance. If the study submitted for evaluation satisfies the quality assurance question (Yes), 1 point is assigned, if it does not comply (No), a score of 0 is assigned and if it is met Partially it is assigned 0.5 points.

After having applied the evaluation instrument presented in Table 7. Table 8 shows the results of the quality assessment of the selected studies.

Table 7. List of questions for quality assurance
Full size table
Table 8. Results of the quality evaluation of the selected studies
Full size table

All relevant publications with a total score equal to or less than 5.0 and greater than or equal to 2.5 are considered accepted; while those with a score lower than 2.5 are discarded. From the final results we can see that the scores reached by each study are not less than 4.0, the average score is 4.4. The result of the quality assessment shown in Table 8 shows that all 15 studies are acceptable.

3.7 Data Extraction

The search was conducted in November 2016, considering the inclusion criteria of studies performed between 2010 and 2016. Table 9 shows the number of publications per year.

Table 9. Studies per years
Full size table

The types of sources of the selected publications are: conferences, symposia, magazines and workshops. Table 10 shows the publications with their respective types.

Table 10. Sources of publications
Full size table

3.8 Synthesis of Publications

From the selected works, RE processes that consider the use of mind maps have been identified. Table 11 details the RE processes [3] that make use of these mind maps.

Table 11. Requirements engineering process
Full size table

Based on the data in Table 11, it can be assured that there is evidence of the inclusion of mind maps in the development of the processes of elicitation, analysis, specification, validation and management of requirements. This finding occurs more frequently in the elicitation, analysis and validation of requirements since it involves a constant interaction and communication between expert users of the business domain and analysts.

In order to ensure a correct communication and understanding of what the user expects to obtain as a final software product, techniques such as “Zaltman metaphor elicitation technique (ZMET)” [9] are applied to structure the phases of an interview. Likewise, methods are combined to group and hierarchize the details of the most relevant data or attributes that represent the needs of the users. The information obtained can be represented in a mind map that allows the user to validate that the analyst has correctly understood their needs.

Another method to validate communication among those interested in software development is the “Method of semiotic inspection (MSI)” [10] which describes a flow of communication in which (1) the user requests the construction of the software, (2) identifies the functional requirements using elicitation techniques and complements it with the development of mind maps, (3) validates the requirements with the user (4) requests the construction of interfaces, (5) presents user interfaces or prototypes and (6) validates the communication method. The flow of communication is represented in Fig. 2 proposed by De Oliveira et al. [10], in each phase is modeled in a semi-structured way: the data, ideas and restrictions of the needs of the users [2], the mind map is increasing and improving in each interaction and transfer in the flow of communication.

Fig. 2.
figure 2

MSI Communication flow [10]

Full size image

The studies describe software tools such as “REMEST (Requirement Management Education Support Tool” [11], which propose mind map templates for the development of the activities included in the requirements elicitation process, Fig. 3 represents the template for Identification of the interested parties. Figure 4 represents the template to identify the problems and their possible causes. Figure 5 represents the template for the analysis of the objectives for the resolution of problems. Figure 6 represents the template for the Identification of the means to achieve the objective. Figure 7 represents the template for the identification and specification of requirements. The elaborated templates are developed in the tool and processed to make a comparison with a template that has the mind map of correct answers and returns the inconsistencies that may have been detected by the analyst. Figure 8 represents the result of the comparison of the map proposed by the analyst and the map with correct answers.

Fig. 3.
figure 3

Template for the identification of interested parties (Stakeholders) [7]

Full size image
Fig. 4.
figure 4

Template for identifying problems and their possible causes [7]

Full size image
Fig. 5.
figure 5

Template for the analysis of objectives for the resolution of problems [7]

Full size image
Fig. 6.
figure 6

Template to identify the means to achieve the objectives [7]

Full size image
Fig. 7.
figure 7

Template for the identification and specification of requirements [7]

Full size image
Fig. 8.
figure 8

Comparison result of mind maps [7]

Full size image

The development of mind maps contributes to a significant improvement in the quality of the specification of software project requirements developed with agile methods [8, 13, 16]. The use of user stories is considered as a technique for eliciting software requirements [3]. Wanderley et al. [11], proposes the specification of user stories using the tool “BehaviorMap”, the mind map developed describes an example scenario in which, provided that the ship “Seal” is in a determined position, a coastguard, visualizing an area of the map limited by the start and end points, you will see this ship within this area. Figure 9 graphically represents the specification of user stories using mental maps.

Fig. 9.
figure 9

Graphical representation of user stories by mind maps [11]

Full size image

In reference to the processes of analysis, specification and validation of requirements, studies propose the use of automated tools such as “MindDomain” [5, 12], “SnapMind” [14], “MindMappingModeler” [16] these tools provide graphic interfaces for the development of mind maps for later with tools such as “DomainModModel” [16] generates the conceptual or business domain models. Then these models are used by the analyst in order to validate the requirements with the users. Wanderley et al. [16], proposes the transformation process is observed between the elicitation of requirements, the development of the mind map, the generation of the conceptual model that using UML class diagrams [15] represent the business entities with their respective attributes and relationships between them [13, 16]. The advantage of transforming the requirements expressed in mind maps into conceptual models or as UML class diagrams create a common vision of the business domain between developers and clients, defining a shared vocabulary [12]. Figure 10 graphically represents the generation of conceptual or business domain models.

Fig. 10.
figure 10

Generation of conceptual models or business domain [16]

Full size image

The mind maps developed using the aforementioned tools are graphic representations that visually consider a central element that represents the main idea and around it different nodes that complement the explanation of the context in treatment [2]. These tools automatically organize the graphic elements and structure them in hierarchical mode. These elements represent the different nodes that make up the mind map [2]. They also provide visual editing functions that allow to: hide, show, copy, paste, move, drag and drop the different nodes that make up a mind map. Amongst other functionalities, the possibility is also considered that the nodes register hyperlinks to external files or even references to other mind maps [2].

The methodology “OntoREM” (Ontology-driven Requirements Engineering Methodology), jointly developed by the company Airbus and the University of the West of England (US Patent pending), is an example of adoption of the development of mind maps to facilitate the modeling of the business domain and the specification requirements. The methodology improves the RE processes and allows managing the changes of the business domain including the specification of the requirements over time [18]. Duarte et al. [6], proposes to use mind maps for the registration of the traceability of the addition or modification of the requirements and how these are linked if it is the case.

From the selected works, it was identified that the requirements elicitation techniques consider in greater number the development of mental maps as a complement to the development were identified. Table 12 lists the requirements elicitation techniques [3] that do develop mind maps.

Table 12. Elicitation techniques that include the use of mind maps
Full size table

3.9 Discussion of Results

In order to answer the research questions that have been previously defined (see Sect. 3.2), this section describes the findings based on the selected studies.

Question 1: Is the development of mind maps in Requirements Engineering currently included in software development projects?

Answer 1: Based on the evidence obtained from the systematic mapping (see Table 11), it is possible to conclude that RE processes do include the development of mind maps. From the findings, it is possible to list the elicitation techniques that include the development of mind maps such as: traditional interviews, analysis of scenarios, assisted meetings, observations, development of user stories, conceptual models or business domain/class diagram (see Table 12).

The inclusion of the development of mental maps is evidenced more frequently in the processes of elicitation, analysis and validation of the requirements, this as a result of the activities developed in these processes involve a constant interaction and communication between expert users of the business domain and the analysts.

There are software tools that allow to develop mental maps and that applying RE elicitation techniques, it is possible to represent the needs of the users in a graphic way, allowing to validate that these have been correctly understood.

Question 2: Regarding the development of mind maps in Requirements Engineering, do they take into account functional and non-functional requirements?

Answer 2: Of the studies presented in Table 6, the inclusion of only the functional requirements is mentioned and referred to and there is no evidence to consider the non-functional requirements during the development of the mind maps.

Automated tools such as “MindDomain”, “SnapMind”, “MindMappingModeler”, provide graphical interfaces for the development of mental maps and later with tools such as “DomainModModel” generates conceptual or business domain models that complement the definition and specification of the software requirements.

Question 3: Regarding the development of mind maps in Requirements Engineering, has this been validated or is it currently used in the industry?

Answer 3: The resulting studies (see Table 6) describe cases of studies that have been validated in controlled environments, as well as their performance in real scenarios in the industry.

The “OntoREM” methodology used in the Airbus company, adopts the development of mental maps to facilitate the modeling of the business domain, the specification of requirements and allows to manage the changes of the business domain including the specification of the requirements over time.

3.10 Threats to the Validity of the Study

Four possible threats to the validity of the results obtained were obtained.

Validity of the Construct.

The main construct used in this study is the search chain developed for research. This search string was built using synonyms associated with the terms that were part of the proposed PICOC. Likewise, the chain has been executed on a set of previously selected digital sources. There is the possibility that some relevant studies have not been considered if they were indexed in one of the non-reviewed digital sources or if they contained terms other than those selected to build the search chain.

Internal Validity.

It is possible that a bias was introduced when extracting and analyzing the data from the study prepared by the researcher. In order to mitigate this risk, revisions were made by the study advisor to validate the analysis of the selected studies.

External Validity.

It is associated with the ability to generalize the results obtained in this study. In order to mitigate this risk, the search process is performed several times.

Validity of the Conclusions.

It is possible that some of the studies were incorrectly excluded in this review. In order to mitigate this risk, a careful construction of the inclusion and exclusion criteria and a subsequent validation of the quality of the selected studies were performed in order to avoid the exclusion of relevant studies.

4 Conclusions and Future Works

In the systematic mapping carried out, fifteen relevant articles formed by the results of the searches were identified. From these works, five RE processes were identified that include the development of mind maps: elicitation, analysis, specification, validation and requirements management.

The usage of mind maps to represent conceptual or business domain models helps to reduce the communication gap in users and software analysts, which is evidenced by the understanding of what is desired and what is developed as a product of software [1, 13, 15, 16].

The technique of developing mind maps could be conciliated with a more robust requirements management perspective and, at the same time, mitigate most criticalities and unwanted side effects due to inadequate control of changes in their specification [8].

The usage of the software product efficiently depends on the level of user knowledge and how this is related to the design of the software and the functionalities it offers to meet the business needs expressed in the elicitation stage [10].

Mind maps, being a graphic element, contribute to facilitating interaction in communication and the exchange of ideas between business users and analysts who will design the software product.

As future work, it is proposed to develop a proposal of method of inclusion of mental maps in the requirements engineering for software projects related to the industry. As well as investigating the inclusion of mind maps in the technique of prototyping interfaces and how they complement the premises of usability and considerations so that the user experience is benefited when users interact with the software product. Achieving in this way evidence within a mental map node the non-functional requirements that will limit the functional scope of the software.