E-NEGOTIATION SYSTEMS DESIGN ISSUES

Morad Benyoucef and Antonio Silva

University of Ottawa, 136 Jean-Jacques Lussier St., Ottawa, Ontario K1N 6N5 Canada

Keywords: e-negotiation system, design framework, usability, development process.

Abstract: Most design frameworks for e-negotiation systems have focused on achieving higher efficiency and lower

transaction costs and, to a lesser extent, easy development and deployment. However, they have neglected

the most important element in a negotiation: the user. In fact, no framework has properly addressed usability

requirements. Usability must not only be the cornerstone of e-negotiation systems, but also serve as a driver

for their development. This paper presents the five phases essential to an e-negotiation system development

process and addresses how usability requirements and evaluation should be used to guide the process.

1 INTRODUCTION

The Internet has reshaped the way users and

organizations carry out their tasks. From a business

perspective, it has served as a platform through

which services are delivered to customers and it has

been used by companies to stay nimble within an

extremely competitive market. From a societal

perspective, it has been used to facilitate large scale

decision making and conflict resolution.

Negotiation is a process by which agents

(humans or software agents representing the

interests of their owners) conclude deals, resolve

conflicts, or make decisions. Negotiation

mechanisms (also called protocols) range from

auctions and bargaining to motion-raising and

voting. When a negotiation process relies on

electronic means (such as the Internet), it is referred

to as an electronic negotiation (e-negotiation). A

system implementing or supporting an e-negotiation

process is known as an e-negotiation system (ENS).

Three categories of ENSs have been identified in

the literature (Bichler et al., 2003): negotiation

support systems assist negotiators with

communication and decision making tasks;

negotiation software agents replace negotiators in

their communication and decision making tasks; and

e-negotiation media provide a platform that

implements a negotiation protocol.

An ENS is usually more complex than a

traditional catalogue-based e-commerce application

because in an ENS:

1. Interactions are more complex - An ENS has

to support a wide range of sophisticated

negotiation protocols.

2. Interactions need to be clearly described and

defined - Interactions must be captured and

described in a way that allows participants to

consult and understand the protocols to be

followed during the negotiation process.

3. Market conditions as well as societal

conditions change rather frequently and so do

the underlying negotiation protocols - The

ENS designer should be able to modify the

negotiation protocol easily and quickly and

without risk of introducing errors,

inefficiencies or inconsistencies.

4. Negotiation mechanisms need to be verified

before operational use - A negotiation protocol

must be formally described to allow automatic

checking for consistency, correctness and

completeness.

5. User demands change very often - An ENS

must therefore meet user demands suitably and

promptly.

ENS design requires not only a framework to

provide designers with concepts, methodologies,

tools, and techniques, but also a way of tying

together a set of components into a useful ensemble

in order to systematically develop a complete,

correct, and consistent application. A design

framework should support both simplicity (to ease

integration and promote reusability by simplifying

interfaces to other systems and subsystems) and

Benyoucef M. and Silva A. (2007).

E-NEGOTIATION SYSTEMS DESIGN ISSUES.

In Proceedings of the Second International Conference on e-Business, pages 84-89

DOI: 10.5220/0002114300840089

 SciTePress

thought through design with methodological support

regardless of system requirements.

There have been several initiatives, some of them

discussed in Section 2, aiming to support the ENS

development process, but most lack a systematic

approach which we believe is essential in view of

the increasing role that ENSs are set to play in the

context of e-business and e-government.

Furthermore, most existing ENS design frameworks

have focused on achieving higher efficiency and

lower transaction costs and, to a lesser extent, easy

development and deployment. However, they have

paid little attention to the most important element in

a negotiation process: the user.

This paper reports on our ongoing research to

devise an ENS development process. We identify

two phases within the process which address ENS

particularities: requirements gathering and

architectural design. We focus on usability as a way

of ensuring that ENSs meet user needs.

To support interoperability during architectural

