A novel negotiation approach for requirements engineering in a cooperative context

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

Requirements engineering requirements conflict negotiation cooperative information systems multi-agent systems

1. 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.

2. 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.

2.1 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.

2.2 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.

2.3 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.
3. Proposed negotiation approach

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.

Figure 1.

The adapted requirement engineering process.

3.1 NegoRE physical architecture

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.

Figure 2.

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:

•

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.

3.2 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:

Table 1
Empty matrix of conflict detection (MCD)

	Requirement 1	Requirement 2	Requirement 3	…
Requirement 1
Requirement 2
Requirement 3
….

Figure 3.

The proposed negotiation solution.

Step 1. Step 1.

The analyst agent sends empty MCD matrices to all cooperative agents to be filled.

Step 2.

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.

Step 3.

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:

$\displaystyle\textit{RC}=N/U$ (1)

where $N$ is the number of cooperative agents that announced that a requirement presents a conflict, and U is the total number of the analysts. Such a negotiation scene considers only those with RC $\geqslant$ 0.5. For instance, the example of Fig. 4 would generate the following rates for requirements resulting of types ‘b’ or ‘c’ (Table 2).

Step 4.

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 $\geqslant$ 0.5.

Table 2

Calculation of rate of conflict (RC)

Requirements	Responsible agent	Index rate
R1	A1	0.66
R2	A2	0.00
R3	A3	1

Figure 4.

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 $\textit{Nc}=\{\textit{CoopAgent}_{1},\textit{CoopAgent}_{2},\ldots$ $\textit{CoopAgent}_{n}\}$ . Let ListM be a set containing $n$ number of matrices of the same size, where the number of lines and columns is equal to the number of requirements. ListM $=\{M_{1},M_{2},\ldots M_{n}\}$ . The $n$ number here should always be equal to the Nc number. When all matrices in ListM are merged together, they are contained in a single new matrix that we denote $M_{\textit{global}}$ . The latter has also the same size as the rest of matrices in ListM.

Algorithm 1. Analyst agent

Begin

//Step 1: Sending matrices to cooperative agents

For each

M_{i}

in ListM

Send

M_{i}

to the corresponding CoopAgent(

M_{i}

);

//Step 2: Receiving filled matrices from cooperative agents

For each

M_{i}

in ListM

Replace empty matrix

M_{\textit{i\_old}}

with filled received matrix

M_{\textit{i\_new}}

;

//Step 3: Creation of

M_{\textit{global}}

For each

M_{\textit{i\_new}}

in ListM

Fill each cell (

i, j

) of

M_{\textit{i\_new}}

in the same position (

i, j

) of

M_{\textit{global}}

;

//Step 4: Generating conflict report using

M_{\textit{global}}

If all cells in

M_{\textit{global}}

are not empty

{

String Report

=

GenerateConflictsReport(

M_{\textit{global}}

);

Negotiator.agent(Report) //Step 5: Sending conflicts report to the negotiation agent

}

//Step 6: Receiving the result of the negotiation from negotiation agent

String NegoResults

=

LocalNegotiationReport;

If all negotiation scenes in NegoResults are well negotiated

AddDataToRESpecificationDocument(report);

Elseif exists (contradiction

\|

blurred

\|

deviated from norms, requirements)

{

RecheckExpressionOrRequirement(requirement, probType);

Return to Step3 and regenerate a new

M_{\textit{global}}

;

}

AddDataToRESpecificationDocument(report);

End

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.

Algorithm 2. Negotiation agent

Begin

//Step 1: Receiving conflicts report from analyst agent

String LocalConflictsReport

=

Report;

ConflictsAnalysis();

//Step 2: Triggering the negotiation scenes between cooperative agents

CooperativeAgents.Start(TypesofConflicts);

//Step 3: Receiving the result of negotiation from cooperative agents

String LocalNegotiationReport

=

NegotiationRes;

MonitoringPhase(LocalNegotiationReport);

