Keywords

1 Introduction

Agents are intelligent entities that act in a flexible and autonomous way in decision making. A multiagent system (MAS) contains several agents acting in a system to solve problems beyond the capability of just one agent [56]. Multiagent systems have been shown to be good alternatives to deal with complex systems, since the complexity can be divided and assigned to several agents specialized in a given facet of the problem [31].

However, developing this kind of system also proved to be complex and generated new challenges for software engineering, which led to the emergence of AOSE - Agent-Oriented Software Engineering, an area that mixes features from both software engineering and Artificial Intelligence [36].

One of the several software engineering subareas is requirements engeineering, which aims to elicit, analyze, specify, and validate system requirements, in order to ensure the correct understanding about what a system really should do. According [73], requirements engineering is one of the most vital activities in the entire software development lifecycle, as the success of a software project depends much of how well users requirements have been understood and converted into proper functionalities.

Thus, several requirements engineering processes for multiagent systems have been proposed over the years. These processes aim to offer techniques, methods, and models adapted for this type of system, since multiagent systems present their own complexity, challenges, and particular requirements which differentiate them from other kinds of systems.

In SWEBOK [15] - a reference book in the field of software engineering - requirements engineering is divided into four subareas, Requirements Elicitation, Requirements Analysis, Requirements Specification, and Requirements Validation. We emphasize that each one of these subareas plays an essential role to Requirements Engineering.

This way, in order to understand the state-of-art of requirements engineering processes for multiagent systems, we carried out a literature systematic review [59]. This review analysed the processes mainly regarding the coverage of requirements engineering subareas defined in SWEBOK and its support to the BDI model, one of the most recognized approaches to integrate desired cognitive skills in autonomous agents and which facilitates the description of the relation cause-effect needed to an agent to achieve its goals [5]. Furthermore, this model proved to be one of the most suitable for the development of agents with flexible behavior [4].

However, this systematic review only presented the support for the BDI model and the coverage regarding SWEBOK requirements engineering of the analysed processes in a general way, without discussing these works in more depth. Therefore, this current paper aims to extend the analysis performed in the previous review, describing in detail the support of the processes regarding the BDI model and the gaps found in these processes, both in the BDI model support as in the processes coverage regarding the requirements engineering subareas as defined in SWEBOK.

This work is organized as follows. Section 2 contains the background. Section 3 presents the related works. The research method is described in Sect. 4. In Sect. 5, the results are presented and discussed. Threats to the validity are described in Sect. 6. Next, we present some insights that we gained from this research and, finally, the conclusion and future works.

2 Background

2.1 Requirements Engineering

According to [9], the RE goals are: (I) to identify software requirements, (II) to analyse requirements in order to classify them and to derive additional requirements, as well as to solve conflicts among them (III) to document requirements, and (IV) to validate the documented requirements.

In SWEBOK [15] - a reference book in the area - it is stated that the RE process cover four main subareas: (I) Requirements Elicitation; (II) Requirements Analysis; (III) Requirements Specification; and (IV) Requirements Validation.

Requirements elicitation investigates how to extract requirements and which are its origins. Requirements analysis aims to detect and solve conflicts among the requirements and to discover the system boundaries. Requirements specification, by its turn, produce requirements documents that can be systematically reviewed, evaluated, and approved. Finally, requirements validation evaluates requirements documents to ensure that the requirements be understandable, consistent, and complete.

2.2 Belief-Desire-Intention Model

The Belief-Desire-Intention (BDI) model is a software model developed to programming intelligent agents. It includes beliefs, desires, and intentions in the agent architecture [17], and that, according to [75] has been widely used in MAS development. Moreover, in the last 30 years this model has been the basis for much research on autonomous agents architectures [28].

In this model, Beliefs represent the information state the agent owns, i.e., what he believes to be true about the environment, about itself, and about other agents. Desires represent the agents motivational state. They represent the goals or situations the agent would like to achieve. Finally, the intentions represent desires the agent believes he can achieve and take actions to achieve them [67].

This model allows to the agents a more complex behavior than the reactive models, without the computational overload of the cognitive architectures. Moreover, it is easier to specify knowledge by means of this model [49].

According to [41], concepts of belief and goal perform a central role in the conception and implementation of autonomous agents. The concept of BDI, consider mental attitudes to be fundamental to the agents, where the beliefs are adapted to the environment truths, while in the intentions, the agents try to make the environment to correspond to its goals.