design, we follow a service oriented approach where

a collection of services with well-defined interfaces

are designed and composed into useful negotiation

services to be deployed on the ENS.

Section 2 discusses ENS design challenges. We

present a five phase ENS development process in

Section 3. Section 4 discusses the need for adding

usability to an ENS development process.

Concluding remarks are provided in Section 5.

2 E-NEGOTIATION SYSTEMS

DESIGN CHALLENGES

Several efforts (Benyoucef et al., 2000; Neumann et

al., 2005; Kim et al., 2006; Strecker, 2006; Bartolini

et al., 2001; Bartolini et al., 2006; Strobel, 2003) to

provide a framework for designing ENSs have been

made. Most address specific phases of the ENS

development lifecycle. However, they lack an

engineering perspective which would provide a

more systematic way of developing such systems. A

discussion of three prominent frameworks is given

next.

2.1 Prominent Design Frameworks

CAME (Computer Aided Market Engineering)

(Neumann et al., 2005) is a framework aimed at

supporting a market engineering process with a

focus on designing electronic markets. The approach

makes use of MML (Market Modelling Language)

(Mäkiö, 2005) to allow a designer to configure the

rules of an auction by describing a set of parameters.

An executable auction based platform is then

generated automatically. Most of the work within

the CAME project has been restricted to auctions,

and the framework requires knowledge of MML and

market modelling, which may not be intuitive

enough for designers.

A context-independent framework for

developing ENSs was proposed in (Kim et al.,

2006). It makes use of the well known Model-View-

Controller (MVC) design pattern in order to promote

modularity, reusability and, as a result, reduce

system development effort. The general framework

is aimed at providing a generic platform which can

support multiple ENSs, and a platform called Invite

has been developed to explore the approach further

(Strecker, 2006). One reason for using the MVC

design pattern is the flexibility it can provide in user

interface design. However, this task may become

difficult when dealing with the design of complex

negotiation scenarios because MVC components are,

in general, tightly coupled and thus become hard to

deal with. Moreover, a not so user friendly table-

based specification has been used for configuring the

negotiation rules.

Generic Negotiation Platform (GNP) (Benyoucef

et al., 2000) was aimed at supporting several

negotiation protocols. Within GNP, the interplay of

negotiations is captured in iterative patterns, called

rounds, using Statecharts. GNP is a componentized

approach since its architecture clearly separates

application logic (i.e., business rules) from the

server component (i.e., the platform). This allows for

an easy deployment of new negotiation applications.

In addition to a lack of (or insufficient / non-

structured / non-documented) design process, a

thorough review of the literature shows that ENS

design has neglected an important element in a

negotiation process, which is the user. No approach

has addressed usability requirements. We believe

that usability must not only be the cornerstone of

such systems, but also serve as a driver within their

development process.

Next we discuss the need to provide a systematic

way of developing ENSs.

2.2 The Need for a Process

The interplay of activities in an ENS development

process calls for continuous communication between

stakeholders (designers, market makers, third party

service providers, regulators, etc.). In addition,

design activities depend on appropriate methods for

E-NEGOTIATION SYSTEMS DESIGN ISSUES

describing the artefacts produced during every

development phase.

An ENS development process should provide

guidelines, from a software engineering perspective,

to be followed so that the resulting application will

meet all requirements. The process must be used

from the conception of the ENS application through

requirements gathering and onto deployment. In

fact, Fuggetta defines a software process as “the

coherent set of policies, organizational structures,

technologies, procedures, and artefacts that are

needed to conceive, develop, deploy, and maintain a

software product” (Fuggetta, 2000).

An ENS is usually an online interactive

application through which participants interact with

each other using a variety of negotiation protocols.

Most of these interactions generally take place using

high speed public and private communication

networks. Also, an ENS shares the following

characteristics with other categories of web-based

applications:

1. Such systems are usually used by large

numbers of users. The eBay online auction

