Supporting the Negotiation Life Cycle - Semantic Scholar

Supporting the Negotiation Life Cycle William N. Robinson Slav Volkov [email protected], (404) 651-3867 Department of Computer Information Systems Georgia State University Atlanta, GA 30301-4015

Introduction Negotiation is often associated with the strategic posturing prior to agreements among nations or between management and labor. Computer negotiation is often associated with the “handshake” protocol between connecting computer modems. In fact, both are types of negotiation behavior. So broad and powerful are the techniques, that many human interactions, and increasingly human computer interactions, can be classified as negotiation behavior. Negotiation is a difficult task, for humans or software agents. In this method, participants bring their goals to a bargaining table, strategically share information, and search for alternatives which are mutually beneficial. This negotiation “dance” is difficult in that a global understanding of all goals, solutions, and their interactions can be extremely complex. Firstly, participants may not know or want to reveal their goals. Secondly, solutions for some goals may have complex interactions with the solutions for other goals. The interactions can lead to participant conflicts or coalitions. Without negotiation techniques, participants often focus on persuading others to accept a ready solution, rather than seek new solutions which may be acceptable to all. Expert human negotiators address these problems through a combination of social and analytical techniques[19]. They provide strategic advice on when to generate new solutions and when to persuade others; moreover, they use a specific set of techniques for coordinating interactions, generating resolutions, and deriving agreements. Recently, a growing number of computer programs are employing these techniques to support human, as well as software agent collaboration. Negotiation systems are becoming ever more important because of the increasing opportunities for humans or software agents to interact. Negotiation systems can mediate human or software agent interactions in local environments, or over wide area networks. Such generality has led to a growth of embedding negotiation systems within group meeting systems, concurrent engineering and design tools, software agents, and electronic commerce systems. Where a group must agree on a description which has complex implications, negotiation systems succeed by bringing interaction analysis and consensus building techniques to bear. We expect future systems will use these techniques to provide quick and expert negotiation techniques to achieve user goals within the growing networked community. In the wake of negotiation’s importance and wide appeal lays a fragmented and dispersed research community. Herein, through our description of the negotiation life cycle, we aim to provide a framework for understanding automated negotiation. Prior frameworks are based on

Supporting the Negotiation Life-Cycle

GSU Working Paper CIS-96-05

The Negotiation Life Cycle

1

negotiation theory or design issues for negotiation systems[12][16]. Herein, we take an information processing perspective in drawing our analogy between the software development life cycle and the “negotiation life cycle”. Negotiation, like software development, moves through stages of requirements acquisition, specification, design, implementation, and maintenance. Like software development, negotiation automation varies with the life cycle stage; generally, more automation is provided for the “downstream” stages of negotiation design and implementation. Finally, like software development, different negotiation contexts call for different negotiation methodologies. This article describes processes, products, and perspectives of the negotiation life cycle and applies this framework to show: (1) how different life cycle phases have different support requirements, and (2) how existing tools differ in their level of support for these various phases. We illustrate the use of the framework by showing how it can guide the selection of negotiation support tools for a specific negotiation context.

