A Systematic Mapping of Software Requirements Negotiation Techniques

Lucas Tito, Alexandre Estebanez, Andr

ea Magalh

aes Magdaleno,

Daniel de Oliveira and Marcos Kalinowski

Computing Institute, Fluminense Federal University (UFF), Av. Gal. Milton Tavares de Souza, Niteroi , Brazil

Keywords:

Software Requirements Negotiation Techniques, Requirements Engineering.

Abstract:

[Context] Eliciting requirements is a commonly discussed task. However, after they are ready, it is essentially

important for a software project that these requirements are sufﬁcient for stakeholders to reach their goals.

Therefore, techniques to negotiate schedule, price, quality, and scope among stakeholders are important.

[Goal] This paper aims at identifying and presenting characteristics of techniques that have been proposed

and/or used to negotiate software requirements. [Method] A mapping study was planned and conducted to

identify techniques and to capture their characteristics. Those characteristics include description, environment

(e.g. academic, industrial), the types of research being published, and the types of primary studies. The main

ﬁndings of the papers, and the advantages and disadvantages reported for theses techniques were also summa-

rized. [Results] We mapped the characteristics of 10 different requirements negotiation techniques identiﬁed

in 33 papers which met our inclusion criteria. We found that most of the identiﬁed techniques can be seen as

variations of the seminal WinWin requirements negotiation technique proposed in 1994. [Conclusions] The

conducted mapping study provides an interesting overview of the area and may also be useful to ground future

research on this topic.

1 INTRODUCTION

Requirement engineering involves a wide variety

of stakeholders (e.g., users, customers, developers,

project managers) and difﬁculties associated with the

communication between them (M

endez Fern

andez

et al., 2016). Accordingly to (Schopenhauer, 1831),

men are moved by the idea of selﬁshness. Consider-

ing this fact and the different goals of the stakehold-

ers, it is easy to understand why conﬂicts are com-

mon. Another important aspect is that when bonds are

made and relationships of trust are established, people

(in our context software project stakeholders) will try

harder to ﬁnd consensus during negotiations on their

different dimensions of interest (Le Bon, 1895).

The different dimensions of interest present in

software requirements negotiations are Level of Ser-

vice, Capabilities, Schedule, Cost, and Productivity

(Gr

unbacher and Briggs, 2001). Depending on the

situation, each dimension can be variable , but the

change in one of them will always affect the others.

Hence, it is difﬁcult to ﬁnd the ideal trade-off

between the dimensions and software requirements

negotiation is fundamental to the project’s success

(Boehm et al., 1995). There are many different tech-

niques to conduct software requirements negotiation,

but currently there is no clear overview of the avail-

able ones. Therefore, we conducted a mapping study

on those techniques to provide such overview.

To allow for a precise understanding what we

mean with a software negotiation technique in the

context of this paper, we created the following deﬁ-

nition: a series of steps, method and rules that are ap-

plied by two or more people trying to reach a consen-

sus and establish agreements that minimize the differ-

ences in their points of view regarding the software

requirements. It is noteworthy, we only understand

techniques as requirements negotiation techniques if

they are designed to be conducted by two or more

people. This excludes other techniques, such as solo

requirements prioritization techniques.

The goal of this paper is to identify and to provide

an overview of requirements negotiation techniques,

published in academic literature, and their character-

istics. The main ﬁndings of the papers and the ad-

vantages and disadvantages reported for theses tech-

niques are also presented and discussed.

The remainder of this paper is organized as fol-

lows. In Section 2, we describe our research ques-

tions, systematic mapping planning, execution and

518

Tito, L., Estebanez, A., Magalhães, A., Oliveira, D. and Kalinowski, M.

A Systematic Mapping of Software Requirements Negotiation Techniques.

DOI: 10.5220/0006362605180525

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 2, pages 518-525

ISBN: 978-989-758-248-6

the identiﬁed papers. In Section 3, we discuss the re-

sults and proceed to answer our research questions.

Finally, Section 4 presents the concluding remarks.

2 SYSTEMATIC MAPPING

This section, presents the planning, execution and the

identiﬁed papers of the systematic mapping study. In

order to conduct the mapping on software require-

ments negotiation techniques in a wide and unbiased

way, we used the deﬁnition presented in the introduc-

tion and built our protocol according to the guidelines

deﬁned by (Kitchenham and Charters, 2007).

2.1 Planning

Our systematic mapping study addresses one main re-

search question named RQ1: ”Which techniques have

been proposed and(or) used to negotiate software re-

quirements?”.

Software requirement negotiation techniques may

be deﬁned, applied or evaluated in many different

contexts. To better understand the context where

