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
Software Requirements Negotiation Techniques, Requirements Engineering.
[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 sufficient 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
findings 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 identified
in 33 papers which met our inclusion criteria. We found that most of the identified 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.
Requirement engineering involves a wide variety
of stakeholders (e.g., users, customers, developers,
project managers) and difficulties associated with the
communication between them (M
endez Fern
et al., 2016). Accordingly to (Schopenhauer, 1831),
men are moved by the idea of selfishness. Consider-
ing this fact and the different goals of the stakehold-
ers, it is easy to understand why conflicts 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 find 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
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 difficult to find 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 defi-
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 findings 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
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
Copyright © 2017 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
the identified papers. In Section 3, we discuss the re-
sults and proceed to answer our research questions.
Finally, Section 4 presents the concluding remarks.
This section, presents the planning, execution and the
identified 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 definition presented in the introduc-
tion and built our protocol according to the guidelines
defined 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-
Software requirement negotiation techniques may
be defined, 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 defined, 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 findings) 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, benefits/application is demonstrated
by example, experiments, or student labs; (iii) Philo-
sophical paper: New way of thinking, structuring
a field 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 defined 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 definition for the Outcome
of the primary studies. The resulting search string
follows: ((”software”) AND (”scope OR require-
ments”) AND (”negotiation”)).
For filtering the papers we defined 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 classification
a third researcher should be involved to also evaluate
to reach final consensus.
To check the efficiency of our string-based query,
we manually identified 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
Papers that focus on requirements
negotiation techniques and de-
scribe, propose, apply or evaluate
one of such techniques.
Papers in which the technique is
only mentioned or that do not de-
scribe the technique steps in a un-
derstandable way.
Papers that are not indexed in digi-
tal libraries and available online.
Papers in any language other than
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
proved papers and the rejected ones. The first group
is the starting point for the next filtering 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 significantly con-
tributes to finding relevant research in the literature
(Badampudi et al., 2015). With the articles that had
been found by applying the snowballing, we repeated
the same filtering processes that was done previously.
The snowballing and filtering 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 findings 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 filtering 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 filtered by the first
two authors following the aforementioned protocol,
consulting the last author in case of classification dif-
ferences. The set obtained after the first round of fil-
tering (by title and abstract) contained 39 papers, and
the one obtained after the second round of filtering
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 classified as multiarea. This rein-
forced our confidence 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 first iteration of the backward snow-
balling process using these 18 papers as seed set, a
total of 383 papers were found. After the filtering by
title, the set was reduced to 56 non-duplicated papers.
The abstract filtering 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 filter 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 final
set remained with 33 papers that met our criteria and
that had their data extracted.
The identified 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 identified 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.
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 identified 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
conflict with others. On the other hand, when there
are conflicts, 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 identification; (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
can be introduced and it usually unbalances the Win-
Win status, thus the technique needs to undergo a
modification to include some steps such as: validating
and verifying what has been negotiated, analyzing the
generated conflicts 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 difficulties for realization are
moderate; (ii) Important with hurdles: Important Win
Conditions that are difficult 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 difficult 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 conflicts.
These conflicts arise from the interpretation of
requirements among software architects. CBSP’s
steps are the following: (i) Selection of next level
requirements; (ii) Architectural classification of
requirements; (iii) Identification and resolution
of classification mismatches; (iv) Architectural
refinement 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 defining the crite-
ria it is necessary to implement the following steps:
(i) Eliciting Win Conditions; (ii) Identifying issues
and conflicts; (iii) Exploring conflict-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 specifications. 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
specifications 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 defined; and (v) a list
of technical specifications priorities is defined. This
one can be considered a requirement negotiation tech-
nique when stakeholders participate in meetings col-
laboratively to define values for the matrix.
(VIII) Win CBAM: It’s goal is to reconcile with
focus on cost-benefit of the options. It establishes the
following steps: (i) Eliciting win conditions; Identi-
fying conflict Issues; (ii) Exploring options / architec-
ture strategies; (iii) Assessing quality assurance ben-
efits; (iv) Quantifying the architecture strategies ben-
efits; (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 Conflicts; (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 conflict resolution.
(X) WinWin with Scrum: It is based on WinWin
Technique and therefore has the same steps. However,
it defines 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 defined schedule and well defined roles. The
Product Backlog and Sprint Backlog are adapted to
contain requirements. The PMO defines 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
Table 2: Identified 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);
unbacher et al., 2007); (Khan
et al., 2014)
Easy WinWin (Egyed and Boehm, 1997);
unbacher, 2000); (Gr
and Boehm, 2001); (Gr
and Briggs, 2001); (Stallinger and
unbacher, 2001); (Briggs and
unbacher, ); (Gr
unbacher and
Braunsberger, 2003); (Gr
and Seyff, 2005);
unbacher et al., 2001);
MPARN (In et al., 2002); (In and Olson,
(Ruhe et al., 2002); (Ruhe et al.,
QA EasyWin-
unbacher et al., 2004b);
(Ramires et al., 2005);
Win CBAM (Kazman et al., 2005)
Spiral Model
(Ahmad, 2008);
WinWin with
(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 identified 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 findings 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
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.
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
et al., 2004b). These last two techniques also
are mentioned to promote the comprehension be-
tween distinct viewpoints (technique vs functional)
unbacher et al., 2001)(Gr
unbacher et al., 2004b).
On the other hand, QA Easy WinWin and Win-
Win present domain flexibility (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 satisfied
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 findings can be summarized as follows: (i)
Users and clients were more active in defining win
conditions, while developers and analysts were more
active in resolving issues and trying to find 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 confidence 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 defines the general negotiation steps.
Indeed, most of the identified 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 first one is a lack of a clear tax-
onomy for requirements negotiation techniques. For
instance, we identified papers in which negotiation
was defined 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 definition of what a requirements negotiation
technique represents for us (cf. Section 1).
A Systematic Mapping of Software Requirements Negotiation Techniques
The filtering 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 fil-
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 identified 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)
unbacher and Briggs, 2001) papers alone were
cited in almost 1000 papers. Thus, some more recent
papers might not have been identified, given that we
used only one digital library (even though it claims
being the largest).
Hence, as an additional quality assurance mecha-
nism we identified the three authors with most publi-
cations among the 33 identified papers (Barry Boehm,
Paul Gr
unbacher, and Alexander Egyed, involved in
22 of the 33 identified papers) and verified within the
titles of their online DBLP computer science bibliog-
raphy if there were additional papers to be included.
This additional verification improved our confidence
in the reliability of the results. During this process
we found only three additional papers: (Gr
et al., 2004a), (Kitapci and Boehm, 2007), and (Vogl
et al., 2011). The first 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 identified papers. The effort of applying forward
snowballing to complement the results will be the fo-
cus of a future work.
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 identified 33 papers that describe 10 differ-
ent requirements negotiation techniques. For each of
these techniques we extracted and summarized their
information. Additionally, we highlighted findings
mentioned in the identified 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 identified 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 identified tech-
niques (or others) and if it already uses some of them.
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
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
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–
unbacher, P. and Boehm, B. (2001). Easywinwin: A
groupware-supported methodology for requirements
negotiation. SIGSOFT Softw. Eng. Notes, 26(5):320–
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., Biffl, 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,
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,
Khan, U. Z., Wahab, F., and Saeed, S. (2014). Integra-
tion of scrum with win-win requirements negotiation
model. Middle-East Journal of Scientific Research,
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–
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–
Schopenhauer, A. (1831). Die Kunst zu beleidigen. C.H.
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 classification
and evaluation criteria: A proposal and a discussion.
Requirements Engineering, 11(1):102–107.
A Systematic Mapping of Software Requirements Negotiation Techniques