Supporting the Negotiation Life Cycle - AMiner · Supporting the Negotiation Life-Cycle GSU Working ... We illustrate the use of the framework by showing how it can guide the selection

Supporting the Negotiation Life-Cycle GSU Working Paper CIS-96-05

Supporting the Negotiation Life Cycle

William N. RobinsonSlav Volkov

[email protected], (404) 651-3867Department 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 orbetween management and labor. Computer negotiation is often associated with the “handshake”protocol between connecting computer modems. In fact, both are types of negotiation behavior. Sobroad and powerful are the techniques, that many human interactions, and increasingly humancomputer interactions, can be classified as negotiation behavior.

Negotiation is a difficult task, for humans or software agents. In this method, participants bringtheir goals to a bargaining table, strategically share information, and search for alternatives whichare mutually beneficial. This negotiation “dance” is difficult in that a global understanding of allgoals, solutions, and their interactions can be extremely complex. Firstly, participants may notknow or want to reveal their goals. Secondly, solutions for some goals may have complexinteractions with the solutions for other goals. The interactions can lead to participant conflicts orcoalitions. Without negotiation techniques, participants often focus on persuading others to accepta ready solution, rather than seek new solutions which may be acceptable to all. Expert humannegotiators 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, generatingresolutions, and deriving agreements. Recently, a growing number of computer programs areemploying these techniques to support human, as well as software agent collaboration.

Negotiation systems are becoming ever more important because of the increasingopportunities for humans or software agents to interact. Negotiation systems can mediate humanor software agent interactions in local environments, or over wide area networks. Such generalityhas led to a growth of embedding negotiation systems within group meeting systems, concurrentengineering and design tools, software agents, and electronic commerce systems. Where a groupmust agree on a description which has complex implications, negotiation systems succeed bybringing interaction analysis and consensus building techniques to bear. We expect future systemswill use these techniques to provide quick and expert negotiation techniques to achieve user goalswithin the growing networked community.

In the wake of negotiation’s importance and wide appeal lays a fragmented and dispersedresearch community. Herein, through our description of the negotiation life cycle, we aim toprovide a framework for understanding automated negotiation. Prior frameworks are based on

The Negotiation Life Cycle 1


negotiation theory or design issues for negotiation systems[12][16]. Herein, we take aninformation processing perspective in drawing our analogy between the software development lifecycle and the “negotiation life cycle”. Negotiation, like software development, moves throughstages of requirements acquisition, specification, design, implementation, and maintenance. Likesoftware development, negotiation automation varies with the life cycle stage; generally, moreautomation is provided for the “downstream” stages of negotiation design and implementation.Finally, like software development, different negotiation contexts call for different negotiationmethodologies.

This article describes processes, products, and perspectives of the negotiation life cycle andapplies this framework to show: (1) how different life cycle phases have different supportrequirements, 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 negotiationsupport tools for a specific negotiation context.

The Negotiation Life Cycle

Traditionally, negotiation is viewed as the actual interactions among participants to derive mutualcommitment. Negotiation starts when participants begin communicating their goals, and ends(successfully) when all agree to a specified contract[20]. In expanding our analysis to thenegotiation life cycle, we can consider the broad range of tools and techniques that are applied tonegotiations[12][16].

In our view, thenegotiation life cycle address steps directly leading to, or following from, theactual 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 computerizednegotiationsystem is a composite of computer techniques which support the social or analytical aspects of thenegotiation life cycle.

The negotiation life cycle has many similarities with the software life cycle—partly becauseboth are exercises in formalization. However, the negotiation life cycle differs in some significantways. First, analysis elicits participant goals, which allow for a range of satisfaction, as opposed tosoftware requirements. Second, interaction design explicitly addresses individual achievementamong competitors. Finally, the negotiation artifact (e.g., contract) is produced throughinteractions with competitors, as opposed to the teamwork of software development. On the otherhand, some have characterized requirements analysis as having these same negotiationqualities[23].