these different techniques are mentioned, we pro-

pose to also analyze the following secondary research

questions: (i) SQ1. ”Where the requirement negoti-

ation techniques were deﬁned, applied or evaluated,

in industry or in academy?”; (ii) SQ2. ”What are

the types of research about requirement negotiation

techniques that have been published? (e.g., Evalu-

ation research, Solution proposal, Philosophical pa-

per, Opinion paper, Experience paper)?”; (iii) SQ3.

”What are the types of primary studies that have been

used to evaluate requirement negotiation techniques?

(e.g., experiment, case study, survey)?”; (iv) SQ4.

”What are the advantages and disadvantages of each

technique according to the literature?”; and (v) SQ5.

”What is the knowledge (main ﬁndings) found in the

literature about each technique?”.

The types of research mentioned in SQ2 were ob-

tained from (Wieringa et al., 2005) and can be de-

scribed as follows: (i) Evaluation research: imple-

mented in practice, the evaluation of the implemen-

tation; demands more than one demonstration case

study.; (ii) Solution proposal: Solution for a prob-

lem is proposed, beneﬁts/application is demonstrated

by example, experiments, or student labs; (iii) Philo-

sophical paper: New way of thinking, structuring

a ﬁeld in form of a taxonomy or a framework, sec-

ondary studies like SLR or SMS; (iv) Opinion paper:

Personal opinion, not grounded in related work and

research methodology; and (v) Experience paper:

Personal experience, how things are done in practice.

Our search strategy to identify relevant papers

describing requirements negotiation techniques in-

cluded conducting a search string-based query and

complementing the results by applying backward

snowballing (searching for new papers in the refer-

ences). The elaboration of the search string followed

the PICO strategy, as suggested by (Kitchenham and

Charters, 2007).

The Population is deﬁned as software projects

(keyword software); the Intervention is what we are

observing within the population - requirements nego-

tiation techniques (keywords scope, requirements and

negotiation). As common for mapping studies, there

is no Comparison and no deﬁnition for the Outcome

of the primary studies. The resulting search string

follows: ((”software”) AND (”scope” OR ”require-

ments”) AND (”negotiation”)).

For ﬁltering the papers we deﬁned the follow-

ing inclusion and exclusion criteria (Table 1). Those

criteria should be applied by two independent re-

searchers. In case of differences in their classiﬁcation

a third researcher should be involved to also evaluate

to reach ﬁnal consensus.

To check the efﬁciency of our string-based query,

we manually identiﬁed 3 relevant papers that attend

the inclusion and exclusion criteria and are used as

control papers: (i) Software requirements negotia-

tion using the software quality function deployment

(Ramires et al., 2005); (ii) Integration of scrum with

Win-Win requirements negotiation model (Khan et al.,

2014); (iii) Requirements Negotiation Using Multi-

Criteria Preference Analysis (In and Olson, 2004).

Table 1: Inclusion and exclusion criteria.

Criterion Description

Inclusion

(IC1)

Papers that focus on requirements

negotiation techniques and de-

scribe, propose, apply or evaluate

one of such techniques.

Exclusion

(EC1)

Papers in which the technique is

only mentioned or that do not de-

scribe the technique steps in a un-

derstandable way.

Exclusion

(EC2)

Papers that are not indexed in digi-

tal libraries and available online.

Exclusion

(EC3)

Papers in any language other than

english.

Exclusion

(EC4)

Papers that describe requirement

negotiation techniques made for

non face to face contexts.

The papers found in the query result should be an-

alyzed by title and abstract, taking into account the

proposed inclusion and exclusion criteria. This anal-

ysis should naturally result into two groups: the ap-

A Systematic Mapping of Software Requirements Negotiation Techniques

519

proved papers and the rejected ones. The ﬁrst group

is the starting point for the next ﬁltering phase. In this

step, the researchers read and evaluate each paper us-

ing the aforementioned criteria to decide whether the

paper is aligned with the research goal or not. The re-

sulting papers from this step are considered in a back-

ward snowballing process, which signiﬁcantly con-

tributes to ﬁnding relevant research in the literature

(Badampudi et al., 2015). With the articles that had

been found by applying the snowballing, we repeated

the same ﬁltering processes that was done previously.

The snowballing and ﬁltering are iterative, i.e. they

stop when there are no more results to be added.

We extract the following data from the included

papers: (i) Reference; (ii) Technique name; (iii) Tech-

nique description summary; (iv) Environment (aca-

demic or industrial); (vi) Type of research (Evalua-

tion research, Solution proposal, Philosophical paper,

Opinion paper, Experience paper); (vii) Type of pri-