The Negotiation Life Cycle Traditionally, negotiation is viewed as the actual interactions among participants to derive mutual commitment. Negotiation starts when participants begin communicating their goals, and ends (successfully) when all agree to a specified contract[20]. In expanding our analysis to the negotiation life cycle, we can consider the broad range of tools and techniques that are applied to negotiations[12][16]. In our view, the negotiation life cycle address steps directly leading to, or following from, the actual negotiation process; this includes the subprocesses of: initial problem recognition, participant solicitation and communication, goal analysis, solution generation, solution selection, solution implementation, and solution maintenance. In this context, a computerized negotiation system is a composite of computer techniques which support the social or analytical aspects of the negotiation life cycle. The negotiation life cycle has many similarities with the software life cycle—partly because both are exercises in formalization. However, the negotiation life cycle differs in some significant ways. First, analysis elicits participant goals, which allow for a range of satisfaction, as opposed to software requirements. Second, interaction design explicitly addresses individual achievement among competitors. Finally, the negotiation artifact (e.g., contract) is produced through interactions with competitors, as opposed to the teamwork of software development. On the other hand, some have characterized requirements analysis as having these same negotiation qualities[23]. The negotiation life cycle can be illustrated by considering a labor contract negotiation from the point of view of a company owner. Figure 1 illustrates the negotiation life cycle and an instantiation of it for labor negotiations. In the figure, processes such as analysis, design and implementation are shown as rectangles, while the products they produce are shown as notched rectangles. Finally, the bottom of the figure indicates roles of participants, called perspectives, at each phase in the life cycle. In the analysis phase, the owner (or representative) works with an analyst to describe and formalize what the company wants to achieve in current round of negotiations. In our example, the company seeks to increase profits by reducing labor costs. This can be achieved by increasing automation and subcontracting, and reducing the wages and fringe benefits of laborers; however, increasing subcontracting is the main purpose of negotiation. Once the company goals are established, a designer plans a persuasive strategy: the company negotiator Supporting the Negotiation Life-Cycle


Negotiation Perspectives

2

Life Cycle Model Describe & formalize owner goals.

Formal abstract goals, weighted preferences, constraints, alternatives.

Plan for achieving owner goals by interactions with other agent while using appropriate technology.

Agent interaction strategies and contingency models; Configuration of negotiation environment and tools.

Engage in agent interactions while using appropriate protocols and tools to best advantage for owner’s goals.

Negotiation documents describing mutual commitments of agents and negotiation record.

Labor Instance Describe & formalize the company goals

Company goals: automation(+) subcontract(+) wages(-) fringes(-)

Analysis Owner/Analyst

Plan for achieving company goals by interacting with the labor union

Bait&Switch: Initially indicate most important: automation, wages. Then, switch to: subcontracting

Interaction Design Designer/Technologist

Engage in interactions with the union using appropriate protocols and tools.

Contract: subcontract(+) — for parts only worker training(+) seniority(+)

Negotiation Facilitator/Negotiator

Figure 1. The negotiation life cycle and an instance of labor negotiation from the company point of view.

should initially suggest a reduction in automation and wages, but later should give in to some labor demands in exchange for an increase in subcontracting. Once the negotiation design is established, a company negotiator implements it by engaging the labor negotiator. The resulting contract may in fact specify the details under which the company can increase subcontracting, typically with some compensatory satisfaction for labor (e.g., worker training). The above example illustrates the broad scope of the negotiation life cycle as well as opportunities for automated support. It illustrates how the negotiation life cycle transitions from poorly defined, unstructured individual analysis to the synthesis of defined, structured, group constructs. Currently, there are a number of systems which support these transitions, both in human negotiations and in software agent negotiations. (See “Negotiation Systems” on page 4.) Through reviewing these systems, and our own efforts to create negotiation systems, we derived the negotiation life cycle framework. As illustrated in figure 1 and elaborated in the following sections, the framework consists of perspectives, processes, and products. After defining these negotiation dimensions, we show where existing tools and techniques support processes of the negotiation life cycle.

Negotiation Perspectives As shown in figure 1, the negotiation life cycle framework categorizes the roles of negotiation participants into analyst (owner and analyst), designer (designer and technologist), and implementor (facilitator and negotiator). Participants may have different roles within the negotiation process; for example, an owner is one who initiates the process, while a facilitator



Negotiation Perspectives

3