The negotiation life cycle can be illustrated by considering a labor contract negotiation fromthe point of view of a company owner. Figure 1 illustrates the negotiation life cycle and aninstantiation of it for labor negotiations. In the figure, processes such as analysis, design andimplementation are shown as rectangles, while the products they produce are shown as notchedrectangles. Finally, the bottom of the figure indicates roles of participants, called perspectives, ateach phase in the life cycle. In the analysis phase, the owner (or representative) works with ananalyst to describe and formalize what the company wants to achieve in current round ofnegotiations. In our example, the company seeks to increase profits by reducing labor costs. Thiscan be achieved by increasing automation and subcontracting, and reducing the wages and fringebenefits of laborers; however, increasing subcontracting is the main purpose of negotiation. Oncethe company goals are established, a designer plans a persuasive strategy: the company negotiator

Negotiation Perspectives 2


should initially suggest a reduction in automation and wages, but later should give in to somelabor demands in exchange for an increase in subcontracting. Once the negotiation design isestablished, a company negotiator implements it by engaging the labor negotiator. The resultingcontract 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 asopportunities for automated support. It illustrates how the negotiation life cycle transitions frompoorly defined, unstructured individual analysis to the synthesis of defined, structured, groupconstructs. Currently, there are a number of systems which support these transitions, both inhuman 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 derivedthe negotiation life cycle framework. As illustrated in figure 1 and elaborated in the followingsections, the framework consists of perspectives, processes, and products. After defining thesenegotiation dimensions, we show where existing tools and techniques support processes of thenegotiation life cycle.

Negotiation Perspectives

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

Analysis Interaction Design NegotiationOwner/Analyst Designer/Technologist Facilitator/Negotiator

Describe &formalize thecompany goals Company goals:

automation(+) subcontract(+) wages(-) fringes(-)

Plan forachievingcompanygoals byinteractingwith thelabor union

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

Engage ininteractionswith theunion usingappropriateprotocolsand tools.

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

Describe &formalizeowner goals. Formal

abstractgoals,weighted pref-erences, con-straints,alternatives.

Plan forachievingowner goalsbyinteractionswith otheragent whileusingappropriatetechnology.

Agent interac-tion strategiesand contin-gency models;Configurationof negotiationenvironmentand tools.

Engage inagentinteractionswhile usingappropriateprotocolsand tools tobestadvantagefor owner’sgoals.

Negotiationdocumentsdescribingmutual com-mitments ofagents andnegotiationrecord.

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

Labor Instance

Life Cycle Model

Negotiation Perspectives 3


assists participant interactions. Conversely, a single participant may play multiple roles in theprocess. Finally, perspectives may be identified with individuals or groups. Each of theperspectives is describe next.

An owner is an agent (or agents) who is the main stakeholder of the negotiation outcome. Anowner initiates negotiations by setting forth abstract unstructured goals (e.g., reduce labor costs)prior to negotiation. Ananalyst works with an owner to refine, structure, and formalize an owner’sgoals[16]. Additionally, the analyst may conduct domain analysis to place the abstract goalswithin the context of other alternatives, thereby defining the search space and making possiblecompromises and substitutions. Hence, good analysts are formalists with some experience withthe domain.

Once the owner goals are sufficiently understood, thedesigner contributes knowledge of thenegotiation process; this is largely strategic meta-knowledge. The designer plans for a series ofinteractions with the other participants which will likely lead to the optimal satisfaction of theowner’s goals. Planning can entail developing a probabilistic contingency model based onstrategic exchanges of information with the goal of persuading others to accept the owner’spreferred alternative[26].

The technologist andfacilitator bridge the gap from the design to the actual negotiations; theydesign and provide the communication link between the participants. The goals of the technologistis to provide and maintain the best infrastructure for the participant interactions. This may simplyinvolve reserving a meeting room, or it could involve the setup and running of a virtual decisionroom. The technologist specifies and maintains the appropriate technology for the designer'sstrategy, the size and duration of negotiation, and the mode of communication among thenegotiators.