mary study (Experiment, Case study or Survey), if ap-

plicable; (viii) Main ﬁndings of the paper (knowledge

found); (ix) Advantages; and (x) Disadvantages.

2.2 Execution

For conducting our search strategy we selected Sco-

pus, which claims to be the largest database of

abstracts and citations (Kitchenham and Charters,

2007). Applying the ﬁltering to the papers retrieved

by Scopus should allow us to obtain a large and un-

biased set of papers that could be used as a rep-

resentative seed set to start backward snowballing

(Badampudi et al., 2015). We used the search string

to conduct the query in Scopus, limiting the results to

the areas of computer science and engineering.

The search in the library was performed in

November 24th 2015 and retrieved a set of 408 pa-

pers. These papers were read and ﬁltered by the ﬁrst

two authors following the aforementioned protocol,

consulting the last author in case of classiﬁcation dif-

ferences. The set obtained after the ﬁrst round of ﬁl-

tering (by title and abstract) contained 39 papers, and

the one obtained after the second round of ﬁltering

contains 18 papers.

Control papers (1) and (3) were successfully re-

trieved. We observed that the control paper (2) was

not retrieved due to the area restriction (computer sci-

ence and engineering), which intended to avoid pa-

pers from areas like economics . The reason was that

the paper (2) was classiﬁed as multiarea. This rein-

forced our conﬁdence of having a good search string

for retrieving this kind of paper. Despite this indexing

issue, control paper (2) was considered and its data

was extracted and included in the set of 18 papers.

During the ﬁrst iteration of the backward snow-

balling process using these 18 papers as seed set, a

total of 383 papers were found. After the ﬁltering by

title, the set was reduced to 56 non-duplicated papers.

The abstract ﬁltering reduced this amount to 26. After

analyzing the content of each paper we had 15 addi-

tional papers that passed our criteria. During the sec-

ond iteration, within the 332 references of these 15

additional papers, 7 non-duplicated papers that had

not been analyzed before remained after the ﬁlter by

title. Out of these 7, 3 were excluded by reading the

abstract and the other 4 had promising titles but had

to be excluded using criterion EC2. Thus, our ﬁnal

set remained with 33 papers that met our criteria and

that had their data extracted.

The identiﬁed papers, their publication years and

the references among them are shown in the citation

graph available at https://goo.gl/ZjG2bv. It depicts the

18 identiﬁed papers retrieved from Scopus as the seed

set in green. The 15 papers included after the back-

ward snowballing are shown in blue. Based on the

content of these papers we answer our research ques-

tions in Section 3.

3 RESULTS AND DISCUSSION

The extracted data and the knowledge acquired after

reading the papers subsidize the answers to our re-

search questions.

3.1 Requirement Negotiation

Techniques (RQ1)

A total of 10 requirement negotiation techniques have

been identiﬁed in the 33 included papers. The tech-

niques are shown in Table 2 together with its refer-

ence. The techniques are described hereafter ordered

by their chronological proposal.

(I) WinWin: It is based on the theory W (Boehm

et al., 1994). Four fundamental concepts are ap-

plied, which are: Win Conditions, Issues, Options

and Agreements. Win Conditions capture the stake-

holder goals and concerns about the new system. An

Agreement is created when a Win Condition does not

conﬂict with others. On the other hand, when there

are conﬂicts, Issues are recorded and the stakeholders

could suggest alternative solutions about these Issues,

which are represented by Options and could be used

by an Agreement to resolve Issues. The WinWin steps

are: (i) Stakeholders identiﬁcation; (ii) Stakeholders’

Win Conditions detection; and (iii) Reconciliation ne-

gotiation of Win Conditions. Once this technique is

applied by using the spiral model, a new requirement

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

520

can be introduced and it usually unbalances the Win-

Win status, thus the technique needs to undergo a

modiﬁcation to include some steps such as: validating

and verifying what has been negotiated, analyzing the

generated conﬂicts and the risks for the next iteration.

(II) Easy WinWin: It has the same steps as Win-

Win technique. Its main differential is stakehold-

ers collaboration during the negotiation process. The

stakeholders prioritization about the business impor-

tance and the ease of realization are needed.There are

4 prioritization categories: (i) Low hanging fruits:

Win Conditions that are perceived as important and

where the expected difﬁculties for realization are

moderate; (ii) Important with hurdles: Important Win

Conditions that are difﬁcult to implement; (iii) Maybe

later: Unimportant Win Conditions that are attractive

because of their burden-free implementation are la-

beled; and (iv) Forget them: Unimportant Win Con-

ditions that are difﬁcult to achieve are tagged. When it