assists participant interactions. Conversely, a single participant may play multiple roles in the process. Finally, perspectives may be identified with individuals or groups. Each of the perspectives is describe next. An owner is an agent (or agents) who is the main stakeholder of the negotiation outcome. An owner initiates negotiations by setting forth abstract unstructured goals (e.g., reduce labor costs) prior to negotiation. An analyst works with an owner to refine, structure, and formalize an owner’s goals[16]. Additionally, the analyst may conduct domain analysis to place the abstract goals within the context of other alternatives, thereby defining the search space and making possible compromises and substitutions. Hence, good analysts are formalists with some experience with the domain. Once the owner goals are sufficiently understood, the designer contributes knowledge of the negotiation process; this is largely strategic meta-knowledge. The designer plans for a series of interactions with the other participants which will likely lead to the optimal satisfaction of the owner’s goals. Planning can entail developing a probabilistic contingency model based on strategic exchanges of information with the goal of persuading others to accept the owner’s preferred alternative[26]. The technologist and facilitator bridge the gap from the design to the actual negotiations; they design and provide the communication link between the participants. The goals of the technologist is to provide and maintain the best infrastructure for the participant interactions. This may simply involve reserving a meeting room, or it could involve the setup and running of a virtual decision room. The technologist specifies and maintains the appropriate technology for the designer's strategy, the size and duration of negotiation, and the mode of communication among the negotiators. In contrast, the facilitator conducts the actual negotiations. The facilitator’s goal is to

Negotiation Systems This graph summarizes the quantity and domain of the example systems we reviewed. For the most part, these are recent research projects. (More established groupware systems, such as decision support and group calendaring systems, have gone on to define classes of commercial systems, but are not represented in the graph[17].) The graph shows that most of the recent negotiation systems are from the growing field of software agents. Typically, these systems focus on conflict resolution among distributed software agents while they engaged in cooperative problem-solving, such as task distribution, network routing, or configuration[1][31]. Some concurrent engineering applications use such software agents, but many rely on a central agent to integrate work[13][15][24]. Typically, concurrent requirements engineering applications addresses policy definition, while concurrent design (and other downstream applications) focus more on resource allocation conflicts. Contract negotiation systems are similar to concurrent design in that they can be characterized as component configuration[14][17][29]. On the other hand, decision support systems typically address policy formation negotiations where issue definition and structure are key tasks[10][12][25].



Negotiation Processes

4

implement the strategy provided by the designer while using the technology specified by the technologist. The facilitator contributes the tactical knowledge, people (or agent) skills, hands-on use of technology, and the knowledge of appropriate protocols. This may involve governing the interactions when an arbitration protocol is used, or it may simply involve guiding participants toward a mutually beneficial alternative through persuasion. (The “Assisted Negotiation Example” on page 6 illustrates an automated facilitator for design.) Finally, the negotiator is the representative of the owner by proxy. The role of the negotiator is to “do” the negotiation within the specified framework on behalf of the owner. The negotiator may have specialized skills at strategically manipulating other negotiators, or even the negotiation framework. For human negotiators, this is the “charm” of a slick automobile salesperson. For software negotiation agents, this may include specialized algorithms or knowledge geared toward inferring other agents’ models and gaining their support. While actually physically separating the owner agent from the negotiator has advantages of specialization and parallelism, it does introduce the possibility of misrepresentation of the owners goals—especially for new or dynamic domains where the owner has yet to accept a consistent set of preferences.

Negotiation Processes Negotiation moves through phases similar to that of software development, with the initial phases focusing on what participants require and the subsequent phases defining how the requirements can be satisfied. During negotiation analysis, participant requirements are elicited and represented in agent models. Next, designers from all sides must agree on a negotiation protocol which will

Assisted Negotiation Example The Oz design system provided support for analysis and negotiation phases of the negotiation life cycle[22]. The figure below illustrates how Oz represented the goals of library system stakeholders—patrons desired an increased loan period, while librarian’s desired increased resource usage. During negotiations, Oz’s could detect interactions between goals; here, loan period and resource usage are negatively correlated. Finally, Oz was able generate a variety of types of resolutions to aid the search for a mutually agreeable alternatives. For example, Oz suggested that loan periods be distributed over subtype of patrons and resources (indicated as loan period x patron x resource), where some patrons (e.g., faculty) receive longer loan periods.

Describe & formalize the participant goals

Patron goals: loan period (+)

Library goals: resource usage(+)



Plan for achieving goals through cooperative design in Oz.

Cooperative Design in Oz: Honestly reveal goals, seek group solutions

Engage in analysis of models and their interactions, derive resolutions.

Interaction!: loan period (-) → resource usage (+) Compromise: loan period (0..n)

Reformulate: loan period x resource x patron





5