3 Related Works

We discovered some studies that aimed to identify and to evaluate methodologies/processes in the AOSE area. However, these studies do not follow a systematic vision, they are informal literature reviews with subjective comparison criteria.

The study of [40] discusses the state of AOSE methodologies and how to turn them into acceptable products for the industry. This study also presents a methodology classification, dividing them in (I) independent of goal-oriented methodologies and (II) extensions of goal-oriented methodologies to give support to the agent concepts. The study of [76] evaluates agent-oriented software methodologies. The work proposes a comparison frame with four selection groups: concepts, notations, process, and pragmatics. This proposal was evaluated comparing the methodology adequation and its development capacity. For this comparison, were used three methodologies, MaSE (an old version of O-MaSE), Tropos, and Prometheus. Finally, the work of [22] investigates the AOSE methodologies coverage regarding software engineering concepts. However, besides this work not following a systematic vision, it does not present several methodologies and does not have a wide coverage of requirements engineering.

Regarding systematic reviews, we found the study of [11] that developed a review about requirements engineering in multi-agent systems development. Nevertheless, this study tried to verify which modeling techniques were applied in the requirements engineering for MAS. On the other hand, our work has as its goal to identify the coverage of the requirements engineering process regarding the SWEBOK stages and its adequation to the BDI model.

The Table 1, presents a comparison of the studies related to our work, having as a comparison point the main features of this work. As can be noticed our work covers some characteristics that are different from the previous ones.

Table 1. Comparison of studies related to this work.
Full size table

4 Research Method

A systematic literature review (SLR) is a research technique whose purpose is identifying, selecting, evaluating, interpreting, and summarizing the available studies considered relevant to the research theme or phenomenon of interest [47]. This technique searches for primary studies related to the theme and provides a deeper synthesis about the data obtained from these studies [48].

A SLR has as its basis a protocol previously defined, that formalizes its execution, beginning by the stipulation of the research questions, passing by establishing the studies inclusion and exclusion criteria, selecting the digital basis for the extraction of works related with the keywords applied during the search in these basis, and concluding with the definition of how the results will be presented [10].

Our review has as its goal to establish the state-of-art of the process/methodo- logies for MAS development that support in somehow requirements engineering for this kind of system. Our main interest is about how these processes identify and specify the BDI model features in the requirements engineering phase.

4.1 The Research Questions

We defined four research questions for this review. The first research question (RQ1) aims to identify which methodologies/processes support RE for MAS.

The second research question (RQ2) was defined to identify the coverage of the RE by these methodologies. We believe that with this question we can discover possible gaps in the area and that this will allow for future research.

The third research question (RQ3) aims to verify which methodologies support the BDI model. As we stated before, this is a consolidated model in the MAS development and we believe it aggregates better reliability in using the methodologies that support it.

Finally, the fourth question (RQ4) has as its goal to show a wider view of the area needs and to focus on the points that can be approached in future works.

The four research questions are listed below:

  • RQ1: Which methodologies for the MAS development support a specific requirements engineering (RE) life cycle to this kind of system?

  • RQ2: Which is the coverage of the requirements engineering by these methodologies taking as a basis the subareas defined by SWEBOK [15]?

  • RQ3: Which of these methodologies focus on the BDI model during the requirements engineering?

  • RQ4: Which are the existing gaps in the methodologies that support RE for MAS?

4.2 Identifying and Selecting Primary Studies

To recover relevant works for this study, we built a String containing a set of keywords based on the research questions. This String was adapted to the particularities of each bibliographic basis.

To perform this review, we used bibliographic bases which (I) have a search mechanism based on web; (II) have a mechanism able to use keywords; (III) contain documents from the computer science area; and (IV) their data bases are updated regularly. It is important to highlight that we do not limited the period in which the studies were published

In addition, we have included a book [26] about methodologies for MAS, as well as other classical and known studies. These studies were manually selected by a specialist in the area because we considered that they would not be selected in the search String as they do not present in its title, abstract, and keywords topics related to the requirements engineering, since they are not processes focused on RE, though their life cycles encompass the RE area.

In Table 2 we show the generic String used in the basis. In addition to the search String, we used manual filters in the bibliographic bases. We considered necessary to apply these manual filters because, in some bases, the results obtained were high and many of the studies returned were outside the scope.