comes to negotiation environment, stakeholders often

forget a Win Condition.

(III) CBSP (Component-Bus-System-

Property): it is a lightweight approach intended to

provide a systematic way of reconciling requirements

and architectures. It aims at transforming require-

ments descriptions into architectural descriptions to

further understand and reduce technical conﬂicts.

These conﬂicts arise from the interpretation of

requirements among software architects. CBSP’s

steps are the following: (i) Selection of next level

requirements; (ii) Architectural classiﬁcation of

requirements; (iii) Identiﬁcation and resolution

of classiﬁcation mismatches; (iv) Architectural

reﬁnement of requirements; and (v) Derivation of

architectural style and architecture.

(IV) MPARN (Multi-Criteria Preference Anal-

ysis Requirements Negotiation): it is also based on

the WinWin model. However, it is more objective and

systematic than WinWin. MPARN applies the sys-

tematic analysis of the preferences by using weights

and points. For the purpose of deﬁning the crite-

ria it is necessary to implement the following steps:

(i) Eliciting Win Conditions; (ii) Identifying issues

and conﬂicts; (iii) Exploring conﬂict-resolution op-

tions; (iv) Exploring objective criteria; (v) Assessing

options based on the criteria; (vi) Assessing relative

weights for criteria by each stakeholder; (vii) Rank-

ing options; and (viii) Post-analysis for agreements.

(V) Quantitative WinWin: It is very similar to the

WinWin technique, however the former uses Analytic

Hierarchy Process (AHP) to classify the requirements

and the stakeholders and measuring their importance.

In the end, a sequence of iterations of analysis is per-

formed to determine the optimal result.

(VI) QA EasyWinWin: It is a gathering of Easy

WinWin with quality assurance practices, so it has all

of Easy WinWin’s steps and still involves applying

some quality assurance techniques before, during and

after the negotiation.

(VII) Collaborative QFD (Quality Function De-

ployment): It involves a matrix of correlation values

between requirements and speciﬁcations. This matrix

is used in the following way: (i) users’ requirements

are elicited to relevant stakeholders and placed in the

left-hand side (rows); (ii) with the help of the stake-

holders, the requirements are converted to technical

speciﬁcations and placed at the upper side (columns);

(iii) the stakeholders are then invited to complete the

matrix with their perceived correlations; (iv) a list

of requirements priorities is deﬁned; and (v) a list

of technical speciﬁcations priorities is deﬁned. This

one can be considered a requirement negotiation tech-

nique when stakeholders participate in meetings col-

laboratively to deﬁne values for the matrix.

(VIII) Win CBAM: It’s goal is to reconcile with

focus on cost-beneﬁt of the options. It establishes the

following steps: (i) Eliciting win conditions; Identi-

fying conﬂict Issues; (ii) Exploring options / architec-

ture strategies; (iii) Assessing quality assurance ben-

eﬁts; (iv) Quantifying the architecture strategies ben-

eﬁts; (v) Quantifying the architecture strategies cost

/ schedule implications; (vi) Calculating desirability;

and (vii) Reaching agreements.

(IX) Requirement Negotiation Spiral Model: It

is similar to WinWin, but some steps have different

semantics and there are some assumptions for them

to be applied. The steps are: (i) Identify Conﬂicts; (ii)

Develop Alternatives Solutions; (iii) Elaborate Solu-

tions; (iv) Judgment and Trade-off; (v) Evaluate and

Analyze Agreement. In order to use the technique, 3

external elements are needed: scenario, criterion, and

resolution strategy. The scenario consists of a stake-

holders mapping, the criterion would be the way how

the requirements are prioritized and the strategy is one

archetype of conﬂict resolution.

(X) WinWin with Scrum: It is based on WinWin

Technique and therefore has the same steps. However,

it deﬁnes roles, the order of meetings, and the use of

artifacts in the same way as Scrum. The main differ-

ence is that there must be a negotiation meeting for

each Sprint, whereas in WinWin, the meetings do not

have a deﬁned schedule and well deﬁned roles. The

Product Backlog and Sprint Backlog are adapted to

contain requirements. The PMO deﬁnes the require-

ments together with the clients, the Master Negotiator

ensures the proper functioning of the meetings and

Negotiation Team raise points for discussion.

A Systematic Mapping of Software Requirements Negotiation Techniques

521

Table 2: Identiﬁed techniques and references.

Technique Reference

WinWin (Boehm et al., 1994); (Boehm et al.,

1995); (Lee, 1996); (Boehm et al.,

1997); (Boehm and Egyed, 1998);

(Boehm and Egyed, ); (Boehm

et al., 1998a); (Boehm et al.,

1998b); (Egyed and Boehm, 1999);