system (which is an ENS) is a good example.

2. Such systems may have some of their

components modified over time, thus

requiring dynamic updates with minor

downtimes for their users. It is not unusual

that the market maker decides to introduce a

new negotiation protocol or to modify an

existing one within an ENS.

3. Constant improvements in information and

communication technologies require fast

updates of such systems to keep up with the

pace of the advances.

4. The characteristics and functionalities of such

systems can evolve as new demands arise,

which requires rapid ways of inserting,

removing, updating, and maintaining system

functionalities.

Efforts at addressing the design process for web-

based applications are described in (Ginige and

Murugesan, 2001a; Ginige and Murugesan, 2001b;

Lowe, 2003). Parts of these efforts provide the

foundations for web engineering as discussed in

(Deshpande and Hansen, 2001) and more recently in

(Pressman, 2005), and address specific activities of a

process ranging from requirements elicitation and

analysis through architectural design to

implementation and testing.

While ENSs and other web-based applications

carry similarities as aforementioned, ENSs have

their particularities. For instance, some ENSs are

required to support multi-attribute negotiations,

multi-criteria decision making, and multiple

interdependent issues in contract negotiation, which

calls for an appropriate development process to

support such needs. Also, differently from most

web-based applications, ENSs borrow knowledge

from a broad rage of disciplines such as economics,

management science, information systems, game

theory, and computer science. To meet the

requirement of evolving negotiation protocols,

whether the ENS is under development, in an

evolving phase, or in-use, the ENS development

process must be evolutionary rather than static.

A key issue for an ENS development process is

usability. The process should be usability-driven in

the sense that user requirements must be taken into

account during the development process.

3 DEVELOPMENT PROCESS

FOR E-NEGOTIATION

SYSTEMS

Despite the initiatives discussed earlier and the

recent advances in ENS development approaches,

the development process for ENSs lacks a software

engineering perspective which would allow for such

systems to be conceived, built and deployed in a

predictable, reproducible and traceable fashion.

However, we do not intend to propose a new

process, but rather shed light on how to address the

specific development needs of an ENS.

The usability requirements determine the success

or failure of a system in that they comprise the user

acceptance level given in terms of user satisfaction

and performance. To address this issue, designers

need to find out what the users want and require

from a system. In other words, they should have the

premise that “any system designed for people to use

should be easy to learn (and remember), useful, that

it contains functions people really need in their

work, and be easy and pleasant to use” (Gould and

Lewis, 1985).

Previous approaches have focused too much on

system requirements and not enough on users. To

address this issue properly, usability should not only

be part of the overall system requirements, but also

serve as a driver for the ENS development process.

One way of doing so is to introduce a requirements

gathering phase into the ENS development process,

then put an emphasis on the system’s usability

throughout the various phases of the process.

ICE-B 2007 - International Conference on e-Business

In addition, we consider that a process needs to

be configurable so that it can be customized to meet

the requirements of a system under development.

From a software engineering perspective, an

ENS development process should include the

following phases:

Requirements Gathering - It is concerned with

understanding system and user needs. That is, this

phase aims at understanding the nature of the system

to be developed and the required functionality.

Within this context, the main objective is to capture

the system's organization. This organization is

viewed as a collection of components and users. In

addition, this phase aims at identifying the role that

each entity will play.

Interaction Scenario Development - The designer

must describe interaction scenarios involving the

users of the system in order to identify their goals

and tasks. All interaction details such as the kind of

information exchanged between participants are

abstracted out. The focus is on the interactions

between participants.

Architectural Design - A system is described in

terms of its architectural model.

System Building and Testing - This phase

comprises all implementation activities where

system components are implemented and integrated

to the main system (i.e., the ENS application).

Testing is carried out to verify if the desired

functionalities have been correctly delivered.

System Deployment - This phase comprises a set

of activities that aim at delivering the system to the

users.

For an ENS development process the two

important phases are requirements gathering and