For ACM library it was used the filter “Title/Abstract/keywords”; for Engineering Village, “Subject/Title/Abstract”; for IEEE Xplore, All metadata, filters suggested by the base software “agents and multi-agent systems”; for Science Direct, “Subject/Title/Abstract” and “Title/Abstract/keywords” and commands “multiagent OR multi-agent OR agent-based”; for Scopus, “Title/Abstract/key- words”; and for Springer Link it were applied the filters “Filter of the area: Computer science”, “Filter of the subarea: Software Engineering and Artificial intelligence”.

Table 2. String generic [58].
Full size table
Table 3. Inclusion and Exclusion Criteria [58].
Full size table

4.3 Inclusion and Exclusion Criteria

The selection criteria have as its objective to identify the primary studies that provide contents to answer the research questions. Thus, firstly the studies were analysed with basis on the title, abstract, and keywords. If there were still doubts about the final classification of a study in relation to the inclusion or exclusion criteria, a specialist would be consulted. These criteria are described in the Table 3.

Table 4. Quality Indexes of the Studies [58].
Full size table

4.4 Studies Quality Assessment

We defined two quality criteria to evaluate the relevance of the studies to the scope of this research. These criteria were not used to the exclusion of studies, only for the ranking of studies more relevant. Next we described the two qualitative criteria and the score attributed for each criterion defined.

  1. 1.

    QC1: The work supports the BDI model?

    Yes (Y): the work fully supports the BDI model;

    Partly (P): the work supports at least one of the features of the BDI model;

    Not (N): the work does not support the BDI model.

  2. 2.

    QC2: the work applies some empirical study (experiment, case study, etc.)?

    Yes (Y): the study applies some empirical study;

    Not (N): the study does not apply some empirical study.

To establish a quality general index of the selected studies, we attributed scores to each criterion defined, where Yes (Y) corresponds to 1 score, Partly (P) 0.5 score and Not (N) 0 score.

The Table 4, shows the score of each selected study. We noticed that only three studies ([46, 60, 62]) reached the maximum ranking of 2 scores.

On the other hand, some studies got 0 score ([2, 13, 35, 38]), though these studies did not achieve any score, they were kept because the qualitative criteria were used only for ranking the studies, not for eliminate them.

4.5 Data Extraction Strategy

When the studies selection process was concluded, the basic information of each paper was registered for data extraction. The extraction was performed using the Google Spreadsheet to capture all the information of each work included, allowing the posterior synthesis.

The data extracted from the included works were analysed in order to answer the research questions. In Sect. 5, these results were exposed and discussed.

Fig. 1.
figure 1

Search process [58].

Full size image

4.6 Conducting the Review

The conduction of this systematic review was performed between the months of February and May of 2020. We defined four stages for the studies selection: (I) executing the search String in the bibliographic bases; (II) removing the duplicated studies; (III) applying the inclusion and exclusion criteria to the works; and (IV) reading and extracting the information of the remaining studies of the Stage (III). The studies were read by two reviewers in consultation with a specialist in the area.

In Stage 1, the search String was executed in the bibliographic bases selected for this review. The overview of this stage can be observed in Fig. 1. The conduction began analysing the 1060 works imported from the selected bibliographic bases.

In Stage 2, a total of 247 duplicated studies were removed. In Stage 3, there were applied the inclusion and exclusion criteria based on the reading of the title, abstract, and keywords, resulting in the selection of 53 studies considered promising.

To avoid the selection of works that are not fitted in the scope of this review, the 53 studies, selected in the third stage, were completely read, what resulted in the exclusion of 10 works, totalling 43 selected works. The rejected works in this stage were inside of two exclusion criteria:

  1. 1.

    Works that concentrate in other Software Engineering areas: the works excluded that were inside on this criterion were methodologies that worked with MAS only in posterior stages to the requirements engineering. The requirements engineering was performed in a traditional way, not focusing on any particular feature of MAS.

  2. 2.

    Works that cover a methodology already included in a work: for this criterion we selected the most recent work in such a way we can understand the current state of the methodology.

At the end of the conduction Stage, the manually selected studies ([14, 20, 21, 23, 27, 29, 34, 35, 45, 51, 63]) were added to the set of papers searched in the bases, according with defined in Sect. 4.2. This resulted in a total of 54 accepted studies.