(Boehm et al., 2001); (In et al.,

2001); (Ruhe, 2002); (Raja et al.,

2007); (Boehm and Kitapci, 2006);

(Gr

unbacher et al., 2007); (Khan

et al., 2014)

Easy WinWin (Egyed and Boehm, 1997);

(Gr

unbacher, 2000); (Gr

unbacher

and Boehm, 2001); (Gr

unbacher

and Briggs, 2001); (Stallinger and

unbacher, 2001); (Briggs and

unbacher, ); (Gr

unbacher and

Braunsberger, 2003); (Gr

unbacher

and Seyff, 2005);

CBSP (Gr

unbacher et al., 2001);

MPARN (In et al., 2002); (In and Olson,

2004)

Quantitative

WinWin

(Ruhe et al., 2002); (Ruhe et al.,

2003);

QA EasyWin-

Win

(Gr

unbacher et al., 2004b);

Collaborative

QFD

(Ramires et al., 2005);

Win CBAM (Kazman et al., 2005)

Requirement

Negotiation

Spiral Model

(Ahmad, 2008);

WinWin with

Scrum

(Khan et al., 2014);

3.2 Environments, Types of Research

and Types of Primary Studies

Concerning SQ1 (environment), most techniques

have been applied only in academic environments

(Figure 1) in order to improve the techniques and/or

software engineering education. Thus, apparently lit-

tle is known about the adherence and acceptance of

these techniques by industry.

Regarding SQ2 (research type), it is possible to

observe (Figure 2) that solution proposals and evalu-

ation research are predominant, closely followed by

experience papers.

Out of the papers containing primary studies

(SQ3), most were case studies conducted in the aca-

demic context (e.g., tasks to be completed using

the negotiation techniques), although some were also

Figure 1: Environment of the identiﬁed research.

Figure 2: Types of research.

controlled experiments conducted by professors with

the participation of groups of students (Figure 3).

Figure 3: Types of primary studies.

3.3 Advantages, Disadvantages and

Main Findings

The purpose of this subsection is to answer SQ4 and

SQ5, providing information on advantages, disadvan-

tages, and ﬁndings regarding the techniques.

3.3.1 Advantages

The WinWin, when applied by using the Spiral

Model, and the WinWin with Scrum are reported to

be able to handle changes and accept new require-

ments in any step of the negotiation. (Boehm et al.,

2001)(Khan et al., 2014). One cited advantage con-

cerning WinWin with Scrum and Easy WinWin is

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

522

a shorter time to reach the negotiation goals (Khan

et al., 2014)(Briggs and Gr

unbacher, ). The Easy

WinWin and the WinWin techniques are reported to

have a very effective approach for communication

and collaboration between two or more stakeholders.

(Gr

unbacher and Briggs, 2001)(Boehm and Egyed, ).

According to Gr

unbacher (2000), the Easy WinWin

technique also avoids stakeholders to be judged by

their opinions.

The Win CBAM, the CBSP and the QA Easy Win-

Win techniques include steps for assessing the agree-

ment between two or more stakeholders (Kazman

et al., 2005)(Gr

unbacher et al., 2001)(Gr

unbacher

et al., 2004b). These last two techniques also

are mentioned to promote the comprehension be-

tween distinct viewpoints (technique vs functional)

(Gr

unbacher et al., 2001)(Gr

unbacher et al., 2004b).

On the other hand, QA Easy WinWin and Win-

Win present domain ﬂexibility (Gr

unbacher et al.,

2004b)(Boehm et al., 1997). The Quantitative Win-

Win and MPARN techniques, differently from all oth-

ers, focus on adapting the WinWin technique to obtain

a decision-making in a more quantitative and objec-

tive way (Ruhe et al., 2002)(In and Olson, 2004).

3.3.2 Disadvantages

Most of the analyzed papers do not directly mention

disadvantages. Indeed, these papers, in some way,

seem to recommend the use of the presented tech-

niques. This may be due to publication bias. Conse-

quently, some of the following disadvantages are the

result of the interpretation by the authors.

In the WinWin technique, at the stage of nego-

tiation, a stakeholder might not feel fully satisﬁed

with the agreements, because they may have accepted

more than they would like to.

Since the WinWin technique is subjective, it might

be necessary to organize more negotiation meetings to

analyse a set of requirements when compared to using

Quantitative WinWin (Ruhe, 2002).

The Quantitative WinWin technique and MPARN,

on the other hand, are more objective and are highly

dependent on tools, whereas it is possible loosing fo-

cus during the requirements comparison assignments,

in cases where there are many requirements to be an-