architectural design. These phases call for the use of

appropriate modelling techniques to facilitate the

design and not to hinder the system’s capabilities. A

modelling approach for negotiation protocols within

the ENS development process should take into

account the need of negotiators to agree on the

negotiation protocol before they engage in the

negotiation process, which means that the resulting

model of the negotiation protocol must be

understandable by human negotiators and usable by

automated systems (i.e., negotiating software

agents). Furthermore, the model of the negotiation

protocol should be used to configure the ENS in a

“plug-and-play” fashion.

For instance, in our research we address the

configurability of an ENS by separating the

negotiation protocol from the main component

(called the engine) of an e-negotiation media (as

seen in Section 1, an e-negotiation media is one of

the three ENS categories) (Benyoucef, 2007).

Furthermore, using Statecharts as a modelling

language allows the ENS designer to capture most

negotiation protocol requirements and then have

them mapped into an executable process. In our

case, the Statechart describing the negotiation

protocol is mapped into a web service orchestration

described in the BPEL4WS language (BPEL4WS,

2006). A procedure to map Statechart models into

BPEL4WS specifications is given in (Benyoucef,

2006) and it aims at minimizing the effort of

designing and deploying an ENS. Using web service

orchestrations to implement negotiation processes is

a way of supporting interoperability which is

inherent to the service oriented approach.

The service oriented approach also allows for

both development and deployment of ENSs to be

carried out in a cost-effective way while fostering

application integration. The reasons are:

1. Web services improve Internet use by

enabling program to program

communication;

2. Application integration can benefit from the

widespread adoption of web services;

3. Interactions between negotiation participants

are complex and dynamic and, thus require

mechanisms to deploy services to customers

faster and at a lower cost;

4. By using web services, interoperability can

be achieved within and between e-negotiation

systems.

The development process discussed earlier is

supposed to provide support to and be influenced by:

- Context

(i.e., the resulting ENS design should

tackle different contexts specific to the business

environment, for instance different negotiation

protocols for different situations);

- Usability (i.e., users and organizations involved

in negotiations must have their demands and

requirements met).

Context and usability are used in the process as

triggers to make iterations, thus to enhance and/or

cause redesign with the aim of delivering the right

ENS to the users.

4 USABILITY IN

E-NEGOTIATION SYSTEMS

An ENS requires evaluation in order to check

whether organization and user requirements are

being met, which will determine the acceptance of

the ENS. Before committing to a usability

E-NEGOTIATION SYSTEMS DESIGN ISSUES

evaluation technique, designers need to identify the

measurement criteria to adopt. One example of such

criteria is the number of favorable user comments.

Another example is the time to complete a

transaction. This is an important criterion for a

system that handles a large number of transactions

such as the eBay ENS which has over 200 million

registered users worldwide.

Usability evaluation techniques can be

empirical, automated, formal, and informal.

Examples of such approaches comprise: heuristic

evaluation, surveys, observations, usability testing,

and data logging.

Heuristic evaluation (Nielsen, 1999), also known

as reviews, is a technique to find usability problems

by checking whether heuristics (i.e., largely accepted

usability principles) are being met or not within

system design. It is a cost-effective method, easy to

learn, and easily to apply.

Cognitive walkthrough (Wharton et al., 1994) is

a usability investigation method where one or more

evaluators make a usability inspection by going

through a set of tasks and evaluating the ease of

learning and understandability. This method

considers that users prefer to learn new system

functionalities by adopting a trial-and-error

approach.

Surveys form another usability evaluation

technique that can be performed using

questionnaires or interviews. It has usually been

used to assess user needs as well as to gather data for

a large variety of purposes. If questionnaires are

used to conduct the usability inspection, they can be

either delivered online or in person. Online

questionnaires have a low cost and can provide

results faster. However, results may not be as precise

as hoped, unless careful attention is paid to the

participants and conditions of the survey.

Observation is another usability evaluation