4.7 Data Extraction

For data extracting in the accepted works, we read them all and tried to identify which SWEBOK RE subareas each work covers, whether the methodology proposed in the study has a well-defined life cycle, whether the RE presented in the study is adequate for MAS, and whether the study supports the BDI model.

The conduction of this stage was performed in pairs, where each researcher read the paper and extracted the information about the issues cited previously. The conflicts between the researchers were decided by a specialist in the area.

5 Results

The relevant information of the selected studies was obtained using the data extraction spreadsheet. The evidence found about each research question are discussed in the next subsections.

5.1 Methodologies Analysed in the Systematic Review

This subsection aims to answer the first research question: “Which methodologies for the MAS development support a specific requirements engineering (RE) life cycle to this kind of system?”

To answer this question, we found 54 methodologies which approached RE for MAS. These studies can be observed in Table 5.

Table 5. Methodologies/Processes that support RE for MAS and its coverage with relation to the SWEBOK subareas [58].
Full size table

5.2 Coverage in Relation to the Requirements Engineering Subareas Defined in SWEBOK

This subsection aims to answer the second research question: “Which is the coverage of the requirements engineering by these methodologies taking as a basis the subareas defined by SWEBOK [15]?”

From the 54 selected studies we observed that all of them present Requirements Engineering fit for multi-agent systems. Thus, we extracted which RE sub-areas defined in SWEBOK [15] are supported by these studies.

Table 5 shows the 54 studies and the sub-areas that they support. Great part of these studies, 46 in the total, support the sub-area of requirements analysis. While 31 of them support the sub-area of requirements specification.

The sub-area of requirements elicitation, by its turn, is supported by 16 studies.

From these methodologies, Homer methodology (Human Oriented Method for Eliciting Requirements) [80], stood out for being the only one that presented a way to elicit requirements from direct contact with the stakeholders.

Homer operation can be described as the use of organizational metaphors. In these metaphors, during the interview, the Stakeholder must simulate that the system is a company that is hiring new employees to work on a certain problem. This elicitation style aims to more easily discover the agent roles and their goals inside the system. In its execution, Homer presents a series of questions that should be asked to the Stakeholders.

However, Homer methodology presents problems in its application. In addition to not supporting requirements related to the BDI model, there is not a way to easily elicit the agents perceptions and plans. Moreover, this methodology does not provide support for eliciting requirements about external agents, being focused on the system’s internal functions.

Another important point is that no methodology contains a way to elicit requirements related to the BDI model. Although Tropos methodology [62] supports the BDI model and has a elicitation phase, Tropos does not detail how its elicitation should be done, differently from Homer.

We also noticed that several of the methodologies do not seek to determine whether the use of multiagent systems is valid, being uncommon a methodology that contains a viability study to establish the need for a multiagent system. Most of the time, methodologies assume that the system under analysis is a multiagent system.

Finally, concerning the sub-area of requirements validation, it is the area that have the lower number of studies, with only 3 of the total supporting validation.

We also noticed that, from these studies, only ADELFE methodology [14] supports the four RE sub-areas (elicitation, analysis, specification, and validation). However, the elicitation in the ADELFE methodology is not suitable for MAS, being applied a traditional elicitation. The features suitable for a MAS began to be presented in the analysis stage. However, this stage does not present the means for validating the documents specific for MAS. ADELFE validates only documents produced by a traditional requirements engineering.

Another important fact that we noticed in the extraction is that only 30 studies presented some empirical experiments for the validation of the methodology.

5.3 Methodologies Supporting the BDI Model

In this subsection we aim to answer the third research question: “Which of these methodologies focus on the BDI model during the requirements engineering?”

We tried to identify which methodologies support the BDI model. We observed that most part of the studies, 43 in the total, support partially the BDI model, i.e., they identify at least one of the features of this model.

These features are: agent beliefs; agent goals/desires; and agent intentions. However, it is necessary to state that the majority of these works do not cite explicitly the BDI model, most of them are goal-oriented methodologies, i.e., they focus on just in one feature of the BDI model and they do not necessarily use this model, but the fact that these studies identify one of the features is useful for our research.

Agents goals were the most identified feature, in most cases in isolation. There are studies that identify intentions, however we noticed that beliefs and intentions are not identified in isolation, they are always accompanied by the identification of their goals.