define how the interactions will proceed. Finally, negotiators actually present their goals, recognize conflicts, generate resolutions, and commit to an agreement. However, these negotiation phases need not proceed in a lock-step waterfall: participants may engage in “what if” scenario analysis prior to negotiations, agent models may be (and often are) updated throughout the life cycle, even the negotiation protocol or participant organization may change during negotiations[4]. During analysis, an agent model is created for the goals that a participant seeks to achieve, avoid, or maintain possibly under some constraints. For example, an agent may wish to achieve ownership of an automobile which increases their prestige, while fitting within the constraints of a limited budget. Such agent models are acquired through interactions with participants. Often, the result is a formal model such as a utility model[20]. Agent model acquisition various with the frequency of updates and the type of feedback participants receive on their goals. Automated systems can work accurately on behalf of a participant if they: (1) provide analysis of how their goals can be achieved, (2) provide analysis of how their goals interact with other participant’s goals, and (3) allow a participant to keep their model up-to-date with their thinking[16]. In the software life cycle, prototyping characterizes an approach to gain participant feedback and accurate participant modeling. Process-oriented decision theory follows a similar model of intertwining model updates with feedback on decision alternatives[11][31]. In this tradition, Oz negotiated design system provided feedback by graphically presenting interaction analysis derived from simulating plans and constraint analysis as participants updated their models[22]. Thus, like software developers, negotiators use prototyping to acquire agent models. As part of the design process, participants must agree on a negotiation protocol. A negotiation protocol defines how agents communicate through an ordered interchange of structured messages. For example, Robert’s Rules of Order is a protocol for conducting meetings which focuses on agent turn taking and voting. Software agent negotiation protocols are even more disciplined in that they define the structure of the messages. The design of the negotiation protocol is a critical aspect of the negotiation life cycle[26]. As agents run a negotiation protocol, they engage is four specific types of behavior: (1) revealing agent models, (2) identifying conflicts, (3) searching for alternatives (including conflict resolutions), and finally (4) selecting an alternative[19]. Clever agents can take advantage of a poor protocol by implementing specific strategies which lead other agents to accept inferior solutions. Similarly, the manner in which conflicts are addressed and their resolutions are sought can influence the quality of the negotiation outcome. A negotiation strategy refers to the plan by which an agent intends to interact with other agents while using a particular negotiation protocol. For example, agents may honestly reveal their preferences or be strategically deceitful to gain an advantage. In the automobile sales domain, salespeople may have no previous negotiation history and anticipate no future negotiations; hence, they may engage in a one-time negotiation strategy: maximize current sales without regard to prior or future sales. To carry out such a strategy, agents can influence negotiations by suggesting alternatives or strategically revealing their preferences. If a negotiation protocol is non-stable, agents can influence the outcome by providing inaccurate information[20]. For example, if two agents agree to deliver flyers to a neighborhood such that they collectively minimize their walking (as defined by the path from their home, through the neighborhood and back), then an agent could




6

lie about their home location so as to reduce their amount of work. Stable protocols can be designed to prevent such strategic posturing[26]. During negotiations, understanding the interactions of agent models is critical. If one has an understanding of the domain, semantic conflicts can be differentiated from simple syntactic differences; for example, variables x and y in two versions of the same program will not appear equal to a diff program (and therefore the program versions conflict); however, a slice analysis of the two programs may reveal that they are the same except for their names[3]. Conversely, two agents may hold identical goals (e.g., borrow(book,”x”)); however, these goals do in fact conflict because each agent wants the same resource. However, in many contexts, this is only a goal conflict—the apparent inconsistency of desired abstract states. Often, a goal conflict does not imply a means conflict—the unavailability of any specific alternative to achieve the goals. Hence, a goal conflict may be resolved by specifying a context in which each goal is achieved. In the case of borrowing books, one can alternate the time frame in which each agent has the book, i.e., they borrow in turns. Conflict understanding can have a significant influence on the resolution generation approach. If only syntactic differences can be understood, then resolution generation is limited to choice among the given alternatives. However, if the semantics of the conflict are understood, then the alternatives can be decomposed and resolutions can be generated based on their recombination. For example, price compromises are possible during automobile negotiation because agents understand the semantics of money. If the agents have a deeper understanding of the automobile domain, alternatives based on the configuration of the automobile, loan, and maintenance features can be generated. (See “Automated Negotiation Analysis Techniques” on page 9.)