technique which involves watching and monitoring

the activities of users. It is somewhat subjective, and

interpretation of the findings is necessary. Moreover,

collecting data using this technique is time-

consuming. An example is Ethnography (a technique

originally developed by anthropologists where they

spend long periods of time in foreign societies

aiming to understand the social mechanisms).

Within a design context, the major objective is to

achieve a thorough understanding of work practices

in order to better support the system’s design. This is

an approach that has been receiving increasing

interest. By having its starting point anchored in the

Social Sciences and Humanities, it brings a

provoking and relevant perspective into the design

of software applications. The focus is on the detailed

analysis of current work practices, as viewed by the

people who actually do the work. According to

(Blomberg et al., 1993), the four main principles that

guide the ethnographic work are: (1) First hand

encounters: a commitment to study the activities of

people in their everyday settings; (2) Holism: a

belief that particular behaviors can only be

understood in the everyday context in which they

occur; (3) Descriptive rather than prescriptive:

describe how people actually behave, instead of how

they ought to behave; and (4) Members' point-of-

view: describe the behavior in terms relevant and

meaningful to the study participants.

Usability testing (Dumas and Redish, 1999) is

derived from experimental procedures and is more

appropriate to be applied during system

development. Usability testing usually takes place in

a usability laboratory where people can be gathered

to perform tests. During experiments, evaluators

monitor and record tasks being carried out by

individuals who take part in the test.

Data logging and metrics both involve

accumulation of numeric data (NIST, 2007). Data

logging provides a way to quantify online activity

while metrics can be used as measures to quantity

activity in online applications. Thus, online activities

can be described and quantified provided that a set

of metrics is developed.

The reader is referred to (Nielsen and Mack,

1994) for other usability inspection methods and a

broader discussion on the topic.

Choosing a suitable method for evaluating

system usability depends mainly of the universe of

system users. Although surveys and usability testing

are powerful techniques, they serve mainly to point

out major usability problems, and results may not be

precise unless careful attention is paid.

Our current investigation considers the use of a

heuristic evaluation approach which relies on a set

of evaluation sessions carried out by one or more

experts in order to identify usability problems of an

ENS under development. Such heuristics aim, for

instance, at checking if:

1. The dialogue is carried out in a simple and

natural fashion;

2. The system is minimalist in the sense that it

does consider the human memory constraints;

3. The system offers proper user feedback;

4. The system supports consistency and its state

is clearly identified by users.

We are in the process of evaluating the usability

of several ENSs, some of them from academia (e.g.,

INSPIRE) and some from the business world (e.g.,

ICE-B 2007 - International Conference on e-Business

eBay). We plan to report on the results of the

evaluation soon.

5 CONCLUSION

In this paper we reported on an ongoing effort to

identify what is missing from the design process of

e-negotiation systems. We identified requirements

gathering and architectural design as two phases

within the process that address the particularity of e-

negotiation systems. We emphasised on usability as

a way of meeting the needs of the users. To support

interoperability during architectural design, we

proposed a service oriented approach where a

collection of services are designed and composed

into negotiation services that are deployed on the e-

negotiation system. A thorough evaluation of the

usability of several e-negotiation systems from

business and academia is in progress. We will report

on its results when it is completed.

ACKNOWLEDGEMENTS

Funding for this work is provided by the Natural

Sciences and Engineering Research Council

(NSERC) of Canada.

REFERENCES

Bartolini, C. and Preist, C., A Framework for Automated

Negotiation, HP Labs Bristol, Tech Report HPL-2001-

90, 2001.

Bartolini, C., Preist, C., and Jennings, N. R., A Software

Framework for Automated Negotiation(Revised and

Updated), HP Labs Bristol, Tech Report HPL-2006-

33, 2006.

Benyoucef, M. and R. Keller and S. Lamouroux and J.

Robert and V. Trussart, Towards a generic e-

negotiation platform, Proc. of the Sixth Conf. on Re-