Another issue to be highlighted is that 11 studies do not present support to the BDI model and only 8 present support for all these features in at least one stage of their requirements engineering. Table 6 presents the methodologies coverage regarding their support to the BDI model.

Next we will present how the 8 methodologies that support totally the BDI model, in some requirements engineering phase, are structured.

The study of Ribino [65], supports the BDI model in the phase related to the requirements analysis. This methodology proposes a modeling of BDI organization for requirements analysis. This analysis is performed through an ontology that aims to represent the problem domain reality and the problem specification incompleteness.

Table 6. Coverage of methodologies/processes regarding the BDI model support [58].
Full size table

The ontology describes the environment, its main states, and what can be done to achieve/modify these states. This ontology is composed of the Action (specialized in intentional and unintentional action), Concept (specialized in position and object) and Predicate metaclasses. In this ontology, the “predicates” represent the beliefs and states that influence a concept that, in turn, works as a scenario related to the environment.

We understand that this way of representing beliefs weakens a view of BDI agents since, for this kind of agents, beliefs represent the knowledge that an agent or agent role has about the environment, and delimiting the knowledge related only to the environment can result in conflicts in the analysis, since all beliefs are related to the environment and not to a particular agent or agent role.

This methodology allows the identification of goals from patterns discovered by the requirements analysis described textually. There is a set of guidelines that establish how to identify positions, actions, and predicates. However, it is not possible to identify the perceptions associated with a goal or how that goal becomes an intention.

The BDI ASP process [46] appeared to be promissor in its preliminary reading. This process is entirely turned to BDI agents development, besides using as its basis the use-cases production, a technique widely used both in the industry and academia.

Nevertheless, after an analysis of the process, we found errors that could compromise this proposal. The first point is the use of the term intention as a synonym of plan. We believe that this could compromise the support of the BDI model, since an intention is usually related to one or more plans, but intentions and plans are not synonymous. In addition, the methodology uses what has been called “internal use cases” to represent plans, desires, and beliefs, however, no adaptation of the use-cases diagram to represent these concepts is presented, and this approach contains conceptual errors, such as the representation of agents as use-cases.

Tropos [62] supports the BDI model through the i* framework. However, this framework presents limitations in the coverage of this model. These limitations can be perceived by the lack of a way to visualize when a goal becomes an intention and how the beliefs affect the agents’ goals. In addition to the support provided by i*, Tropos dedicates, in the design phase, a stage to BDI agents, however we have not analysed this stage in depth because it belongs to the design phase and not to the requirements engineering phase.

Cysneiros methodology [57], theoritically supports the BDI model since it uses the i* framework. However, although it uses a framework containing concepts of BDI agents, the work of Cysneiros does not state at any moment that it works with the BDI model.

PRACTIONIST [60] is a goal-oriented methodology. However, unlike the other goal-oriented methodologies found in this review, the authors of PRACTIONIST describe its goals as goals of BDI agents.

PRACTIONIST is based on the BDI model, presenting total support for its use. As an overview of the support to this model, we can highlight that the methodology cover the following concepts: a set of perceptors that hear some relevant external stimuli (perceptions); a set of beliefs that represent information the agent got about its internal state and the external environment; a set of goals that the agent desire to achieve, representing the states or activities the agent would like to perform in the system, related to the agent desires or intentions; a set of goals relation that the agent uses during the deliberation and reasoning means-end process; a set of plans that are the means to achieve the intentions; a set of actions the agent can execute to act in the environment; and a set of effectors that really execute the actions.

However, although PRACTIONIST structure is adequate to the BDI model use, the methodology has structural problems for its application. The main issue is that the methodology seems to be more suitable for the design area, the only point that contributed to include this methodology as suitable for requirements engineering is that the authors understand that the methodology is useful for requirements analysis. Even so, PRACTIONIST does not porvide a lifecycle for its requirements engineering and does not detail how should be done the requirements analysis for BDI agents.

Prometheus [63] states to have full support for the BDI model, however, it does not present in its models examples or explanations of how to apply the BDI model, leaving open for interpretation by whoever applies the methodology. We considered it a risk, as it can generate inconsistencies and even errors during the system development.