utomated Negotiation Analysis Techniques utomated negotiation systems have a specialized techniques, including goal analysis and resolution eneration.

❑ Goal analysis methods overcome differences in terminology and classify goal interactions (e.g., conflicting, cooperative)[7][27]. Further analysis may be applied to the decision alternatives themselves in order to distinguish between apparent goal conflicts and actual means conflicts. Goal conflicts occur when two abstract contradictory goals are desired (e.g., x and not x). Some goal conflicts can be overcome by: (a) redefining the goals, or (b) defining the conditions surrounding their achievement (e.g., alternate between achieving x, then not x, then x, etc.). On the other hand, means conflicts occur when two specific contradictory goals are desired and there is no known method to achieve both.

❑ Resolution generation methods create new decision alternatives. These methods include[19]: ❑ Distributive compromise, which distributes some portion of a resource to different agent within the confines of a given constraint space. ❑ Integrative “logrolling”, which generalizes distributive compromise to include a set of resources. Then, one agent can be provided satisfaction on one subset of resources in trade for another agent’s satisfaction on a complementary set of resources. ❑ Reformulation, which generates alternatives by modifying agent goals in order to find the best mutually satisfactory alternative. Reformulation may simply involve an agent “backing-off” and providing less contentious goals. However, reformulation can involve an analysis of the contextual conditions causing conflict, followed by the introduction of goals which alleviate the conflict. For example, conflicts over non-consumable resources can often be resolved by alternating usage, or even creating more resources[22].



Negotiation Products

7

Finally, the manner in which agents select a solution can also be critical. The particular method is defined during protocol design. For example, the flyer delivery and automobile negotiations are examples of distributed decision-making—no single authority determines the final outcome. In contrast, disputants appearing before a judge illustrate centralized decisionmaking. While such a centralized protocol may not appear to be “negotiation”, the difference as to which and how many agents make the final decision is mainly architectural. In fact, groups can switch between centralized, representative, or distributed architectures to gain different degrees of efficiency or participation[4].

Negotiation Products Negotiation can be characterized as the search for an alternative which satisfies a set of agent models[20]. Initially, during analysis, participant goals are captured in agent models. At this point, goal conflicts may be noted. Later, during negotiations, the search for a mutually satisfactory alternative begins. During search, cooperating and competing interactions among alternatives and agent models become apparent. Finally, if successful, a deal will be struck. The deal indicates the conditions under which the participants are committed to the alternative. Thus, agent models, alternatives, conflicts, deals, and their relationships are key negotiation products which should be tracked throughout the negotiation life cycle. Figure 2 illustrates a negotiation meta-model which shows relationships among agent models, alternatives, conflicts, and deals. Using an entity relationship diagram notation, it shows that: solution alternatives can fulfill agent goals, alternatives can be composed of other alternatives, deals are composed of alternatives agreed upon by agents, deals can be composed of subdeals, and goals or alternatives can cause conflicts. It also shows some of the refined components of the four basic entities. For example, there are two basic types of conflict: goal and means; three basic types of goal satisfaction within a deal: goal achievement, goal avoidance, and goal maintenance (continued achievement over time, e.g., safety). Additionally, the figure shows attributes of the basic entities; for example, agent models are held by owners, deals have a status (accepted, unaccepted), a time-frame, and a binding, alternatives may have a number of associated attributes. The negotiation meta-model of figure 2 is a combination of two software requirements metamodels. The agent model indicates how goals stem from basic issues in the problem environment[21]. For example, an issue such as, “how can the company increase its value to stockholders?”, could lead to preferring the goal of increasing subcontracting. Goals can be linked to alternatives by goal reduction (subgoaling), constraint introduction, and finally assigning the responsibility of actions to particular agents[6]. Reconsider the labor negotiation example to see how negotiation entities are used throughout the life cycle. During the analysis phase, the two participants, company A and union B, develop their agent models. The company model generally includes goals which lead to higher company profits, while the union model includes goals which lead to higher union status and member compensation. Each participant generates a variety of alternatives which indicate how their goals can be fulfilled; for example, a1 = company subcontracting can include parts of type x, a2 = starting salary is $y, a3 = company contribution to union pension is $z. Additionally, the participants may structure deals in which these alternatives are achieved.; for example, company A will be contractually bound to provide for union B: a1, a2, a3 from 1/1/96 through 12/31/98. Next, the participants design their negotiation strategy and begin negotiations. As the participants begin to reveal their preferred goals, alternatives, and deals, they will discover interactions; for example,