Technologies for Information Systems, pp. 95-109,

Zurich, Switzerland, 2000.

Benyoucef, M. and Rinderle, S., Modeling e-Negotiation

Processes for a Service Oriented Architecture, Group

Decision and Negotiation Journal 15:449-467, 2006.

Benyoucef, M. and Verrons, M. H., Configurable e-

Negotiation Systems for Large Scale and Transparent

Decision Making, Proceedings of the GDN’2007 (to

appear), 2007.

Bichler, M, Kersten, G, and Strecker, S., Towards a

Structured Design of Electronic Negotiations, Group

Decision and Negotiation Journal 12:311-335, 2003.

Blomberg J. et al: Ethnographic Field Methods and Their

Relation to Design, Participatory Design: Principles

and Practices (D. Schuler and A. Namioka – Editors),

Lawrence Erlbaum Associates, 1993, pp. 123-155.

BPEL4WS, Business Process Execution Language for

Web Services – Version 1.1, http://www-

128.ibm.com/developerworks/library/specification/ws-

bpel/, Accessed March 2006.

Deshpande, Y., and Hansen, S., Web engineering:

creating a discipline among disciplines. IEEE

Multimedia, (April - June), 82-87, 2001.

Dumas, J. S. and Redish, J. C., A Practical Guide to

Usability Testing. Intellect, 1999.

Fuggetta, A., Software Process – A Roadmap, Proceedings

of the ICSE, pp. 25-34, 2000.

Ginige, A., and Murugesan, S. (2001a). Web engineering:

An introduction. IEEE Multimedia, 8(1), 14-18.

Ginige, A. and Murugesan, S. (2001b). The essence of

Web engineering: Managing the diversity and

complexity of Web application development. IEEE

Multimedia, 8(2), 22-25.

Gould, J. and Lewis, C., Designing for Usability: Key

Principles and What Designers Think,

Communications of the ACM, Vol. 28, No. 3, pp. 300-

311, March 1985.

Kim, J., Kersten, G., Strecker, S. and Law, K. P.,

Developing Context-Independent E-Negotiation

Systems using Software Protocol and Model-View-

Controller Design Pattern, Proceedings of the

Montreal Conference on e-Technologies (MCeTech),

2006.

Lowe, D., Web system requirements: An overview.

Requirements Engineering, 8, 102-113, 2003.

Mäkiö, J., Designing and Modeling B2B-Markets,

Frontiers of E-Business Research, pp. 292-303, 2005.

Neumann, D., Mäkiö, J. And Weinhardt, C.,

CAME – A

Tool Set for Configuring Electronic Markets,

Proceedings of the ECIS, 2005.

Nielsen, J., Designing Web usability: The practice of

simplicity, New Riders Publishing, 1999.

Nielsen, J. and Mack R., Usability Inspection Methods,

John Wiley and Sons, 1994.

NIST. Web Metrics: Technical Overview, NIST (National

Institute of Standards and Technology),

http://zing.ncsl.nist.gov/WebTools/tech.html, accessed

in March 2007.

Pressman, R.S., Applying Web Engineering, Part 3.

Software Engineering: A Practitioner’s Perspective

(6th ed.). New York: McGraw-Hill, 2005.

Strecker, S., Kersten, G., Kim, J. and Law, K. P.,

Electronic Negotiation Systems: The Invite Prototype,

Proceedings of the Collaborative Business MKWI’06,

Passau, Germany, 2006.

Strobel, M and Weinhardt, C., The Montreal Taxonomy

for Electronic Negotiations, Group Decision and

Negotiation 12: 143-164, 2003.

Wharton, C. et al, The Cognitive Walkthrough Method: A

Practitioner’s Guide, in J. Nielsen and R. Mack

“Usability Inspection Methods”, Wiley & Sons, pp.

105-150, 1994.

E-NEGOTIATION SYSTEMS DESIGN ISSUES