alyzed. In this regard, the stakeholders need to be

guided to not forget to perform comparisons. The

MPARN helps to make local decisions, however, it

is not completely effective for global decisions (Ruhe

et al., 2002)(In and Olson, 2004). It is noteworthy that

we did not identify studies evaluating the Quantitative

WinWin and MPARN in practical industrial contexts.

Therefore, their adoption might still be associated to

unknown risks. In Collaborative QFD, the larger the

matrix and more stakeholders, the shorter the time for

decision making and the longer the total time of the

negotiation process (Ramires et al., 2005).

3.3.3 Main Findings

The main ﬁndings can be summarized as follows: (i)

Users and clients were more active in deﬁning win

conditions, while developers and analysts were more

active in resolving issues and trying to ﬁnd options

(In et al., 2001); (ii) There are several ways to apply

MPARN due to a lot of kinds of mathematical for-

mulas in its steps (In et al., 2002); (iii) Easy WinWin

helps in the software documentation and it is inter-

esting to associate it with a software inspection tech-

nique (Khan et al., 2014); (iv) Stakeholders tend to ac-

cept satisfying Win Conditions. Once they achieved

them, they do not engage to obtain an optimal solu-

tion for themselves (In et al., 2001); (v) It is impor-

tant to develop prototypes during the negotiation and

the software development process, so that users and

customers do not change their minds at the end of ne-

gotiations (Boehm et al., 1998a); (vi) A lot of Win

Conditions can be achieved, when brainstorming is

used (Gr

unbacher and Briggs, 2001); and (vii) Face

to face negotiation provide a sense of conﬁdence and

security to stakeholders (Egyed and Boehm, 1997).

In some papers, WinWin and Spiral WinWin are

considered as requirements negotiation models (more

abstract then techniques). They are described as an

outline that deﬁnes the general negotiation steps.

Indeed, most of the identiﬁed techniques can be

seen as variations of WinWin (e.g., WinWin with

Scrum, Quantitative WinWin and MPARN are basi-

cally WinWin with mathematical models, EasyWin-

Win is based on WinWin with a stronger focus on

collaboration, QA Easy WinWin extends EasyWin-

Win with quality assurance practices, Win CBAM is

basically WinWin applied to software components).

3.4 Limitations and Threats to Validity

As any study, ours also faces limitations and threats

to validity. The ﬁrst one is a lack of a clear tax-

onomy for requirements negotiation techniques. For

instance, we identiﬁed papers in which negotiation

was deﬁned as prioritization, involving just one stake-

holder. In these cases, we did not consider it as a ne-

gotiation technique. In other cases, authors used the

word framework for different meanings (e.g., system,

tool, model, technique). To minimize this threat, be-

fore building our mapping protocol, we agreed on a

precise deﬁnition of what a requirements negotiation

technique represents for us (cf. Section 1).

A Systematic Mapping of Software Requirements Negotiation Techniques

523

The ﬁltering process is effort intensive and in-

volves human judgement. In many cases the title and

abstract could lead us to exclude a paper due to not

allowing a precise understanding that the focus of the

paper is on requirements negotiation techniques. Al-

though this threat can not be directly handled, the ﬁl-

tering process was conducted independently by two

researchers and a third researcher was involved to

solve eventual differences.

Forward snowballing (Felizardo et al., 2016) was

not applied. This was mainly because the quantity of

papers citing the 33 identiﬁed papers would be too

large to be handled with reasonable effort. For in-

stance, according to Google Scholar, (Boehm et al.,

1998a) (Boehm et al., 1995) (Boehm et al., 1994)

(Gr

unbacher and Briggs, 2001) papers alone were

cited in almost 1000 papers. Thus, some more recent

papers might not have been identiﬁed, given that we

used only one digital library (even though it claims

being the largest).

Hence, as an additional quality assurance mecha-

nism we identiﬁed the three authors with most publi-

cations among the 33 identiﬁed papers (Barry Boehm,

Paul Gr

unbacher, and Alexander Egyed, involved in

22 of the 33 identiﬁed papers) and veriﬁed within the

titles of their online DBLP computer science bibliog-

raphy if there were additional papers to be included.

This additional veriﬁcation improved our conﬁdence

in the reliability of the results. During this process

we found only three additional papers: (Gr

unbacher

et al., 2004a), (Kitapci and Boehm, 2007), and (Vogl

et al., 2011). The ﬁrst one was not indexed in Sco-

pus. The other two did not include the word software

in the title, abstract or keywords. However, the word

software was needed to add precision to the search

string. All three would have been retrieved applying

forward snowballing, since they all cite some of the