Even so, some concepts can be understood through Prometheus models, such as the use of “data” to represent the beliefs. However, only data repositories are identified and not the beliefs. Belief repositories are linked to the goals, which may result in conflict since in a BDI agent view, beliefs contain the knowledge of an agent. Furthermore, although goals are represented in the Prometheus models, it is not clear how they change in intentions.

Lastly, regarding CoMoMAS [34] and MAS-CommonKADS [45] methodologies, we believe that they work with the same notation to represent the BDI model, since both methodologies have their models derived from the CommonKADS language, a conceptual language for modeling.

However, the MAS-CommonKADS methodology does not detail the use of the BDI model, it only states that they support this model. Regarding the CoMoMAS methodology, it uses the BDI model to represent the system internal structure, using the concepts of belief, goal, and intention (described through the plan model). Nevertheless, in spite of the concepts seeming to follow a logic line of BDI agents, there are conceptual errors in its approach. In this view, intentions do not appear to be originated from goals, being represented practically as new goals. Furthermore, the example presented does not detail how beliefs influence a goal to become an intention.

5.4 Gaps Found in This Review

In this subsection we will detail the gaps found in this review, aiming to answer the fourth research question: “Which are the existing gaps in the methodologies that support RE for MAS?”

We noticed that only three studies cover the validation sub-area in their RE cycle. It demonstrates that the majority of the methodologies do not care with this phase that is so important to the systems quality.

We also noticed that just one study covers the four sub-areas of RE in its cycle [14]. On the other hand, this study does not support the BDI model, what demonstrates a gap and the need of the proposition of a methodology containing a requirements engineering phase that supports the BDI model.

Regarding the BDI model coverage, we understand that the support to just 8 studies from a total of 54 is a low number. Moreover, just two methodologies have as their focus to cover this model ([46, 65]) and none of them cover elicitation and validation, what highlights a gap in the RE for MAS area.

Other point that we could identify as a neglect is that, among the methodologies that support BDI, only the Tropos methodology [62] covers the requirements elicitation and just the methodology proposed by Cysneiros [57] includes requirements validation. It demonstrates that most of the methodologies that support BDI focus on the requirements analysis and specification and that, besides these areas, there is space to be explored in the elicitation and validation areas.

We highlight in Table 7, which are the gaps of each study that fully supports the BDI model. Although some studies partially support this model, such as allowing the goals representation, they do not refer to the BDI model explicitly and we are only interested in studies that fully support the features needed for the BDI model.

Table 7. Studies that fully support the BDI model and its gaps.
Full size table

As can be seen in Table 7, of all the studies fully supporting the BDI model, only the work of Cysneiros [57] covers the validation subarea, however it does not present any specific technique for check the requirements. In this methodology it is mentioned only that the artifacts should be validated, but without defining how this should be done. It demonstrates that the validation subarea, so important for quality control, is being neglected by the current methodologies.

Another point that can be highlighted is that from these studies only the Tropos [62] methodology covers the requirements elicitation subarea, however, Tropos does not present any technique for capturing specific requirements for multiagent systems, such as those necessary to apply the BDI model.

Furthermore, the studies presented by Ribino [65], Tropos [62], Cysneiros [57], PRACTIONIST [60], and MAS-CommonKADS [45] despite covering the requirements specification subarea, they do not adopt a specification standard. Whereas, according Alsanad [3] due to the general complexity of requirements specification documents, software stakeholders tend not to use them efficiently, therefore, according to Boyarchuk [16], during requirements formation and formulation, it is important to follow the standards that rule the software development process. Moreover, the adoption of a specification standard establishes what information about requirements must be collected and how this information must be organized and structured in documents.

6 Threats to Validity