In contrast, the facilitator conducts the actual negotiations. The facilitator’s goal is to

these systems focus on conflict resolution among distributed software agents while they engaged incooperative problem-solving, such as task distribution, network routing, or configuration[1][31]. Someconcurrent engineering applications use such software agents, but many rely on a central agent to integratework[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 ascomponent configuration[14][17][29]. On the other hand, decision support systems typically address policyformation negotiations where issue definition and structure are key tasks[10][12][25].

Negotiation Systems

This graph summarizes the quantity anddomain of the example systems we reviewed.For the most part, these are recent researchprojects. (More established groupware systems,such as decision support and group calendaringsystems, have gone on to define classes ofcommercial systems, but are not represented inthe graph[17].) The graph shows that most ofthe recent negotiation systems are from thegrowing field of software agents. Typically,

Negotiation Processes 4


implement the strategy provided by the designer while using the technology specified by thetechnologist. The facilitator contributes the tactical knowledge, people (or agent) skills, hands-onuse of technology, and the knowledge of appropriate protocols. This may involve governing theinteractions when an arbitration protocol is used, or it may simply involve guiding participantstoward a mutually beneficial alternative through persuasion. (The “Assisted NegotiationExample” 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 isto “do” the negotiation within the specified framework on behalf of the owner. The negotiator mayhave specialized skills at strategically manipulating other negotiators, or even the negotiationframework. For human negotiators, this is the “charm” of a slick automobile salesperson. Forsoftware negotiation agents, this may include specialized algorithms or knowledge geared towardinferring other agents’ models and gaining their support. While actually physically separating theowner agent from the negotiator has advantages of specialization and parallelism, it doesintroduce the possibility of misrepresentation of the owners goals—especially for new or dynamicdomains 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 phasesfocusing on what participants require and the subsequent phases defining how the requirementscan be satisfied. During negotiation analysis, participant requirements are elicited and representedin agent models. Next, designers from all sides must agree on a negotiation protocol which will


Describe &formalize theparticipantgoals

Library goals: resource usage(+)

Plan forachievinggoalsthroughcooperativedesign in Oz.

CooperativeDesign in Oz:Honestly reveal goals, seek group solu-tions

Engage inanalysis ofmodels andtheirinteractions,deriveresolutions.

Patron goals:loan period (+)

Compromise:loan period (0..n)

Interaction!:loan period (-)→resource usage (+)

Reformulate:loan period x resource x patron

Assisted Negotiation Example

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



define how the interactions will proceed. Finally, negotiators actually present their goals,recognize conflicts, generate resolutions, and commit to an agreement. However, these negotiationphases need not proceed in a lock-step waterfall: participants may engage in “what if” scenarioanalysis prior to negotiations, agent models may be (and often are) updated throughout the lifecycle, even the negotiation protocol or participant organization may change duringnegotiations[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 achieveownership of an automobile which increases their prestige, while fitting within the constraints of alimited budget. Such agent models are acquired through interactions with participants. Often, theresult is a formal model such as a utility model[20].

Agent model acquisition various with the frequency of updates and the type of feedbackparticipants receive on their goals. Automated systems can work accurately on behalf of aparticipant if they: (1) provide analysis of how their goals can be achieved, (2) provide analysis ofhow their goals interact with other participant’s goals, and (3) allow a participant to keep theirmodel up-to-date with their thinking[16]. In the software life cycle, prototyping characterizes anapproach to gain participant feedback and accurate participant modeling. Process-orienteddecision theory follows a similar model of intertwining model updates with feedback on decisionalternatives[11][31]. In this tradition, Oz negotiated design system provided feedback bygraphically presenting interaction analysis derived from simulating plans and constraint analysisas participants updated their models[22]. Thus, like software developers, negotiators useprototyping to acquire agent models.

As part of the design process, participants must agree on a negotiation protocol. A negotiationprotocol 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 onagent turn taking and voting. Software agent negotiation protocols are even more disciplined inthat they define the structure of the messages. The design of the negotiation protocol is a criticalaspect 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 conflictresolutions), and finally (4) selecting an alternative[19]. Clever agents can take advantage of apoor protocol by implementing specific strategies which lead other agents to accept inferiorsolutions. Similarly, the manner in which conflicts are addressed and their resolutions are soughtcan influence the quality of the negotiation outcome.

A negotiation strategy refers to the plan by which an agent intends to interact with other agentswhile using a particular negotiation protocol. For example, agents may honestly reveal theirpreferences 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 toprior or future sales. To carry out such a strategy, agents can influence negotiations by suggestingalternatives or strategically revealing their preferences. If a negotiation protocol isnon-stable,agents can influence the outcome by providing inaccurate information[20]. For example, if twoagents 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



lie about their home location so as to reduce their amount of work. Stable protocols can bedesigned to prevent such strategic posturing[26].

During negotiations, understanding the interactions of agent models is critical. If one has anunderstanding of the domain, semantic conflicts can be differentiated from simple syntacticdifferences; for example, variablesx andy in two versions of the same program will not appearequal to adiff program (and therefore the program versions conflict); however, a slice analysis ofthe two programs may reveal that they are the same except for their names[3]. Conversely, twoagents may hold identical goals (e.g.,borrow(book,”x”)); however, these goals do in fact conflictbecause each agent wants the same resource. However, in many contexts, this is only agoalconflict—the apparent inconsistency of desired abstract states. Often, a goal conflict does notimply ameans 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 caseof borrowing books, one can alternate the time frame in which each agent has the book, i.e., theyborrow 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 choiceamong the given alternatives. However, if the semantics of the conflict are understood, then thealternatives can be decomposed and resolutions can be generated based on their recombination.For example, price compromises are possible during automobile negotiation because agentsunderstand the semantics of money. If the agents have a deeper understanding of the automobiledomain, alternatives based on the configuration of the automobile, loan, and maintenance featurescan be generated. (See “Automated Negotiation Analysis Techniques” on page 9.)

Automated Negotiation Analysis Techniques

Automated negotiation systems have a specialized techniques, including goal analysis and resolutiongeneration.

❑ Goal analysismethods overcome differences in terminology and classify goal interactions (e.g., conflict-ing, cooperative)[7][27]. Further analysis may be applied to the decision alternatives themselves in orderto distinguish between apparent goal conflicts and actual means conflicts. Goal conflicts occur when twoabstract contradictory goals are desired (e.g.,x andnot x). Some goal conflicts can be overcome by: (a)redefining the goals, or (b) defining the conditions surrounding their achievement (e.g., alternate be-tween achievingx, thennot x, thenx, etc.). On the other hand, means conflicts occur when two specificcontradictory goals are desired and there is no known method to achieve both.

❑ Resolution generationmethods create new decision alternatives. These methods include[19]:

❑ Distributive compromise, which distributes some portion of a resource to different agent withinthe confines of a given constraint space.

❑ Integrative “logrolling” , which generalizes distributive compromise to include a set of resourc-es. Then, one agent can be provided satisfaction on one subset of resources in trade for anotheragent’s satisfaction on a complementary set of resources.

❑ Reformulation, which generates alternatives by modifying agent goals in order to find the bestmutually satisfactory alternative. Reformulation may simply involve an agent “backing-off”and providing less contentious goals. However, reformulation can involve an analysis of thecontextual conditions causing conflict, followed by the introduction of goals which alleviate theconflict. For example, conflicts over non-consumable resources can often be resolved by alter-nating usage, or even creating more resources[22].

Negotiation Products 7


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

Negotiation Products

Negotiation can be characterized as the search for an alternative which satisfies a set of agentmodels[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 satisfactoryalternative begins. During search, cooperating and competing interactions among alternatives andagent models become apparent. Finally, if successful, a deal will be struck. The deal indicates theconditions under which the participants are committed to the alternative. Thus, agent models,alternatives, conflicts, deals, and their relationships are key negotiation products which should betracked 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, andgoals or alternatives can cause conflicts. It also shows some of the refined components of the fourbasic entities. For example, there are two basic types of conflict: goal and means; three basic typesof 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 thebasic 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 meta-models. The agent model indicates how goals stem from basic issues in the problemenvironment[21]. For example, an issue such as, “how can the company increase its value tostockholders?”, could lead to preferring the goal of increasing subcontracting. Goals can be linkedto alternatives by goal reduction (subgoaling), constraint introduction, and finally assigning theresponsibility of actions to particular agents[6].

Reconsider the labor negotiation example to see how negotiation entities are used throughoutthe life cycle. During the analysis phase, the two participants, company A and union B, developtheir agent models. The company model generally includes goals which lead to higher companyprofits, while the union model includes goals which lead to higher union status and membercompensation. Each participant generates a variety of alternatives which indicate how their goalscan 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, theparticipants may structure deals in which these alternatives are achieved.; for example,company Awill 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 beginto reveal their preferred goals, alternatives, and deals, they will discover interactions; for example,

Tools and Notations of the Negotiation Life Cycle 8


the goal conflict:reduce union wages≠ increase union wages. Eventually, if successful, they willgenerate a mutually agreeable deal.

Perhaps not surprisingly, we have found that the more complete a system’s negotiation meta-model is, the more automation the system can provide. For example, if a system explicitlyrepresents agents or agent classes, then a conflict over the cost of a resource for agents may beresolved by predicating the cost on agent subclasses. In fact, this is an instance of a generalreformulation rule which attempts to remove conflict by predicating the conditions under whichthey occur—the more complete a representation, the more opportunities the system has togenerate reformulations. (See “Automated Negotiation Analysis Techniques” on page 9.) Ofcourse, this is a double edged sword in that increased expressiveness also increases searchcomplexity. Nevertheless, a common goal of negotiation systems is to increase the number ofinteresting resolution alternatives for participants. This can be done through a morecomprehensive meta-model and ensuring that reformulation methods consider all aspects of themeta-model. (Such complete representations coupled with appropriate control heuristics isbecoming a common theme for resolution generation research[2][22].) In general, if negotiationsare anticipated, and in fact happen frequently, domain models or even participant specific modelscan be of significant help[15][28]. However, if negotiations are not anticipated or occurinfrequently, then a domain model may not be available, in which case only domain independentsupport 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

Deal

Alternative Conflict

GoalReduction

Preference

Evaluate

Issue

Generate

Agent Model

Figure 2. A meta-model of negotiation products.

BindingTime-frameStatusetc.

Owner

IDTimeLocationetc.

accept

part-of

fulfill

Goal ConflictMeans Conflict

cause

cause

0:n

0:n

2:n0:n

0:n

1:n

0:n

0:n0:n

1:n

0:n

0:n

1:1

0:n

composed-of

0:n

1:1

composed-of

0:n

1:1

Constraint

Action ObjectInput

Output

Ensures

Achieve Avoid Maintain

Satisfaction

Conflict

achieve mode1:1

1:1

Isa Isa

Isa Isa Isa

0:n

0:n 0:n

0:n0:n

0:n

Tools and Notations of the Negotiation Life Cycle 9


part of an overall negotiation life cycle. Elaborating on this theme, we illustrated howperspectives, processes, and products vary throughout the life cycle. Thus, each phase of thenegotiation life cycle has a different purpose with different requirements. While theserequirements overlap, we can roughly divide the requirements into three phases and suggest wherecurrent tools and notation are applicable.

Figure 3 again illustrates the negotiation life cycle, but shows where tools and notations aremost applicable. In the first phase of the life cycle, negotiation analysis seeks to acquire and modelindividual preferences. Decision theory, and specifically utility theory, supports this phase in thatit describes how to acquire and model individual preferences[20]. Requirements engineeringtheory adds to this initial stage by providing automated methods for goal-directed analysis ofmodels and deriving alternatives[6]. From the resulting agent models and analysis, negotiationprotocols and strategies can be defined.

In the second phase of the life cycle, negotiation design seeks to define interaction protocolsand strategies. Traditionally, game theory has been used for negotiation strategy design. Itprovides analytic techniques for modeling competitors and defining actions contingent oncompetitor actions. More recently, this technique has been adapted to defining software agentnegotiation protocols and strategies[18][26].

In the third phase of the life cycle, negotiation implementation seeks to reach groupcommitment through a series of communicative exchanges. Groupware provides the infrastructurefor human communication, while “agentware” such as the KIF protocols provide a framework foragent communication[9]. The content of negotiations must also be addressed; this includes,conflict analysis, resolution generation, argumentation, and arbitration. Currently, researchers areattempting 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 aconstrained space; however, generating a new alternative, perhaps outside the defined solutionboundary, often produces many uninteresting solutions or none at all. Moreover, other“downstream” processes still remain unexplored. For example, how does one maintain anegotiated agreement? For human agreements, this entails a plan of monitoring and recovery


Tools

•decision theory•utility theory•requirementstheory

Notation

•issues•goals•preferences•constraints•weightedutilities

Tools

•game theory•protocolanalysis

•speech-acttheory

Tools

•groupware•conflict analysis•resolutiongeneration

•arbitrationtheory

•argumentationtheory

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

Notation

•agent models•conflicts•alternatives•deals

Notation

•protocols•strategymodels

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 setof 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 amenableto problems where networked participants seek complex agreements in well defined domains. Insuch cases, negotiations systems can bring to bear communication protocols, constraint analysis,conflict classification, and knowledge-based resolution generation. We expect negotiation systemswill grow with the increase in networked communication and the reliance on software agents formanaging personal and corporate commitments.

Acknowledgment

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

References[1] AAAI, Workshop on Models of Conflict Management in Cooperative Problem Solving, AAAI, Seattle, Wa,

August 4, 1994.[2] Boehm, B., In, H., Identifying Quality-Requirement Conflicts, IEEE, Software, March, 1996, 25-36.[3] Binkley, D., Horwitz, S., and Reps, T.,Program Integration for Languages with Procedure Calls. ACM Trans-

actions on Software Engineering and Methodology 4, 1 (January 1995), pp. 3-35.[4] Constantine, L.L.,Work Organizations: Paradigms for Project Management and Organization, ACM, CACM,

October, 1993, 34-43.[5] Conry, S., Meyer, R., and Lesser, V., Multi-Stage Negotiation in Distributed Planning, Eds. A.H. Bond, L. Gas-

ser,Readings in Distributed Artificial Intelligence, Morgan Kaufmann, San Meteo, California (1988) 367-384.[6] Dardenne, A., van Lamsweerde, A., Fickas, S., Goal-Directed Requirements Acquisition,Science of Program-

ming, Elsevier, 20, 1993, 3-50.[7] Easterbrooke S., Co-Ordinating Distributed ViewPoints: the Anatomy of a Consistency Check, Concurrent

Engineering: Research & Applications, CERA Institute, (2), 1994.[8] 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 (March1995) 140-147.

[9] Genesereth, M.R., Ketchpel, S.P., Software Agents, ACM, Communications of the ACM, 37 (7), July 1994, 48-53.

[10] Hamalainen, R.P., O. Leikola, Spontaneous Decision Conferencing in Parliamentary Negotiations, IEEE, Pro-ceedings of the 28th Annual Hawaii International Conference on Systems Sciences, 1995, 290-299.

[11] I. Janis, L. Mann, Decision Making: a Psychological Analysis of Conflict, Choice, and Commitment, The FreePress, New York, 1979.

[12] 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.

[13] Kannapan, S.M., Marskek, K.M., An Approach to Parametric Machine Design and Negotiation in ConcurrentEngineering, inConcurrent Engineering: Automation, Tools, and Techniques, A. Kusiak (ed), John Wiley &Sons, 1993, 509-534.

[14] 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.

[15] Klein, M., Supporting Conflict Resolution in Cooperative Design Systems, IEEE,Transactions on Systems,Man, and Cybernetics, 21 (6), November 1991, 1379-1390.

[16] Lim, L., Benbasat, I., A Theoretical Perspective of Negotiation Support Systems, Journal of Management ofInformation Systems, Winter, 9 (3) 1992-1993, 27-44.

References 11


[17] Marca, D., Bock, G., (Eds.) Groupware: Software for Computer-Supported Cooperative Work, IEEE ComputerSociety Press, 1992.

[18] Matwin, S., Szpakowicz, S., Koperczak, Z., Kersten, G.E., Michalowski, W.,Negoplan: An Expert SystemShell for Negotiation Support, IEEE, Expert, 4(4) 50-62.

[19] Mazer, M., A Knowledge-Theoretic Account of Negotiated Commitement," CSRI-237, Univerity of Tor-onto (November 1989).

[20] Pruitt, D., Negotiation Behavior, Academic Press Inc.(1981).[21] Raiffa, H.,The Art and Science of Negotiation, Harvard University Press(1982).[22] Ramesh, B., Dhar, V., Supporting Systems Development by Capturing Deliberations During Requirements

Engineerng, IEEE, Transactions on Software Engineering, 1992, pp. 498-510.[23] Robinson, W.N., “Interactive Decision Support for Requirements Negotiation”,Concurrent Engineering:

Research & Applications, Special Issue on Conflict Management in Concurrent Engineering, The Institute ofConcurrent Engineering, 1994 (2) 237-252.

[24] Robinson, W.N., Negotiation Behavior During Requirement Specification,Proceedings of the 12th Interna-tional Conference on Software Engineering, IEEE Computer Society Press, Nice, France (March 26-30 1990)268-276

[25] Robinson, W.N., Fickas, S. Supporting Multi-Perspective Requirements Engineering,First International Con-ference on Requirements Engineering, IEEE, (April 18-22 1994) 206-215.

[26] Shakun, M.F., Airline Buyout: Evolutionary Systems Design and Problem Restructuring in Group Decision andNegotiation, The Institute of Management Sciences, Management Science, 37(10), (October 1991), 1291-1303.

[27] Rosenschein, J., Zlotkin, G., Rules of Encounter, The MIT Press, 1994.[28] 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)

[29] Sycara, K., Resolving Goal Conflicts via Negotiation,Proceedings of the AAAI-88, (1988) 245-250.[30] Teich, J.E., Wallenius, H., Kuula, M., Zoints, S.,A Decision Support Approach for Negotiation with an Appli-

cation to Agricultural Income Policy Negotiations, Elsevier Science, European Journal of OperationalResearch, 81 (1995) 76-87.

[31] Velthuijsen, H., Distributed Artificial intelligence for Runtime Feature-Interaction Resolution, IEEE,Com-puter, Vol. 26, No. 8, August 1993, 48-55.

[32] Yakemovic, K., Conklin, J., Experience with the gIBIS Model in a Corporate Setting,Proceedings of CSCW90, Los Angeles, 1990.

[33] Zeleny, M.,Multiple Criteria Decision Making, McGraw-Hill(1982).

Documents

Supporting the Negotiation Life Cycle - AMiner · Supporting the Negotiation Life-Cycle GSU Working ... We illustrate the use of the framework by showing how it can guide the selection