33 identiﬁed papers. The effort of applying forward

snowballing to complement the results will be the fo-

cus of a future work.

4 CONCLUSIONS

This paper describes a systematic mapping about soft-

ware requirements negotiation techniques. Its contri-

butions are the protocol planning and the mapping re-

sults. We identiﬁed 33 papers that describe 10 differ-

ent requirements negotiation techniques. For each of

these techniques we extracted and summarized their

information. Additionally, we highlighted ﬁndings

mentioned in the identiﬁed papers, and reported ad-

vantages and disadvantages of the techniques.

We believe that these pieces of information are

useful to both, researchers and practitioners. Re-

searchers might obtain an overview of the research

conducted concerning requirement negotiation tech-

niques. The practitioners in turn might use the results

to help them to choose a technique. It is important to

emphasize that the negotiation of requirements is an

inherent activity to the software development process,

that happens with or without a technique, although

choosing a technique may improve this process.

Also, we identiﬁed a lack of evaluations con-

ducted in industry. Therefore, future work could in-

volve conducting empirical studies in industry. Also,

a survey with practitioners could allow us to verify

whether the industry is aware of the identiﬁed tech-

niques (or others) and if it already uses some of them.

REFERENCES

Ahmad, S. (2008). Negotiation in the requirements elicita-

tion and analysis process. In Proceedings of the 19th

ASWEC, pages 683–689.

Badampudi, D., Wohlin, C., and Petersen, K. (2015). Expe-

riences from using snowballing and database searches

in systematic literature studies. In Proc. of EASE,

pages 17:1–17:10.

Boehm, B., Bose, P., Horowitz, E., and Lee, M.-J. (1994).

Software requirements as negotiated win conditions.

In Proc. of ICRE, pages 74–83.

Boehm, B., Bose, P., Horowitz, E., and Lee, M. J. (1995).

Software requirements negotiation and renegotiation

aids: A theory-w based spiral approach. In Proc. of

ICSE, pages 243–243.

Boehm, B. and Egyed, A. Winwin requirements negotiation

processes: A multi-project analysis. In Proc. of ICSP.

Boehm, B. and Egyed, A. (1998). Software requirements

negotiation: Some lessons learned. In Proc. of ICSE,

pages 503–506.

Boehm, B., Egyed, A., Kwan, J., and Madachy, R. (1997).

Developing multimedia applications with the winwin

spiral model. In Proc. of FSE, pages 20–39.

Boehm, B., Egyed, A., Kwan, J., Port, D., Shah, A., and

Madachy, R. (1998a). Using the winwin spiral model:

A case study. Computer, 31(7):33–44.

Boehm, B., Egyed, A., Port, D., Shah, A., Kwan, J., and

Madachy, R. (1998b). A stakeholder win–win ap-

proach to software engineering education. Annals of

Software Engineering, 6(1):295–321.

Boehm, B., Gr

unbacher, P., and Briggs, R. O. (2001).

Developing groupware for requirements negotiation:

Lessons learned. IEEE Software, 18(3):46–55.

Boehm, B. and Kitapci, H. (2006). The winwin approach:

using a requirements negotiation tool for rationale

capture and use. In Rationale Management in Soft-

ware Engineering, pages 173–190. Springer Berlin

Heidelberg.

Briggs, R. O. and Gr

unbacher, P. Easywinwin: Managing

complexity in requirements negotiation with gss. In

Proc. of HICSS.

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

524

Egyed, A. and Boehm, B. (1997). Analysis of system re-

quirements negotiation behavior patterns. In Proc. of

INCOSE, pages 481–488.

Egyed, A. and Boehm, B. (1999). Comparing software sys-

tem requirements negotiation patterns. Systems Engi-

neering, 2(1):1–14.

Felizardo, K. R., Mendes, E., Kalinowski, M., Souza, E. F.,

and Vijaykumar, N. L. (2016). Using forward snow-

balling to update systematic reviews in software engi-

neering. In Proc. of ESEM, pages 53:1–53:6.

unbacher, P. (2000). Collaborative requirements negotia-

tion with easywinwin. In Proc. of DEXA, pages 954–

958.

unbacher, P. and Boehm, B. (2001). Easywinwin: A

groupware-supported methodology for requirements

negotiation. SIGSOFT Softw. Eng. Notes, 26(5):320–

321.

unbacher, P. and Braunsberger, P. (2003). Tool support

for distributed requirements negotiation. Cooperative

methods and tools for distributed software processes,

pages 56–66.

unbacher, P. and Briggs, R. O. (2001). Surfacing tacit

knowledge in requirements negotiation: experiences

using easywinwin. In Proc. of HICSS.