During the planning and execution of this review, some factors were characterized as threats to the research validity. The potential threats are discussed to orient the interpretation of this work:

  1. 1.

    Construct Validity: The reliability of the search string defined to select relevant works can be a threat to the construct. To minimize this threat the string was calibrated with the execution of several tests and the area expert was consulted about the most used terms.

  2. 2.

    Internal Validity: A possible threat could have arisen from the individual interpretation of each researcher, something that could have led to the exclusion of relevant studies. To minimize this threat, the protocol of this review was strictly followed, considering mainly the inclusion and exclusion criteria. When necessary, a researcher with experience in this area was consulted to reach a consensus about the acceptance of the identified studies.

  3. 3.

    External Validity: Another possible threat is that some studies could not have been found because it does not contain keywords defined in the search string. To minimize this threat, the book “Handbook on Agent-Oriented Design Processes” [26] was used as research source and some classical papers were manually selected by a specialist in the area. To complement the research we performed a manual search in the methodologies found aiming to ensure the use of studies with the most recent version.

  4. 4.

    Coverage Validity: Regarding the possible papers that were not captured by our String, we intend, as a future work, to apply the snowballing technique trying to find more relevant papers. Another issue is that the snowballing technique can allow us to find more papers about the analysed methodologies, since in this analysis we focused only on the last paper of each methodology and this practice may not fully guarantee a complete coverage of the methodology.

  5. 5.

    Conclusion Validity: In spite of following a systematic protocol, systematic reviews are subject to human error, especially in the data extraction from papers. To mitigate this threat, the data extraction was performed by two independent researchers following the strategy defined in Subsect. 4.7 and, in case of divergences, a specialist in the area was consulted.

7 Insights for Future Works

Based on this systematic literature review, we found some gaps that could become future research. Among these gaps, we highlight two of them that are already being addressed in our research group: I) the need to propose requirements engineering processes for the context of multi-agent systems that cover the four sub-areas of requirements engineering and support the resources needed to the BDI model, as none of the 54 processes analyzed in this review actually support these characteristics, which shows a good research opportunity; and II) the need to propose techniques related to the four sub-areas of requirements engineering, especially where the main gaps were found, such as requirements elicitation, specification and validation.

Thus, in the elicitation subarea, we believe it is necessary to develop techniques to obtain requirements related to the BDI model which we have not found. Regarding direct contact with the stakeholders, we found only Homer [80] technique addressing this issue, however Homer presents limitations that need to be addressed in future works.

Regarding the studies that support the specification subarea, none of them adopt a specification standard that establishes how the requirements needed for the BDI model must be organized and documented. Therefore, it is necessary to propose or adopt a standard to document the collected and analysed requirements. Furthermore, this standard should allow describing not only the requirements associated with agents, but also the requirements describing functionalites accessed by normal users.

Finally, these documents must be verified using appropriate techniques to ensure their quality. However, none of the studies returned in our systematic review presented a validation subarea in a consistent way and none of them presented a specific technique for verifying the documented requirements.

8 Conclusions and Future Works

Our original systematic review published in [58], aimed to answer research questions about which methodologies for multiagent systems support the requirements engineering lifecycle, what is the level of coverage of the requirements engineering subareas of these methodologies and which of them have focus on the BDI model. Our study has categorized the studies directly related to the research theme and revealed new possibilities of scientific research in this area.

In that work, we presented 54 studies that support at least one of the subareas of requirements engineering, somehow adapted or applied in the multiagent systems context. Among these studies we noticed that only 8 methodologies support the features needed to the BDI model. However, we have not discussed in depth these methodologies due to lack of space.

Thus, this new study aimed to detail the support of these methodologies regarding the BDI model, as well as to discuss the gaps found in these studies. Regarding the elicitation subarea, we noticed that only the Homer methodology [80] presented a new way to elicit requirements from the direct contact with the stakeholders. However Homer does not support requirements related to the BDI model. Therefore, we realized the need of proposing a technique to elicit requirements related to systems based on the BDI model.

Another gap found is related to the requirements specification subarea, considering that no study uses a specification standard. Lastly, analysing the studies supporting the BDI model, we noticed that only the work of Cysneiros [57] covers the validation subarea, but it does not present any specific technique for requirements verification. Thus, we concluded that further studies are need to create a requirements specification standard for multi-agent systems, as well as, to develop a verification technique to ensure that the requirements documented in this standard are correct, consistent and non-ambiguous.

Based on the data synthesis from the retrieved studies and their gaps, we are currently proposing a requirements engineering process for multiagent systems covering the subareas of elicitation, analysis, specification, and validation. Furthermore, this process is based on the notation proposed in the Multi-Agent Systems Requirements Modeling Language (MASRML) [37] that aims to support the BDI model.

This requirement engineering process will contain a elicitation technique and a verification technique both specific for multiagent systems based on the BDI model. Moreover, the requirements specification will follow an internationally recognized standard extended to the multiagent systems context. All these works are already in development in our research group.