Tools and Notations of the Negotiation Life Cycle

8

Deal

Agent Model

Binding Time-frame Status etc. Satisfaction Isa Achieve

accept 0:n

Avoid

Isa Maintain

Issue 0:n

2:n

1:1

Isa

Owner

achieve mode 0:n

Generate 0:n 1:1 Reduction Goal 1:1 Evaluate

0:n Preference

composed-of 0:n

1:1

1:n

0:n

part-of

cause

1:n

fulfill

Alternative ID Time Location etc.

Conflict

0:n

Conflict

0:n Constraint 0:n

Ensures 0:n

0:n Input 0:n Action 0:n Output 0:n Object

cause 0:n

0:n

Isa Means Conflict

Isa

0:n

Goal Conflict

composed-of 1:1

Figure 2. A meta-model of negotiation products.

the goal conflict: reduce union wages ≠ increase union wages. Eventually, if successful, they will generate a mutually agreeable deal. Perhaps not surprisingly, we have found that the more complete a system’s negotiation metamodel is, the more automation the system can provide. For example, if a system explicitly represents agents or agent classes, then a conflict over the cost of a resource for agents may be resolved by predicating the cost on agent subclasses. In fact, this is an instance of a general reformulation rule which attempts to remove conflict by predicating the conditions under which they occur—the more complete a representation, the more opportunities the system has to generate reformulations. (See “Automated Negotiation Analysis Techniques” on page 9.) Of course, this is a double edged sword in that increased expressiveness also increases search complexity. Nevertheless, a common goal of negotiation systems is to increase the number of interesting resolution alternatives for participants. This can be done through a more comprehensive meta-model and ensuring that reformulation methods consider all aspects of the meta-model. (Such complete representations coupled with appropriate control heuristics is becoming a common theme for resolution generation research[2][22].) In general, if negotiations are anticipated, and in fact happen frequently, domain models or even participant specific models can be of significant help[15][28]. However, if negotiations are not anticipated or occur infrequently, then a domain model may not be available, in which case only domain independent support can be provided[10].

Tools and Notations of the Negotiation Life Cycle In this article, we have attempted to show that negotiation communication exchanges are but one



Tools and Notations of the Negotiation Life Cycle

9

part of an overall negotiation life cycle. Elaborating on this theme, we illustrated how perspectives, processes, and products vary throughout the life cycle. Thus, each phase of the negotiation life cycle has a different purpose with different requirements. While these requirements overlap, we can roughly divide the requirements into three phases and suggest where current tools and notation are applicable. Figure 3 again illustrates the negotiation life cycle, but shows where tools and notations are most applicable. In the first phase of the life cycle, negotiation analysis seeks to acquire and model individual preferences. Decision theory, and specifically utility theory, supports this phase in that it describes how to acquire and model individual preferences[20]. Requirements engineering theory adds to this initial stage by providing automated methods for goal-directed analysis of models and deriving alternatives[6]. From the resulting agent models and analysis, negotiation protocols and strategies can be defined. In the second phase of the life cycle, negotiation design seeks to define interaction protocols and strategies. Traditionally, game theory has been used for negotiation strategy design. It provides analytic techniques for modeling competitors and defining actions contingent on competitor actions. More recently, this technique has been adapted to defining software agent negotiation protocols and strategies[18][26]. In the third phase of the life cycle, negotiation implementation seeks to reach group commitment through a series of communicative exchanges. Groupware provides the infrastructure for human communication, while “agentware” such as the KIF protocols provide a framework for agent communication[9]. The content of negotiations must also be addressed; this includes, conflict analysis, resolution generation, argumentation, and arbitration. Currently, researchers are attempting to automate aspects of these processes. Much work remains to extend the support of the negotiation life cycle. Particularly difficult, but important, has been the work on generating creative and appropriate conflict resolutions. Currently, analytic techniques, such as constraint analysis, can find optimal alternatives within a constrained space; however, generating a new alternative, perhaps outside the defined solution boundary, often produces many uninteresting solutions or none at all. Moreover, other “downstream” processes still remain unexplored. For example, how does one maintain a negotiated agreement? For human agreements, this entails a plan of monitoring and recovery Tools

