Abstract
The requirement engineering process aims to provide a requirements specification document that defines the system to be developed. In this paper, we focus on the negotiation phase for the requirements engineering process in cooperative information systems (CIS). However, inter-enterprise cooperation can generate conflicts and contradictions among enterprise objectives due to the heterogeneity of their interests. The negotiation includes the discussion of requirements conflict and the search for a compromise approved by all stakeholders. In order to improve this phase, we propose a new negotiation approach for requirements engineering in a cooperative context, which overcomes the following problems: requirements could be in conflict, and the existing conflicts cannot be explicitly well expressed, i.e. conflicts are often unknown. Our approach has two steps, where the first one treats conflict detection by using a matrix. The second step consists on applying heuristic and contract net protocols related to the multi-agent systems for the resolution of the conflicts under a negotiation process. The principal quality of CIS is to interoperate physical sites by respecting their autonomy in this perspective, the multi-agents paradigm propose concepts particularly interesting for the development of CIS, such as dynamic organization, autonomy of control, decentralization, and interaction that includes cooperation, coordination, and negotiation. Finally, we apply our approach on a case study to demonstrate its advantages in reducing the complexity and problems of the requirements engineering.
Keywords
Introduction
Cooperation is a concept of an old practice, which has become currently the object of many active researches [47]. Indeed, the current economic context and challenges encourage companies to communicate together to reach a common objective. To this end, companies are forced to build Cooperative Information Systems (CIS) that facilitate interactions between customers, partners, and suppliers. Such systems considerably improve the productivity and service cost. The importance of cooperation increases according to the complexity of the system and the number of the stakeholders.
Since we are talking about cooperation among enterprises in the economic matter, while from a computational point of view, each company with its Information System (IS) which was conceived in isolated way to meet the specific needs of the company. For that, these systems will be incompatible and heterogeneous. These ISs should be coordinated to answer jointly and in a homogeneous way a common global goal. This generates conflicts and contradictions between the objectives of the different stakeholders. Indeed, a bad comprehension of the objectives between the stakeholders leads to failures that involve high development costs, delays in the delivery of products, and, consequently, the loss of reputation.
The principal quality of CIS is to interoperate physical sites by respecting their autonomy. In this perspective, the multi-agents paradigm proposes concepts particularly interesting for the development of CIS, such as dynamic organization, autonomy of control, decentralization, and interaction which includes according to [1] the following types: cooperation, coordination, and negotiation. Autonomous agents and multi-agent systems represent a new approach for the analysis, the design and implementation of complex computer systems and other CIS.
In fact, the majority of works in the field of CIS are devoted mainly to two phases: design and implementation. This is justified by the great number of software tools supporting them. However, very little attention is given to the requirement analysis phase. Therefore, in order to resolve such conflicts, many studies [20, 30, 21, 10] show that the process of requirement analysis is the most effective solution. The latter is so-called a process of requirement engineering (RE) that leads to the production of a coherent set of specifications for system design.
According to [11, 19], a RE process generally includes the phases of elicitation, analysis, specification, validation, negotiation, and management of requirements. The most important phase is the negotiation, because its role is to overcome the conflicts that exist among stakeholders. Indeed, it explains the disagreements that are inevitable when multiple stakeholders are involved in the cooperation process. Moreover, the negotiation plays a fundamental part in the activities of cooperation by enabling people to solve conflicts, which could put in danger cooperative behaviors [1]. Then, we can consider negotiation as a process of improvement of the agreements by reducing inconsistencies and the uncertainty on common points of view or action plans by the structured exchange of relevant information. This exchange is done by well-defined protocols according to the model of negotiation applied.
The conflict is difficult to define because it takes many forms and occurs in different settings. It seems that the conflict is, in essence, a disagreement, a contradiction, or an inconsistency. The term applies to any conflict situation where there are individuals or groups whose goals, cognitions, or emotions are incompatible and lead them to oppose.
There is no universal model that can be applied to any negotiation situation. The main reason is due to the existence of a large number of parameters. These parameters depend on the negotiation techniques, the language that agents use to negotiate, and the types of agents.
In our work, we propose a new approach of negotiation based on a multi-agent system that resolves conflicts to generate a coherent specification document. The latter is used to satisfy the needs of the cooperation objectives. As a first step, we use agents to detect conflict. Then, we adopt protocols for the discussing a multi-agent system for the negotiation phase (contract net protocol and heuristic protocol). During the resolution of conflicts, our negotiation phase resolves mainly three types of conflicts: contradiction conflicts, unclear requirements, and conflicts deviated from the norms.
The rest of the paper is organized as follows: In Section 2, we discuss studies and works related to the RE field. Section 3 presents the proposed approach and the motivation behind our technical choices. We illustrate, in Section 4, a case study and present some implementation aspects of the prototype developed to validate our proposition. Section 5 presents a discussion of our work. The conclusion and carried-out perspectives are presented in the last section.
Literature review
In this section, we present an overview of the literature of the different existing RE models. In addition, we provide more details on the negotiation phase as it is the most important RE phase in our work.
Requirement engineering (RE) process
The RE process may include all or some of the RE phases, which are generally the elicitation, analysis, specification, negotiation, validation, management, and documentation.
Requirements elicitation is a task that consists in gathering information concerning the needs of the users to understand the problem and the field of application.
Requirements analysis focuses on examining, understanding, and modeling results of the elicitation phase in order to clarify the requirements, remove inconsistencies, and ensure completeness and non-redundancy.
Requirements specification consists in transcribing in a document all the requirements identified during the elicitation in a coherent form (e.g., UML, entity relationship, description logics, etc.).
Requirements negotiation aims to explain and consolidate the disagreements on the system requirements that are inevitable when multiple stakeholders are involved in the process.
Requirements validation focuses on the verification of the final requirements document to detect the conflicts, the omissions, and the deviations from standards.
Requirements documentation consists in documenting the requirements to allow the communication and approval of the requirements, as well as the traceability of the products of another work.
Requirements management is performed throughout the RE process. This step involves following the evolution or the change of the requirements, making the traceability, and controlling the various versions of these requirements.
We categorize the existing RE process models into four different models: linear, linear with interactions, hierarchical, and iterative.
In linear model, such activities as elicitation and analysis are performed sequentially in linear steps, where each step represents a phase of the RE process. The model proposed by [27] provides a linear process model resulting in a requirements documentation.
In the same manner as the linear model, a linear model with interactions supposes that it is possible to have interactions between activities. Thus, they have the possibility to be performed often forward and backward [15].
Non-linear models have been suggested after linear models by proposing an iterative process. An iterative model considers cyclical interactions between RE phases such as elicitation, specification, and validation, etc. Recent RE processes are based on the iterative model due to its flexibility and ability to provide better RE results [22]. The existing models in this category have basically the same principal, but they differ in some details such as the omission, addition or combination of the RE phases. In [38], the RE process considers only elicitation, specification, and validation phases. In another RE process proposed by [22], four phases of the RE processes are shown, namely, elicitation, specification, negotiation, and validation. However, the specification is combined with the documentation phase, and the validation phase is combined with the verification one. The specification phase is not always considered as a single phase as in [19, 12]. Indeed, it can be merged with the analysis phase when it has less importance for the RE process.
Wiegers [23] thinks that the lack of agreement over what to call the entire software requirements field can lead to further confusion. For this reason, he follows a hierarchical model and splits the domain of RE into sub-domains: requirements development and requirements management. Requirements development includes elicitation, analysis, specification, and verification tasks. In a hierarchical model, each of the requirements engineering key practices described below fits into one of these sub-disciplines. The deliverable results from requirements development is a baseline that constitutes an agreement among key project stakeholders as to the new product’s capabilities. During requirements management, the project controls changes in the requirements baseline and monitors requirements implementation.
We present in the next section some works that propose a solution to conflicting situations.
Negotiation and conflict resolution techniques
A negotiation process for resolving requirement conflicts is a must when several projects in a cooperative context lead to failure, especially, when their requirements are badly expressed and negotiated [6]. Failures are generally due to the difficulty to resolve conflicts of different stakeholders’ objectives and priorities. Indeed, it is quite challenging to handle conflicts among the stakeholders’ needs when each of them has a specific point of view. Consequently, many requirements negotiation techniques have been proposed [45] proposes a groupware requirements negotiation system (GRNS) that is capable of solving requirements negotiation difficulties by integrating EasyWinWin [3] quality assurance techniques [34, 35], and multi-criteria preference techniques [18]. The proposed model provides structured communication among stakeholders, reducing defects and decreasing their severity level as well as assisting stakeholders to understand other stakeholders’ perspectives to achieve an agreement. However, GRNS is not effective in detecting defects immediately throughout the requirements negotiation and can only be detected after completion of the entire requirements negotiation process. In addition, stakeholders agree that the GRNS process model is not effective in encouraging stakeholders’ involvement and trust, because it proceeds the negotiation process without the involvement of all stakeholders. Another work [48] proposes an agent-oriented approach for requirements engineering, which is based on a spiral model [2]. Requirements are captured in the form of User Story Cards (USCs) that are mapped to Agent Cards (ACs). USCs represent a user-oriented view of requirements, whereas AC is a developer-oriented view of requirements. Multi-Person-Decision-Making model is used as the negotiation process which aims to obtain a comprehensive and prioritized list of requirements. Furthermore, a study is required to prove that the proposed methodology results in higher satisfaction on the part of all stakeholders.
In [25], the focus is on electronic requirements negotiation, which is performed and supported by means of information and communication technology, in terms of communication support, decision support, and/or document management. The authors consider requirements negotiation as an iterative process of communication and decision making between customer and developer and, maybe, other parties who have the overall goal of agreeing on a software development process and outcome. On the other hand, the process of electronic requirements negotiation is a sophisticated one and requires adapted solutions. [37] focuses, in particular, on the negotiation and consensus making during requirements elicitation. The IC Model presented in this work supports the understanding of the communication factors that influence the consensus process during requirements negotiation. But, the IC Model developed in this work can serve only as a guide for future researchers and the confirmation for the IC Model factors and the relationships within the data should be considered as tentative, per now. [7] based there work on the WinWin system, a requirements negotiation tool that supports the collaboration of a number of stakeholders with the goal of identifying, analyzing, and reconciling requirements. The WinWin System is based on the WinWin negotiation model [3, 5, 14]. It revolves around four artifact types: Win Conditions, Issues, Options, and Agreements. The advantages of using the WinWin approach are increasing cooperativeness, focusing participants on key issues, reducing friction, and facilitating distributed collaboration. The main drawback according to [25] is that approaches besides the WinWin-group seem very promising. Unfortunately, most of these approaches are not continued and, thus, no recent work can be reported.
Boehm and Kitapci in [9] propose an approach, which has three primary elements: Theory W [6], The WinWin Spiral Model [2], and a collaborative groupware negotiation tool, EasyWinWin. This approach uses and updates the rationale artifacts and process to keep it in a win-win state. However, the Win–Win Spiral Process model and WinWin likewise try to provide stronger support for scalable-shared ontologies and for collaboration objectives, via the domain taxonomy and via the conceptual bases for collaboration and software development provided by Theory W and the Spiral Model. Nevertheless, the result of a WinWin negotiation is typically not a complete, consistent, traceable, testable requirements specification. Another extension of the WinWin-group is WikiWinWin [26], which is a potential successor to EasyWinWin; it establishes the Win Win approach on a wiki basis. This approach uses the good features of Wiki technology, like flexibility and easy to access. The authors state that WikiWinWin is a good choice for the collaboration activities of requirements negotiation. Though this system also has some limitations or shortcomings, its working mode for synchronous collaboration is not perfect. The level of automation is not high enough, as it still requires a great number of facilitation efforts. In another work based on WikiWinWin [49], the authors suppose that EasyWinWin has been less easy to adapt to the evolving nature of the requirements, for that they propose WikiWinWin, an integrated approach that leverages the Wiki collaboration technology and the successful practice of the shaper role, combines with the Value-Based System and Software Engineering (VBSSE) framework and collaboration techniques. This approach provides effective and robust support in gathering, understanding, and communicating needs; designs flexible tools to accommodate individual use; facilitates knowledge sharing by allowing easy content update and preserving history; reduces manual effort to improve efficiency. However, this approach still has a lot of limitations and shortcomings.
[44] proposes a process analysis and improvement approach that is based on modeling the requirements communication network of a software ecosystem. This approach is based on negotiation and network theory for analyzing and designing the flow of requirements through a software ecosystem. The approach supports the requirements engineering process engineers and managers in taking strategic decisions for resolving communication blockages, increasing overall requirements engineering productivity, and consciously assigning power to stakeholders. However, authors must understand how to model the networks when stakeholders belong to more than one group. Also, they must better understand the effect of node and link characteristics and of network structure on network properties. Finally, they must evaluate the impact of a process development approach based on requirements communication network modeling on a software ecosystem. [36], in their work, introduces a framework covering important dimensions of requirements negotiation, such as conflict resolution strategy, collaboration situation of the stakeholders, and level of negotiation tool support. The purpose of the framework is to help understand and classify existing and future research approaches and to increase awareness of the issues involved in defining and implementing requirements negotiation processes in practice. Further, the purpose of the framework is to assist experts to understand important issues when implementation negotiation processes. Authors in [17] present a systematic model, called “Multi-Criteria Preference Analysis Requirements Negotiation (MPARN)” to assist stakeholders to evaluate, negotiate, and agree upon alternatives among stakeholders using multi-criteria preference analysis techniques. The MPARN cooperates with the artifacts of the win-win analysis and produces systematically negotiated agreements using multi-criteria preference analysis techniques. Multi-criteria methodology potentially increases stakeholders’ levels of cooperation and trust without losing participants by removing as much bias as possible from a problem analysis, and providing a reasoned approach to a better negotiation process. Though, making decisions to evaluate alternatives is still an ad-hoc process; also, the process may lead to agreement by itself (although this is not guaranteed). [42], in her work, considers introducing the negotiation spiral model with the elaboration of supporting elements needed for the model in the requirements elicitation and analysis process. This negotiation process is based on a spiral model to accommodate the dynamic requirements engineering. Each round of the cycle resolves more requirements in conflict and achieves better resolution. The three elements to be considered during negotiation process with the spiral model are environment, judgment criteria, and resolution strategy. The number of iterations around the spiral can vary. Thus, the spiral can be exited after some or all of the conflicts have resolved. Ideally, the process should keep going around the spiral until everybody is satisfied with the agreed requirements. On the other hand, the amount of time and effort devoted to each process in iteration depend on the stage of the overall process and the type of system being developed. In another work [33], a model is proposed for requirements negotiation and its automated support. The model called Oz provides automated methods for conflict detection and resolution generation, an interactive resolution choice procedure, and records of the negotiation process. On the other hand, Oz is still in an experimental phase. It has not been applied in a real system development. Steve Easterbrook in his work [43] proposes a model of computer-supported negotiation. The model is based on the behavioral approaches used in organizational design and addresses the need to separate the people from the problem. The model has a support tool called Synoptic, which displays viewpoints side by side, allowing the participants to compare and annotate them. Inconsistencies noted by the participants are then used to prompt for underlying assumptions and issues. The goals of encouraging expression of conflict and providing productive resolution methods form the basis for this model. Hence, the model is prescriptive, without being a rigid formal process. Another weakness is that there is no way of ensuring that all applicable viewpoints contribute in the conflict resolution. It is not clear how these applicable viewpoints can be detected, especially in the presence of the mismatches in terminology. [46] presents a Compromise-Negotiation framework based on Game theory to eliminate requirements inconsistency aim to solve the inconsistency problem of the requirements set caused by change. Authors apply Game theory to the problem of changing requirements. The inconsistency caused by the changes can be regarded as the interest conflict between the requester of changing requirements and the maker of the original requirements. The main drawback is that authors must propose more perfect and comprehensive frameworks to manage the changes in requirements. Therefore, other conflict resolution techniques have been proposed [39, 16, 40, 28]. Most of these techniques use either a prioritization process or a multi-criteria process. The techniques using prioritization are based on classifying stakeholders by priorities. Thus, less prioritized stakeholders receive less attention during the conflict resolution [16]. The techniques of multi-criteria are based on a framework of discussion. Indeed, an agreement between stockholders is not always guaranteed.
Another informal approach for conflict resolution such as Win-Win conditions [4, 5, 8] provides a general framework for requirements negotiation without significant efforts of capturing, building, and reasoning knowledge base. However, it does not provide a systematic reasoning on how to resolve conflicts. In fact, when the stakeholders identify conflicts, they process in an ad-hoc manner to reach an agreement from alternatives (called “options”) and resolve conflicts. Additionally, there are often tradeoffs among win-win conditions that need to be balanced. Multi-criteria preference analysis provides a strategy to balance these tradeoffs, and a framework for discussion that can lead to resolution. We note that the existing negotiation approaches are generally semi-automated. [29, 24, 50] consider that fully automated approaches require a serious amount of knowledge of a specific domain, which makes them domain-dependent.
After discussing all works regarding negotiation in the requirements engineering process, we have proposed a new negotiation approach that is completely different from what exists in the literature. We gave more importance to the negotiation phase in the requirements engineering process by making it transversal. In other words, the negotiation phase is running throughout the requirements engineering process and can handle any conflicting situation in any phase of the latter. Our approach is divided into two steps, which are 1) Conflict detection: In this step, a conflict detection matrix has been proposed that is completed by the stakeholders of the system. This allows us to clearly define conflict situations; 2) The negotiation step: In this step, we use the negotiation protocols used in the multi-agent systems, this allows us to negotiate conflict situations by integrating the negotiation protocols of the latter under human control. Our approach is based on a centralized system, which is under the control of an analyst who controls all the negotiation system and collaborates with all the stakeholders in the system; this allows us to properly control our negotiation system, especially in the conflict detection step.
We noticed that the multi-agents platform provides an interesting, yet ideal environment for negotiating conflicts, making a negotiation system, and having less human interactions. This is motivated by the fact that the multi-agents platform is based on protocols that can help provide negotiation solution, which we discuss in the following section.
Negotiation in multi agents systems
The interesting property of each agent in the Multi-Agent System (MAS) is its high capacity to react and interact with the other agents. These interactions are usually defined as any form of action performed within the system of agents. MAS allows agents to participate to the satisfaction of a global goal. This participation allows the system to evolve toward one of its objectives and to have an intelligent behavior, regardless of the degree of complexity of the agents that compose it. On the other hand, every agent is autonomous [32] and must arrive to find solutions dynamically, while it attempts to solve problems.
Negotiation in a MAS platform is seen as a process in which a common decision must be made by engaging two agents or more. Therefore, agents are engaged to satisfy the goals or objectives of the cooperation. Actually, there are a number of negotiation techniques in the field of MAS. We present two of these techniques that are relevant to our research work for solving conflicts in an RE context.
The Contract Net Protocol (CNP) [41] is a negotiation protocol between two types of agents: manager and contractor(s). In the CNP, the agent manager announces a task to the different agents of the environment (the contractors). The agents send to the manager their proposals that indicate their capacity to carry out the task. The manager gathers all the proposals and allocates the task to the agent that has made the best proposal.
The heuristic protocol technique is based on negotiating every discussable point between two agents by sending a proposal from one agent and receiving a counter-proposal from the other. This process continues until receiving an accept-proposal from one agent. Therefore, the agents must detect in a heuristic way which proposal or counter proposal he/she must further detail or accept.
The reason behind giving a special attention to the contract net and heuristic protocols is based on their capabilities as a negotiation technique. Indeed, they benefit from the advantages of the MAS platform and they provide, at the same time, the following properties that are essential to a negotiation framework.
They have a local process that does not involve a centralized control, The exchange of information takes place in both directions, Each party in the negotiation evaluates the information from its own perspective, They represent the same real world negotiation aspects, which occur among humans.
Based on these properties, a negotiation process can reach a mutually acceptable arrangement, especially when the conflicts are well defined. For the latter, we propose an approach that detects conflicts and uses the contract net and heuristic protocols for the negotiation phase.
In this section, we detail our proposed negotiation approach that we call NegoRE (Negotiation in Requirements Engineering). In order to ensure a smooth running of our approach, it is important to adopt one of the existing requirement engineering models that best suits our approach. In our case, we adopted the iterative model with little change by making the negotiation phase transversal to the RE process as in Fig. 1. Our choice is motivated by the fact that we are forced to make backtracking between RE phases in order to clarify, correct or, again, remake requirements. Consequently, we will not waste time to carry out solutions to conflict situations.
The adapted requirement engineering process.
Since NegoRE implies an asynchronous cooperation in a CIS environment, it therefore functions in a complex environment, which is emerging as distributed knowledge. In such environments, the agent paradigm is the most suitable technology to apply in order to improve the negotiation in a cooperative context. On the other hand, Agents are capable of interacting between each other to interpret and accomplish their tasks, particularly in the situation where agents do not have all the same local purposes, (each agent represents a separate company).
Figure 2 demonstrates the physical architecture that NegoRE is based on. This architecture facilitates the interoperability and the accessibility to information to negotiate. Additionally, it supplies to partners the same functionalities as if they are in the same place. Indeed, it is a question of resolving conflicts between requirements.
Negotiation architecture-based agent.
Different components: Each agent represents a company that is well established in a particular field. This is defined in the profile of each agent, in order to help the other agents choose the right partner during the negotiation. We have classified these agents in two groups: specific agents and cooperative agents.
Specific agents: they are divided into two agents: an analyst agent that manages the NegoRE system, and a negotiation agent that is responsible for the negotiation scenes. These two agents have complex tasks to realize; they handle the other agents and their negotiation. Additionally, they maintain a record of what is happening throughout the system.
Cooperative agents: they represent any agent with which the negotiation agent plans scenes of negotiation to try to eliminate the existing conflicts among requirements from the system to develop.
The suggested architecture contains also storage components:
Register for agents that contain the agent’s profile and coordinates for selection of partners in the negotiation. Requirements, which is a database that contains all CIS requirements to facilitate the negotiation task.
After having presented the physical architecture of NegoRE, we present in the next section the different details of NegoRE phases.
Our solution of negotiation consists of two main phases as in Fig. 3: conflict detection, and negotiation.
Phase 1. Conflict detection
This phase detects the conflicts that may occur among the existing requirements before generating a report of conflicts. The detection is based on a matrix that we so-call Matrix of Conflict Detection (MCD). It has as rows and columns the requirements resulted from the RE process. Indeed, a matrix can serve as a tool for negotiation, since it permits to pinpoint compromises among the different requirements. In other words, MCD is a matrix of values’ correlation among the requirements. This phase has four steps as follows:
Empty matrix of conflict detection (MCD)
Empty matrix of conflict detection (MCD)
The proposed negotiation solution.
The analyst agent sends empty MCD matrices to all cooperative agents to be filled. Each cooperative agent fills the MCD in the following manner: in each cell if the same or two requirements are in conflict, the agent puts either a, b, c, as in Fig. 4.
It puts “a” for contradiction requirements; It puts “b” for unclear requirements (badly expressed); It puts “c” for requirements deviated from the norms. After filling all matrices by the cooperative agents, the analyst agent combines them into a global single matrix MCD. In other words, each cell of the global MCD takes the values of all the other MCD’s filled by cooperative agents as in Fig. 4. In Fig. 4, each cell where points are used in place of (a, b, or c) means that the related cooperative agent did not specify any conflict. It is important to note that the negotiation takes into consideration the rate of conflicts. The latter is calculated by the number of which cooperative agents have put a conflict for given requirements. More specifically, this rate helps eliminating useless negotiation scenes by considering the following points:
Requirements in contraction (type ‘a’) negotiation always take place. Requirements that are unclear or deviated with the norms (type ‘b’ and ‘c’) a Rate of Conflict (RC) is calculated:
where Once RC is calculated, the analyst agent gets a report of conflicts that has two tables, where the first one mentions the requirements in contradiction (of type ‘a’), and the second mentions the unclear and deviated from the norm requirements (type ‘b’ or ‘c’) with RC
Calculation of rate of conflict (RC)
Generation of a global MCD involving 3 cooperative agents.
After the generation of the report of conflicts, the analyst agent sends the latter to the negotiation agent to start the negotiation scenes.
Phase 2. Negotiation
The phase of negotiation applies models of negotiation (heuristic and contract-net protocol) according to the type of requirements conflict.
In the case of conflict in contradiction, the protocol heuristic is used, because it enables proper communication among two cooperative agents, where they can send either “Accept, Refuse, or Proposition” messages.
In the case of unclear or poorly expressed requirements, the contract net protocol is used. The latter helps resolving the case, where a requirement is unclear for the negotiation agent and must be sent to all cooperative agents, so they propose each a clarification. Then only one of those clarifications is accepted as the best by the negotiation agents.
In the case of deviation from the norms of requirements, the negotiation agent forces the cooperative agent and requires it to follow the norms and standards used in cooperation.
The details of these protocols and other processes related to our negotiation approach are well explained in Algorithms 1–3. Before presenting the algorithms, we define some used notations.
Nc is defined as the number of the cooperative agents such as
Once the analyst agent receives the filled matrices from the cooperative agents, a conflict report is generated in the GenerateConflictsReport() function. Indeed, in this function, the rate of conflict (RC) and fills the tables of the conflict report. Once all the negotiation scenes are completed, the final new data are added to the requirements specification document using the AddDataToRESpecificationDocument() function. During the negotiation scenes, it occurs that the analyst finds contradicted, blurred, or deviated from the norms of requirements that are managed in the RecheckExpressionOrRequirement() function. The latter has the responsibility to inform the negotiation agent in order to contact the cooperative agents about rechecking the specified conflicts.
The main responsibility of the negotiation agent is to monitor negotiation scenes. Firstly, it analysis conflicts report received from the analyst agent in ConflictsAnalysis(), in order to prepare the scene of negotiations. After this, it triggers the negotiation scenes between the cooperative agents. The MonitoringPhase() function is responsible for monitoring the scenes of negotiation in case any intervention by the negotiation agent is needed. Indeed, such interventions occur when a solution exists for the objective of the negotiation but the cooperative agents cannot achieve it.
The cooperative agent algorithm is a profile of how a single agent mainly works. It firstly fills an empty matrix with the type of corresponding conflicts and then starts to deal with them once the negotiation scenes are triggered. Lastly, the negotiation scenes’ final report is sent to the negotiation agent.
Another important point that characterizes the scenes of negotiation is that they cannot be all executed simultaneously unless their correspondent agents responsible for the negotiation are not involved in another scene. In addition, during the scenes of negotiation that are successfully negotiated, requirements may change. For this, analyst agent notifies cooperative agents to refill the matrices to regenerate a new MDC in order to eliminate useless negotiation scenes. For unsuccessful negotiation scenes, a log file is dedicated to save them so they can be treated in other upcoming negotiation scenes.
This section presents a case study that illustrates the application of our negotiation approach, as well as the implementation and tool aspects. We adopted a case study from a real world cooperation example in which a negotiation is needed. Since our approach is based on using agents, we use the JADE platform [31] (Java Agent DEvelopment framework) for the realization of our system.
The case study is about the construction of a cultural center, several companies and workshops that cooperate with each other for its realization, like an architecture office, carpentry workshop, masonry workshop, etc. All these companies and workshops build our cooperative information system as illustrated in Fig. 5.
Cooperative information system of a cultural center construction.
In this case study, we specifically treat the phase of constructing aluminum windows for the cultural center. In our system, only one representative from each company or workshop is assigned. This representative will be responsible for the agent who represents his workshop or company on our cooperative information system.
In the following, we make a description of all the window construction steps. Then, we show how our negotiation approach works on conflict situations among different requirements. We additionally show the interaction between stakeholders to solve these situations.
Elicitation phase
This task is to gather information about the needs of users for the construction of the cultural center in order to try to understand the problem and the field, for that requires the involvement of all the stakeholders of our system. In this phase, we must understand, the domain, the problems encountered by customers, and expectations and constraints of customers.
Analysis and specification phase
We focus in requirements analysis on examining, understanding, and modeling results from the elicitation phase in order to clarify requirements, remove inconsistencies, and ensure completeness and non-redundancy. On the other hand, the specification phase consists in transcribing in a document all the requirements emerging during the elicitation in a coherent form.
These phases are important for the next step of conflict detection between the requirements. In order to simplify and make the step of conflict detection faster, we use the software Objectiver1 that gives a visualization aspect for the requirements as in Fig. 6.
A visual representation of the requirements using Objectiver.
Objectiver is an important tool for our approach, since we can avoid the use of the requirements’ document, which is usually used to represent the requirements. The requirements’ document is a text-based document and is generally difficult to treat. For this reason, we prefer a visual representation of the requirements that provide a fast and easy processing. Another interesting part in Objectiver is the fact that it helps analysts to easily discover conflicts among requirements. The conflict detection step is detailed next.
Table 3 represents the requirements needed for the construction of the aluminum window.
Requirements for construction of aluminum windows
Requirements for construction of aluminum windows
Detection of conflicts
In this phase, we use the matrix MCD for conflict detection and generate the report of conflicts. First, the analyst agent will send empty matrices for each stakeholder to be filled as in Fig. 7. After that, the analyst agent generates the matrix MCD See Fig. 8 and the report of conflicts from the filled matrices as in Tables 4 and 5.
Matrix filled by each representative.
Matrix of conflict detection (MCD).
For instance, R3 is in contradiction with R4, because R3 requires a wooden frame with the dimension 4
Contradiction requirements table
Fuzzy requirement table
Once the analyst agent generates the matrix MCD and the report of conflicts, it sends the latter to the negotiation agent to start the scenes of negotiation.
Protocol of negotiation
The cases of conflicts resulting from the report of conflicts are treated in the negotiation step. The negotiation step eliminates most of the detected conflicts. Negotiations for clarifying requirement R1 are illustrated in Fig. 9 and negotiations to eliminate the conflict between R3 and R4 are illustrated in Fig. 10.
Scene of negotiation to clarifying R1.
Comparative summary of the evoked RE processes
Scene of negotiation to eliminate the conflict between R3 and R4.
The main goal of this task is to validate and verify the specified requirements document. The validation of requirements according to EIA-632, focuses on verifying the final version of the requirements document for detecting conflicts, omissions, and deviations from standards [13]. In this phase, we seek to certify that the requirements meet the expectations of the stakeholders defined in the elicitation phase.
Management and documentation phase
The purpose of this phase is to involve a process of traceability and evaluation of the various phases of this approach. This phase is involved in every action done and journalizes it for reuse in similar cases, or when a change or modification of requirements, laws, or recommendations occur. The causes of evolution may result from each phase of our approach. Almost, stakeholders are the sources of these changes. Traceability is made to follow the origins of each action. If a change occurs, we can locate the origin of the action. In addition, we consider the evaluation to be able to control and examine the results of the negotiations carried out to improve the requirements and recommendations implied in the negotiation.
Discussion
A successful requirement engineering process should consider several characteristics that are necessary for a smooth negotiation process. In our proposed approach, we opted for two phases of conflict detection and negotiation that deploy techniques and an agent-based system which offers the following advantages.
Adaptability: This property is summarized in the fact to adapt the specifications documents through the intervention of different agents (analyst, negotiator, and CIS agents) upon detection of conflicts.
Perception: This property characterizes the analyst agent in order to perceive the conflicts.
Communication: In order to reach a compromise in conflict situations among stakeholders, the communication plays an important part by using the various interactions between the agents.
Autonomy: It is a property to represent each enterprise autonomy, especially that we consider a CIS context.
Conflicts management: it is the possibility to treat several types of conflicts by using the MDC.
In Table 6, we present a comparative study of RE processes and their characteristics in comparison with ours that is based on negotiation.
In this comparison, we tackled the model and type of requirements used by approaches and the fact if they support conflict management and a cooperation context. Additionally, we show the RE processes in which requirements evolution is supported or not. Moreover, this comparative study illustrates the advantages of our research in supporting functional and nonfunctional requirement types. On the other hand, our process is iterative with interaction among RE phases that help support requirements evolution. We consider that good inter-company cooperation implies the achievement of the common objectives of companies in a dynamic environment, while taking into account the different conflicts related to contradictions, unclear requirements, or even those substandard. In this context, we focus on the problem of conflict management between companies’ requirements. For this, we have given great importance to the negotiation phase in the RE process.
Conclusion
In this work, we proposed a negotiation approach in a cooperative context in order to benefit inter-enterprise cooperation. The purpose behind our research is to eliminate conflicts and contradictions among enterprise objectives, especially with the increasing heterogeneity of the environment and the definition of interests. For this, our approach treats the negotiation in the RE phase in order to reduce conflicts that may emerge between the stakeholders, as the context is cooperative. Indeed, Negotiation provides a flexible means for finding solutions to different conflict situations that may occur. We defined two steps in our approach where, in the first one, we detect conflicts between the requirements that are set by the stakeholders. The conflict detection uses a matrix that is to be filled with correlation variables used to indicate the type of the conflicts. The second step applies negotiation scenes, which consists in applying heuristic and contract net protocols related to the multi-agent systems for the resolution of the conflicts. Additionally, the negotiation process is transversal to the RE process and is not limited to a single phase or activity in that process. Consequently, conflicts are better supported, and, therefore, we minimize the maintenance step. As perspectives, we aim to add mechanisms to calculate the impact of change in the MCD matrix, in order to have a more sophisticated negotiation management. On the other hand, we aim to integrate ontologies in the representation of requirements to avoid complex semantic problems among the stakeholders.
Footnotes
Authors’ Bios