unbacher, P., Egyed, A., and Medvidovic, N. (2001).

Reconciling software requirements and architectures:

The cbsp approach. In Proc. of RE, pages 202–211.

unbacher, P., Egyed, A., and Medvidovic, N. (2004a).

Reconciling software requirements and architectures

with intermediate models. Software & Systems Mod-

eling, 3(3):235–253.

unbacher, P., Halling, M., Bifﬂ, S., BIFFL, S., and

Boehm, B. W. (2004b). Integrating collaborative pro-

cesses and quality assurance techniques: experiences

from requirements negotiation. Journal of Manage-

ment Inf. Sys., 20(4):9–29.

unbacher, P. and Seyff, N. (2005). Requirements negoti-

ation. In Engineering and managing software require-

ments, pages 143–162. Springer Berlin Heidelberg.

unbacher, P., Seyff, N., Briggs, R. O., In, H. P., Kitapci,

H., and Port, D. (2007). Making every student a win-

ner: The winwin approach in software engineering ed-

ucation. JSS, 80(8):1191 – 1200.

In, H., Boehm, B., Rodgers, T., and Deutsch, M. (2001).

Applying winwin to quality requirements: a case

study. In Proc. of ICSE, pages 555–564.

In, H. P. and Olson, D. (2004). Requirements negotia-

tion using multi-criteria preference analysis. J.UCS,

10(4):306–325.

In, H. P., Olson, D., and Rodgers, T. (2002). Multi-criteria

preference analysis for systematic requirements ne-

gotiation. In Proceedings of the Annual Interna-

tional Computer Software and Applications Confer-

ence (COMPSAC), pages 887–892.

Kazman, R., In, H. P., and Chen, H.-M. (2005). From

requirements negotiation to software architecture de-

cisions. Information and Software Technology,

47(8):511–520.

Khan, U. Z., Wahab, F., and Saeed, S. (2014). Integra-

tion of scrum with win-win requirements negotiation

model. Middle-East Journal of Scientiﬁc Research,

19(1):101–104.

Kitapci, H. and Boehm, B. W. (2007). Formalizing informal

stakeholder decisions–a hybrid method approach. In

Proc. of HICSS.

Kitchenham, B. and Charters, S. (2007). Guidelines for per-

forming systematic literature reviews in software en-

gineering. Technical report, Keele University.

Le Bon, G. (1895). Psychologie des foules. UltraLetters.

Lee, M.-j. (1996). Foundations of the winwin requirements

negotiation system. PhD thesis, University of South-

ern California.

endez Fern

andez, D., Wagner, S., Kalinowski, M., and

et al. (2016). Naming the pain in requirements en-

gineering: Contemporary problems, causes, and ef-

fects in practice. Empirical Software Engineering

(doi:10.1007/s10664-016-9451-7), pages 1–41.

Raja, B. S., Iqbal, M. A., and Ihsan, I. (2007). Moving

from problem space to solution space. Int. J. of Social,

Behavioral, Educational, Economic, Business and In-

dustrial Engineering, 1(11):764–767.

Ramires, J., Antunes, P., and Resp

ıcio, A. (2005). Software

requirements negotiation using the software quality

function deployment. In International Conference on

Collaboration and Technology (CRIWG), pages 308–

324.

Ruhe, G. (2002). Software engineering decision support–

a new paradigm for learning software organizations.

In Int. Workshop on Learning Software Organizations,

pages 104–113.

Ruhe, G., Eberlein, A., and Pfahl, D. (2002). Quantita-

tive winwin: A new method for decision support in

requirements negotiation. In Proc. of SEKE, SEKE

’02, pages 159–166, New York, NY, USA. ACM.

Ruhe, G., Eberlein, A., and Pfahl, D. (2003). Trade-off anal-

ysis for requirements selection. IJSEKE, 13(04):345–

366.

Schopenhauer, A. (1831). Die Kunst zu beleidigen. C.H.

Beck.

Stallinger, F. and Gr

unbacher, P. (2001). System dynam-

ics modelling and simulation of collaborative require-

ments engineering. JSS, 59(3):311 – 321.

Vogl, H., Lehner, K., Gr

unbacher, P., and Egyed, A. (2011).

Reconciling requirements and architectures with the

cbsp approach in an iphone app project. In Proc. of

RE, pages 273–278.

Wieringa, R., Maiden, N., Mead, N., and Rolland, C.

(2005). Requirements engineering paper classiﬁcation

and evaluation criteria: A proposal and a discussion.

Requirements Engineering, 11(1):102–107.

A Systematic Mapping of Software Requirements Negotiation Techniques

525