Tools

•decision theory •utility theory •requirements theory

Notation •issues •goals •preferences •constraints •weighted utilities


Tools

•game theory •protocol analysis •speech-act theory

Notation •protocols •strategy models

•groupware •conflict analysis •resolution generation •arbitration theory •argumentation theory


Notation •agent models •conflicts •alternatives •deals


igure 3. Types of notation and tool support for the negotiation life cycle.



Conclusions

10

(perhaps including sanctions). Software agent agreements may employ a similar methods[8].

Conclusions Negotiation systems assist group problem-solving in a variety of domains through a common set of techniques. Their broad appeal has led to a niche of literature within the decision science, computer science, and management of information systems fields. They are particularly amenable to problems where networked participants seek complex agreements in well defined domains. In such cases, negotiations systems can bring to bear communication protocols, constraint analysis, conflict classification, and knowledge-based resolution generation. We expect negotiation systems will grow with the increase in networked communication and the reliance on software agents for managing personal and corporate commitments.

Acknowledgment The authors would like to thank Peggy Beranek, Sandeep Purao, and Detmar Straub for their comments on previous drafts of this paper. This work was supported, in part, through a grant from the Georgia State University College of Business Administration.

References [1] [2] [3] [4] [5] [6] [7] [8]

[9] [10] [11] [12] [13]

[14] [15] [16]

AAAI, Workshop on Models of Conflict Management in Cooperative Problem Solving, AAAI, Seattle, Wa, August 4, 1994. Boehm, B., In, H., Identifying Quality-Requirement Conflicts, IEEE, Software, March, 1996, 25-36. Binkley, D., Horwitz, S., and Reps, T., Program Integration for Languages with Procedure Calls. ACM Transactions on Software Engineering and Methodology 4, 1 (January 1995), pp. 3-35. Constantine, L.L., Work Organizations: Paradigms for Project Management and Organization, ACM, CACM, October, 1993, 34-43. Conry, S., Meyer, R., and Lesser, V., Multi-Stage Negotiation in Distributed Planning, Eds. A.H. Bond, L. Gasser, Readings in Distributed Artificial Intelligence, Morgan Kaufmann, San Meteo, California (1988) 367-384. Dardenne, A., van Lamsweerde, A., Fickas, S., Goal-Directed Requirements Acquisition, Science of Programming, Elsevier, 20, 1993, 3-50. Easterbrooke S., Co-Ordinating Distributed ViewPoints: the Anatomy of a Consistency Check, Concurrent Engineering: Research & Applications, CERA Institute, (2), 1994. Fickas, S., Feather, M.S., Requirements Monitoring in Dynamic Environments, Proceedings of the 2nd Inter national Symposium on Requirements Engineering, IEEE Computer Society Press, York, England (March 1995) 140-147. Genesereth, M.R., Ketchpel, S.P., Software Agents, ACM, Communications of the ACM, 37 (7), July 1994, 4853. Hamalainen, R.P., O. Leikola, Spontaneous Decision Conferencing in Parliamentary Negotiations, IEEE, Proceedings of the 28th Annual Hawaii International Conference on Systems Sciences, 1995, 290-299. I. Janis, L. Mann, Decision Making: a Psychological Analysis of Conflict, Choice, and Commitment, The Free Press, New York, 1979. Jelassi, M.T., Foroughi, A., Negotiation Support Systems: An Overview of Design Issues and Existing Software, North-Holland, Decision Support Systems, (5), 1989, 167-181. Kannapan, S.M., Marskek, K.M., An Approach to Parametric Machine Design and Negotiation in Concurrent Engineering, in Concurrent Engineering: Automation, Tools, and Techniques, A. Kusiak (ed), John Wiley & Sons, 1993, 509-534. Kersten, G.E., Simulation and Analysis of Negotiation Processes: The Case of Softwood Lumber Negotiations, IEEE, Proceedings of the 28th Annual Hawaii International Conference on Systems Sciences, 1995, 252-261. Klein, M., Supporting Conflict Resolution in Cooperative Design Systems, IEEE, Transactions on Systems, Man, and Cybernetics, 21 (6), November 1991, 1379-1390. Lim, L., Benbasat, I., A Theoretical Perspective of Negotiation Support Systems, Journal of Management of Information Systems, Winter, 9 (3) 1992-1993, 27-44.