While (cooperative scenes not ended)

{

If (updates received from any cooperative.agent)

MotitoringPhase.UpdateData();

}

//Step 4: Sending negotiation results to analyst agent

Analyst.agent(FinalNegotiationReport);

End

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.

Algorithm 3. Cooperative agent

Begin

//Step 1: Filling a specified matrix

For each cell

i

in matrice

M_{i}

For each cell

j

in matrice

M_{i}

{

if (Contradiction requirements detected)

cell (

i,j)=

“a”;

elseif (Blurred requirements detected)

cell (

i,j)=

“b”;

elseif (Deviated from norms requirements detected)

cell (

i,j)=

“c”;

}

//Step 2: Sending matrix to analyst agent

Analyst.agent.NewMatrix(

M_{\textit{i\_new}}

);

//Step 3: Treating negotiation scenes

If (negotiation scenes triggered by negotiation agent)

{

If (case of contradiction requirements)

HeuristiqueProtocole.Start();

If (case of deviated from norms requirements)

RedefiningNewAdequateNorms(old norms, cooperation norms);

If (case of blurred requirements)

{

If (BlurredRequirement can be clarified to the negotiation agent)

NewClarifiedRequirement

=

Corrected(BlurredRequirement);

NegotiatorAgent.Notify(NewClarifiedRequirement);

Else (BlurredRequirement cannot be clarified)

ContractNetProtocole.Start();

}

//Step 4: Sending results of the negotiation scenes to the negotiation agent

String NegotiationRes

=

Saved negotiation scenes;

Negotiator.agent (NegotiationRes);

End

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.

4. Case study and some implementation aspects

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.

Figure 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.

4.1 Application of the proposed approach

4.1.1 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.

4.1.2 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.

Figure 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.

4.1.3 Negotiation phase

Table 3 represents the requirements needed for the construction of the aluminum window.

Table 3
Requirements for construction of aluminum windows

	Stakeholder	Description
Requirement 1 (R1)	Owner	Construction of aluminum windows
Requirement 2 (R2)	Architect	Provides the shape and dimensions of the windows, after discussion with the owner
Requirement 3 (R3)	Carpenter aluminum	For bonding an aluminum window, we must have a wood frame with the size 4 $\times$ 2 cm
Requirement 4 (R4)	Carpenter	For bonding a wood frame for windows on the wall, it must have the following dimensions 4 $\times$ 4 cm

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.

Figure 7.

Matrix filled by each representative.

Figure 8.

Matrix of conflict detection (MCD).

For instance, R3 is in contradiction with R4, because R3 requires a wooden frame with the dimension 4 $\times$ 2, but R4 requires it as 4 $\times$ 4. On the other hand, R1 is badly expressed, because the customer did not specify the shape of the window and its dimensions.

Table 4

Contradiction requirements table

Requirements	Responsible agent
R3; R4	Carpenter aluminum; Carpenter

Table 5

Fuzzy requirement table

Requirements	Responsible agent	Index rate
R1	Owner	0.75

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.

Figure 9.

Scene of negotiation to clarifying R1.

Table 6

Comparative summary of the evoked RE processes

[dir=NW, width=3cm, height=1cm]RE processesCharacteristics	Process model	Requirements type	Conflicts management Support	Inter-enterprise cooperation	Requirements evolution support
[dir=NW, width=3cm, height=1cm]RE processesCharacteristics	Linear with interactions	Nonfunctional	partially	No	No
Macaulay	Linear	Nonfunctional	No	No	No
Loucopoulos et Karakostas	Iterative	Nonfunctional	No	No	No
Pohl	Linear with interactions	Nonfunctional	partially	No	No
Ian sommerville	Iterative	Nonfunctional	partially	No	No
Wiegers	Hierarchical	Nonfunctional	No	No	No
Pandey and all	Iterative	Nonfunctional	No	No	No
NegoRE (Our process)	Iterative with interactions	Functional and Nonfunctional	Yes	Yes	Yes

Figure 10.

Scene of negotiation to eliminate the conflict between R3 and R4.

4.1.4 Validation phase

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.

4.1.5 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.

5. 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.

6. 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

http://www.objectiver.com/index.php?id=4&L=1.

Authors’ Bios

Chaouki Boulekdam is a PhD student. He is currently completing his doctoral thesis at the LIRE Laboratory in Constantine 2 – Abdelhamid Mehri University. He is a member of the research group “Information systems and Knowledge Bases”. His current research interests include Cooperative Information Systems, Requirements Engineering, and Negotiation.

Nacer eddine Zarour is a Professor since 2009 in the Department of Software Technologies and Information Systems at the University of Constantine 2, Constantine, Algeria. He received his Ph.D. Degree in Cooperative Information Systems from University of Mentouri Constantine in 2004. He served as the Chair of the Scientific Council of the Faculty of New Technologies of the Information and the Communication (NTIC) for the period 2013–2016. Currently, he is responsible of the domain (LMD) at the NTIC faculty. His current research activities are conducted at the LIRE laboratory. His research areas include advanced information systems, requirements engineering, Cloud Computing, and Big Data. He was and is responsible for several international (PHC CMEP Tassili) and national (CNEPRU) projects.

References

Chaib-Draa

Jarras

and Moulin

, Systémes multi-agents: principes généraux et applications, Edition Hermés 242 (2001), 1030–1044.

Boehm

, A spiral model of software development and enhancement, Computer 21(5) (1988), 61–72.

Boehm

and Ross

, Theory-W software project management principles and examples, IEEE Trans Softw Eng 15 (1989), 902–916.

Boehm

Bose

Horowitz

and Lee

M.J.

, Software requirements as negotiated win conditions, in: Proceedings of IEEE International Conference on Requirements Engineering, IEEE, April 1994, pp. 74–83.

Boehm

Bose

Horowitz

and Lee

M.J.

, Software requirements negotiation and renegotiation aids: A theory-w based spiral approach, Proceedings of ICSE 17 (April 1995), 243–253.

Boehm

, Anchoring the software process, IEEE Software 13(4) (1996), 73–82.

Boehm

and Alexander

, WinWin requirements negotiation processes: A multi-project analysis, Proceedings of the 5th International Conference on Software Processes 1998.

Boehm

and In

, Conflict analysis and negotiation aids for cost-quality requirements, Software Quality Professional (SQP), American Society for Quality (ASQ) 1(2) (1999), 38–50.

Boehm

and Kitapci

, The winwin approach: Using a requirements negotiation tool for rationale capture and use, in: Rationale Management in Software Engineering Dutoit

A.H.

McCall

Mistrík

Paech

, eds, Springer, Berlin, Heidelberg, (2006), 173–190. DOI https://doi.org/10.1007/978-3-540-30998-7_8.

10.

Nuseibeh

and Easterbrook

, The process of inconsistency management: A framework for understanding, in: Proceedings Tenth International Workshop on Database and Expert Systems Applications, DEXA, IEEE 99 (1999), 364–368.

11.

Nuseibeh

and Easterbrook

, Requirements engineering: A roadma, in: Proceedings of the Conference on the Future of Software Engineering ACM, May 2000, pp. 35–46.

12.

Pandey

Suman

and Ramani

A.K.

, An effective requirement engineering process model for software development and requirements management, in: International Conference on Advances in Recent Technologies in Communication and Computing, IEEE (October 2010), 287–291.

13.

Ansi

, EIA-632-1998 (R2003)-processes for engineering a system, Electronic Industries Alliance, (1999).

14.

Horowitz

, WinWin reference manual: A system for collaboration and negotiation of requirements, Center for Software Engineering, University of Southern California Technical Report, March 1996.

15.

Kotonya

Sommerville

, Requirements engineering processes and techniques, John Wiley & Sons, UK, 1998.

16.

Bendjenna

Charre

P.J.

and Zarour

N.E.

, Using multi-criteria analysis to prioritize stakeholders, Journal of Systems and Information Technology 14(3) (2012), 264–280.

17.

Hoh

Olson

Rodgers

, A requirements negotiation model based on multi-criteria analysis, Proceedings Fifth IEEE International Symposium on Requirements Engineering, Toronto, Ontario, Canada, Canada, Aug 2001, pp. 27–31.

18.

Hoh

and Olson

, Requirements negotiation using multi-criteria preference analysis, J Univ Comput Sci 10(4) (2004), 306–325.

19.

Sommerville

, Integrated requirements engineering: A tutorial, IEEE Software 22(1) (2005), 16–23.

20.

García-Flores

J.J.

, Annotation sémantique des spécifications informatiques de besoins par la méthode d’Exploration Contextuelle: une contribution des méthodes linguistiques aux conceptions de logiciels (Doctoral Dissertation, Paris 4), 2007.

21.

McGraw

and Harbison

, User-centered requirements: The scenario-based engineering process, L. Erlbaum Associates Inc, 1997.

22.

Pohl

, The three dimensions of requirements engineering: A framework and its applications, Information Systems 19(3) (1994), 243–258.

23.

Wiegers

K.E.

, When telepathy won’t do: Requirements engineering key practices, Cutter IT Journal 13(5) (2000), 9–15.

24.

Sycara

K.P.

, Problem restructuring in negotiation, Management Science 37(10) (1991), 1248–1268.

25.

Annika

Mareike

and Georg

, Requirements analysis as a negotiation process, in: Proceedings of the 15th International Conference on Group Decision & Negotiation Kamiński

Kersten

G.E.

Szufel

Jakubczyk

and Wachowicz

, eds, Warsaw School of Economics Press, Warsaw (2015), 303–309.

26.

Huang

and Zhang

, WikiWinWin: A wiki based system together with win win method for collaborative requirements negotiation, AASRI Winter International Conference on Engineering and Technology (AASRI-WIET 2013), (2013), https://doi.org/10.2991/wiet-13.2013.16.

27.

Macaulay

L.A.

, requirements engineering, SpringerVerlag London, Series on Applied Computing, London, UK, 1996.

28.

Amroune

, Pierre jean charrel, nacereddine zarour and jean michel inglebert, composition of aspectual requirements: A multi-criteria process for conflict resolution, Journal of Software Engineering 8(2) (2014), 75–88.

29.

Klein

, Supporting conflict resolution in cooperative design systems, IEEE Transactions on Systems, Man and Cybernetics 21(6) (1991), 1379–1390.

30.

Lubars

Potts

and Richter

, A review of the state of the practice in requirements modeling, in: Proceedings of the IEEE International Symposium on Requirements Engineering, IEEE (January 1993), 2–14.

31.

Wooldridge

, An introduction to multiagent systems, John Wiley & Sons, 2009.

32.

Jennings

N.R.

Faratin

Lomuscio

A.R.

Parsons

Wooldridge

M.J.

and Sierra

, Automated negotiation: prospects, methods and challenges, Group Decision and Negotiation 10(2) (2001), 199–215.

33.

William

N.R.

and Fiekas

, Automated support for requirements negotiation, AAAI Technical Report, WS-94-04.

34.

Grunbacher

Halling

Biffl

Kitapci

and Boehm

, Repeatable quality assurance techniques for requirements negotiations, in: 36th Hawaii International Conference on Systems Sciences, Los Alamitos, CA, USA, 36th Hawaii International Conference on Systems Sciences, 9 IEEE Computer Society, 2003.

35.

Grunbacher

Halling

Biffl

and Boehm

, Integrating collaborative processes and quality assurance techniques: experiences from requirements negotiation, J Manag Inf Syst 20(4) (2004), 10–30.

36.

Grunbacher

and Seyff

, Requirements negotiation, in: Engineering and Managing Software Requirements Aurum

Wohlin

, eds, Springer, Berlin, Heidelberg, 2005, pp. 143–162. https://doi.org/10.1007/3-540-28244-0_7.

37.

Jenny

and Jacob

L.C.

, Consensus making in requirements negotiation: The communication perspective, Australasian Journal of Information Systems 13(1) (September 2005). DOI: 10.3127/ajis.v13i1.72.

38.

Loucopoulos

and Karakostas

, System requirements engineering, McGraw-Hill, Inc, 1995.

39.

Louridas

and Loucopoulos

, A generic model for reflective design, ACM Transactions on Software Engineering and Methodology (TOSEM) 9(2) (2000), 199–237.

40.

Chitchyan

Rashid

Rayson

and Waters

, Semantics-based composition for aspect-oriented requirements engineering, in: Proceedings of the 6th International Conference on Aspect-oriented Software Development, ACM, March 2007, pp. 36–48.

41.

Davis

and Smith

R.G.

, Negotiation as a metaphor for distributed problem solving, Artificial Intelligence 20(1) (1983), 63–109.

42.

Ahmad

, Negotiation in the requirements elicitation and analysis process, 19th Australian Conference on Software Engineering, Perth, WA, Australia, March 2008, pp. 26–28.

43.

Easterbrook

, Resolving requirements conflicts with computer-supported negotiation, in: Requirements Engineering (ISBN: 0-12-385335-4), Academic Press Professional, Inc. San Diego, CA, USA, (1994), 41–65.

44.

Fricker

, Specification and analysis of requirements negotiation strategy in software ecosystems, Proceedings of the First International Workshop on Software Ecosystems, CEUR-WS, 2009, 19–33.

45.

Hazrina

S.B.

Siti.

S.B. S

and Shahamiri

S.R.

, A requirements negotiation process model that integrates easywinwin with quality assurance and multi, Criteria Preference Techniques, Arabian Journal for Science and Engineering 39(6) (June 2014), 4667–4681.

46.

Feng

Zhang

Y.R.

Jin

Zhang

, A compromise-negotiation framework based on game theory for eliminating requirements inconsistency, Tehnicki Vjesnik 22(5) (October 2015), 1085–1092. DOI: 10.17559/TV-20150731092521.

47.

Couturier

, L’ingénierie des systémes d’information coopératifs par réutilisation: Une approche á base de patterns (Doctoral Dissertation, Lyon 3), 2004.

48.

Gaur

Soni

and Bedi

, An agent-oriented approach to requirements engineering, IEEE 2nd International Advance Computing Conference (IACC), Patiala, India, February 2010, pp. 19–20. DOI: 10.1109/IADCC.2010.5422878.

49.

and Boehm

, Finding success in rapid collaborative requirements negotiation using wiki and shaper, 43rd Hawaii International Conference on System Sciences 1 (2010), 1–10.

50.

Robinson

W.N.

and Fickas

, Automated support for requirements negotiation, in: AAAI-94 Workshop on Models of Conflict Management in Cooperative Problem Solving, August 1994, pp. 90–96.

A novel negotiation approach for requirements engineering in a cooperative context

Abstract

Keywords

1. Introduction

2. Literature review

2.1 Requirement engineering (RE) process

2.2 Negotiation and conflict resolution techniques

2.3 Negotiation in multi agents systems

Phase 1. Conflict detection

Table 1 Empty matrix of conflict detection (MCD)

Phase 2. Negotiation

4.1.1 Elicitation phase

4.1.2 Analysis and specification phase

Table 3 Requirements for construction of aluminum windows

Detection of conflicts

4.1.5 Management and documentation phase

5. Discussion

6. Conclusion

Footnotes

Authors’ Bios

References

Table 1
Empty matrix of conflict detection (MCD)

Table 3
Requirements for construction of aluminum windows