References

[17] [18] [19] [20] [21] [22] [23]

[24]

[25] [26] [27] [28]

[29] [30]

[31] [32] [33]

11

Marca, D., Bock, G., (Eds.) Groupware: Software for Computer-Supported Cooperative Work, IEEE Computer Society Press, 1992. Matwin, S., Szpakowicz, S., Koperczak, Z., Kersten, G.E., Michalowski, W., Negoplan: An Expert System Shell for Negotiation Support, IEEE, Expert, 4(4) 50-62. Mazer, M., A Knowledge-Theoretic Account of Negotiated Commitement," CSRI-237, Univerity of Toronto (November 1989). Pruitt, D., Negotiation Behavior, Academic Press Inc.(1981). Raiffa, H., The Art and Science of Negotiation, Harvard University Press(1982). Ramesh, B., Dhar, V., Supporting Systems Development by Capturing Deliberations During Requirements Engineerng, IEEE, Transactions on Software Engineering, 1992, pp. 498-510. Robinson, W.N., “Interactive Decision Support for Requirements Negotiation”, Concurrent Engineering: Research & Applications, Special Issue on Conflict Management in Concurrent Engineering, The Institute of Concurrent Engineering, 1994 (2) 237-252. Robinson, W.N., Negotiation Behavior During Requirement Specification, Proceedings of the 12th International Conference on Software Engineering, IEEE Computer Society Press, Nice, France (March 26-30 1990) 268-276 Robinson, W.N., Fickas, S. Supporting Multi-Perspective Requirements Engineering, First International Conference on Requirements Engineering, IEEE, (April 18-22 1994) 206-215. Shakun, M.F., Airline Buyout: Evolutionary Systems Design and Problem Restructuring in Group Decision and Negotiation, The Institute of Management Sciences, Management Science, 37(10), (October 1991), 1291-1303. Rosenschein, J., Zlotkin, G., Rules of Encounter, The MIT Press, 1994. Shaw, M., Gaines, B., A Methodology for Recognizing Consensus, Correspondence, Conflict and Contrast in a Knowledge Acquisition System, Workshop on Knowledge Acquisition for Knowledge Based Systems, Banff (November 7-11, 1988) Sycara, K., Resolving Goal Conflicts via Negotiation, Proceedings of the AAAI-88, (1988) 245-250. Teich, J.E., Wallenius, H., Kuula, M., Zoints, S., A Decision Support Approach for Negotiation with an Application to Agricultural Income Policy Negotiations, Elsevier Science, European Journal of Operational Research, 81 (1995) 76-87. Velthuijsen, H., Distributed Artificial intelligence for Runtime Feature-Interaction Resolution, IEEE, Computer, Vol. 26, No. 8, August 1993, 48-55. Yakemovic, K., Conklin, J., Experience with the gIBIS Model in a Corporate Setting, Proceedings of CSCW 90, Los Angeles, 1990. Zeleny, M., Multiple Criteria Decision Making, McGraw-Hill(1982).

