See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/280243996

Requirements Analysis as a Negotiation Process

Conference Paper · June 2015

CITATIONS READS

3 3,049

3 authors:

Annika Lenz Mareike Schoop

RTS Steuerberatungsgesellschaft KG University of Hohenheim
15 PUBLICATIONS   15 CITATIONS    111 PUBLICATIONS   1,312 CITATIONS   

SEE PROFILE SEE PROFILE

Georg Herzwurm
Universität Stuttgart
311 PUBLICATIONS   802 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Mobile Learning View project

Cloud Manufacturing: Defining the problem domain of trust View project

All content following this page was uploaded by Annika Lenz on 31 July 2015.

The user has requested enhancement of the downloaded file.

Requirements Analysis as a Negotiation Process 303

Requirements Analysis as a Negotiation Process

Annika Lenz1,2*, Mareike Schoop1, and Georg Herzwurm2

1
University of Hohenheim,
Chair of Information Systems I,
70593 Stuttgart, Germany
2
Universität Stuttgart,
Department for Business Administration and Information Systems II,
70147 Stuttgart, Germany
*
Corresponding author, ­e‑mail: [email protected]‑hohenheim.de

Abstract. Requirements engineering is an essential part of software development.

Here, the necessary requirements are elicited, clarified, agreed upon, validated, and
documented. To do so, the stakeholders engage in complex negotiation processes.
The paper discusses the specifics of such requirements negotiations and the potential
of negotiation systems to support them.

Keywords: requirements negotiations, requirements analysis, requirements engi‑

neering, negotiation support systems.

1  Introduction
In software development, requirements engineering is essential for a project to succeed
[1, 2]. In general, requirements engineering consists of requirements analysis and require‑
ments management. Whereas in the former, all requirements necessary for the software to
be developed are elicited, clarified, jointly agreed upon, validated, and documented among
all relevant stakeholders, the latter phase covers requirements traceability, prioritising re‑
quirements, managing requirements changes, and the maintenance of the user requirement
specification (cf. [1]). These requirements develop over time. Requirements of low quality or
unresolved conflicts such as mutually exclusive requirements often lead to longer duration of
the development, higher development costs, wrong functionality, or even project failure.
To prevent such scenarios, all stakeholder involved have to come to an agreement. The
pitfalls hereby lie in diverging individual preferences and objectives as well as in diverse
stakeholder groups [1, 3]. Such groups involve developers, customers, managers, and users
who all have different and often opposite preferences and objectives. Thus, there is a high
risk of conflicts, e.g. due to individual concerns of stakeholders such as the fear of losing
one’s employment or a need to demonstrate one’s power. In addition, there is the possibility

B. Kamiński, G.E. Kersten, P. Szufel, M. Jakubczyk, and T. Wachowicz (eds.), Proceedings of the 15th International
Conference on Group Decision & Negotiation, pp. 303–309, Warsaw School of Economics Press, Warsaw, 2015.
© Annika Lenz, Mareike Schoop, and Georg Herzwurm
304   A. Lenz, M. Schoop, and G. Herzwurm

of interest conflicts, data conflicts, value conflicts, relationship conflicts, and structural
conflicts [4].
Despite individual goals, each stakeholder group has the overall goal of reaching a suc‑
cessful software development project. The groups’ interdependent tasks become apparent.
Obviously, the customers need developers to code their desired software, and developers
need the customers’ requirements and knowledge to build adequate software. Requirements
engineering is a “(...) cooperative, iterative, and incremental process” [1]. Its main focus is to
establish a common terminology of customers and developers in order to enable an effective
and efficient communicative exchange.
To summarise, the processes of requirements engineering, especially requirements
elicitation and requirements analysis, is a negotiation process [5]. We adapt the definition
of Bichler [6] and define requirement negotiation as an iterative process of communication
and decision­‑making between customer and developer and maybe other parties who have
the overall goal of agreeing on a software development process and outcome. Neither of the
partners can reach this goal unilaterally as their tasks are interwoven in that the requirements
are the basis for the development process which will have to be based on realistic target
specifications. The negotiations involve multiple attributes and thus facilitate integrative
negotiation outcomes (cf. [7]). Consequently, we will use the term requirements negotiation
for the above described process.

2  Negotiation in the Requirements Engineering Process

Some authors integrate negotiating requirements in the context of requirements engineering
as a separate phase among requirements analysis and requirements management [8, 9]. Other
approaches situate requirements negotiation in the elicitation process during requirements
analysis [10, 11], which holds similarities to the pre‑negotiation phase [5].
More common approaches also integrate requirements negotiation in requirements analy‑
sis, but place it during the reconciliation phase. As the main activity of the reconciliation is
conflict management, which consists of the tasks of conflict identification, conflict analysis,
conflict resolution, and the documentation of the solution (cf. [1]), the underlying aspect of
reaching consensus encourages this view point.
Hence, we classify requirements negotiation as a cross­‑sectional activity. As stated above,
requirements negotiation is realised during both requirements elicitation and the succeeding
requirements analysis phase [5]. To improve readability, we will use the more generic term
requirements analysis for both activities.

2.1  Electronic Requirements Negotiations

Requirements negotiations are about a software that is to be developed. Thus, the specifics
of software itself and of the process of designing and developing it have a strong influence
on the medium that used in the negotiation process.
Requirements Analysis as a Negotiation Process 305

Firstly, the stakeholders are often dislocated. Software development is nowadays often
carried out in low‑wage countries with high programming expertise. Secondly, software
development is often done in a dislocated manner, i.e. the development teams are located in
various countries and continents. Finally, the software itself is a digital good which makes it
desirable to use digital media in the process leading to its specification. Therefore, many if
not most processes of requirements analysis for software development are carried out with
the help of digital media. We will consequently focus on electronic requirements negotiations
in our work which are defined as follows.
Electronic requirements negotiation is performed and supported by means of information
and communication technology in terms of communication support, decision support, ­and/­or
document management. Such support is only possible through the adoption of information
and communication technology which consequently offers additional value.

2.2  Approaches
Among the different approaches of negotiating requirements, investigated research does not
always involve or follow a defined process model. It is often assumed that the requirements
negotiation processes are obvious and therefore not mentioned [8]. Furthermore, negotiation
is done by commenting and voting for requirements [12].
Nevertheless, the majority of the applied process models are developed by researchers
in the requirements engineering discipline, which can be grouped by certain aspects. One
group addresses the automated support of negotiating requirements. This is achieved by
revealing the individuals’ preferences. The negotiation software detects conflicts among the
requirements, characterises the conflict, and generates resolution alternatives such as one of
the conflicting values, a compromise value, or reformulation of the conflicting values [13, 14].
For this purpose, autonomous software agents can be used to resolve conflicts according to
the revealed preferences. For the automation of managing requirements changes, more for‑
mal approaches formulate a logical representation of the requirement specification and the
to‑be‑specification of the requirements to consolidate them [15]. Therefore, one approach
has developed a compromise­‑based algorithm based on a logical language without human
involvement to reach consistent requirements [16]. Furthermore, a broker­‑based negotiation
framework has been discussed which automatically determines the non‑functional require‑
ments of a required business service. Active participation of stakeholders is not required.
However, they must provide specific input data such as an agreed functional goal model,
control flow information, and stakeholder utility functions [17].
Among the other researchers that argue for the human component to be indispensable,
there is a large group whose work is based on the so‑called Theory W and the related Win‑
Win negotiation model [18, 19]. Theory W is a software project management theory that is
based on the Harvard Principled Negotiation [20], aiming to reach an integrative solution.
It supports conflict management by previously defining each stakeholder’s win conditions,
attempting to fulfil them, and coming to a perceived fair and agreeable resolution for every
stakeholder.
306   A. Lenz, M. Schoop, and G. Herzwurm

The WinWin negotiation model has been combined among others with the ­SCRUM
methodology [21], complementing the WinWin negotiation model by quality assurance and
multi­‑criteria preference techniques [22], or extending the WinWin spiral model by multi
criteria preference analysis negotiations and a broker based negotiations framework [23].
Another group of researchers have introduced approaches whose basic concepts involve
negotiation theory but are different from the mentioned WinWin approach. For examining the
communication medium in distributed settings versus on‑site settings, a framework based on
social presence, computer­‑mediated communication theories, media richness theory, common
ground theory, media synchronicity, cognitive­‑based view, time­‑interaction­‑performance and
task/technology fit is developed, stating that in certain phases of the requirements negotia‑
tion process synchronous text­‑based chat is more effective than face‑to‑face [9]. Also based
on the media richness theory, some research investigates how the medium (face‑to‑face,
distributed three­‑dimensional virtual environment and text­‑based structured chat) influences
the time to negotiate, the quality of the negotiated software requirements, and the number of
problematic and solved issues within the requirements negotiation process [24]. As a result,
their study shows that the time needed to negotiate software requirements is influenced by
communication media (face‑to‑face being the quickest), whereas the number of issues was
larger using the distributed three­‑dimensional virtual environment.
Other research investigates distributed asynchronous electronic requirements negotiation
in particular [25]. The influence of a given task structure or a given negotiation structure with
explicit sequence of certain negotiation phases of the negotiation process model proposed by
Gulliver [26] and extended by Kersten [27] on requirements negotiation groups’ activeness,
satisfaction with their process, and conflict in a distributed environment is discussed. It was
shown that groups provided with a task structure are more active than those without, but the
latter are more satisfied with their process. The lowest level of conflict was found among the
groups that neither used task structure nor negotiation sequence. The study was performed
with a web‑based collaboration environment.

2.3  Discussion
Since stakeholders hardly know their complete requirements in advance, and therefore re‑
quirements must evolve over time, we have to deal with incomplete, changing, and missing
information at the beginning of the process. Interaction of all relevant stakeholders in terms of
exchanging information, ideas, thoughts, and arguments is necessary during the whole process
of requirements negotiations to come to an agreed, specified set of requirements [5].
The process of electronic requirements negotiation as part of requirements analysis is
a complex one (cf. sections 1 and 2.1). To assess what is required to support such electronic
negotiations, we will first look at automated approaches. They need complete knowledge of
individual preferences [17]. This means that the requirements must be completely elicited and
their utility known. This is unrealistic and even often infeasible since that input is not avail‑
able right from the beginning [5]. Requirements are elicited and agreed upon in interactive
communication processes between the involved stakeholders. Thus, automated approaches
are not sufficient for the complex communicative and social process of negotiation.
Requirements Analysis as a Negotiation Process 307

The approaches based on the Harvard model are very conceptual. This can be chal‑
lenging, since conceptual approaches easily get too structured to support such complex
real­‑world processes with diverse influencing factors. The mentioned approaches besides
the WinWin‑group seem very promising. Unfortunately, most of these approaches are not
continued and thus no recent work can be reported.
Often, collaboration environments are used for electronic requirements negotiation [25],
which indeed support group processes, but obviously lack adequate negotiation support. Col‑
laboration software focuses on supporting group tasks and is not designed to support a complete
negotiation process, including pre‑negotiation, negotiation, and settlement. Requirements
engineering software is not sufficiently adapted for meeting this task either [2, 7].
In contrast, we have sophisticated negotiation support systems already available, which
are designed to ideally handle the complex task of electronic negotiation processes, dealing
with incomplete and changing information.

3  Potential of Negotiation Support Systems for Supporting

Requirements Negotiation

The process of requirements analysis including steps of clarification and terminology develop‑
ment is most definitely a negotiation process since it fulfils all the criteria of such a process.
Although there exist approaches in the research field of requirements engineering, negotia‑
tion research has up to now disregarded this application area. Looking at negotiation support
systems, the question is whether NSSs can be used for electronic requirements negotiations.
We will discuss each support component, i.e. communication support, decision support, and
document management w.r.t. the specifics of requirements negotiations.
The negotiation processes are between lay people and experts. In particular, each stake‑
holder acts both as a lay person and as an expert. The customer is an expert in the application
domain but a lay person when it comes to the technical aspects of software development. This,
however, is where the developer’s expertise lies who is at the same time a lay person in the
specific application domain. This requires a dedicated communication support, in particular
terminological support since the terminologies will differ to the extent that misunderstand‑
ings seem inevitable if communication is unsupported. For example, semantic support needs
to clarify the meaning of utterances whereas pragmatic support can help to place a statement
into context [28].
Since requirements will evolve over time and might very well change during the process,
an NSS will have to deal with incomplete and missing information. This will require adequate
decision support as well as flexible processes that allow negotiation issues to be inserted,
modified, or deleted (cf. also [29]).
All interactions need to be document for several reasons. Firstly, the interaction processes
involve several stakeholders (as described above) and might require internal coordination which
itself must be based on a sound, complete, and consistent process documentation. Secondly,
software development processes require a specification agreed upon by the stakeholders as
308   A. Lenz, M. Schoop, and G. Herzwurm

a document in several versions specific to such development process. Thirdly, documenta‑

tion that is directly derived from the interactions enables traceability and enhances trust
[28, 30, 31].
We argue that negotiation support systems are pre‑destined for electronic requirements
negotiations. In particular, Negoisst is well­‑suited with its sophisticated communication sup‑
port, decision support, and document management [28, 32]. Nevertheless, the above specifics
require adapted solutions which is what we are currently working on.

References
1.  Pohl, K.: Requirements Engineering. Fundamentals, Principles, and Techniques. Springer, Berlin,
Heidelberg (2010)
2.  Grünbacher, P. and Seyff, N.: Requirements Negotiation. In: Aurum, A., Wohlin, C. (eds.), Engi‑
neering and Managing Software Requirements, pp. 143–162. Springer, Heidelberg, Berlin (2005)
3.  Price, J. and Cybulski, J.: The Importance of IS Stakeholder Perspectives and Perceptions to
Requirements Negotiation. In: Proceedings of the 11th Australian Workshop on Requirements
Engineering (2006)
4.  Frühauf, K., Fuchs, E., Glinz, M., Grau, R., Hood, C., Houdek, F., Hruschka, P., Paech, B.,
Pohl, K., and Rupp, C.: IREB Certified Professional for Requirements Engineering. Foundation
Level. Syllabus. Version 2.2, http://www.ireb.org/fileadmin/IREB/Lehrplaene/IREB_cpre_syl‑
labus_FL_en_v22.pdf (access: 25th Mar 2015)
5.  Reiser, A., Krams, B., and Schoop, M.: Requirements Negotiation in Consideration of Dynamics
and Interactivity. In: Proceedings of the ­R EFSQ 2012 Workshops and the Conference Related Em‑
pirical Study, Empirical Fair and Doctoral Symposium, ICB Research Report No. 52, pp. 163–174.
Springer, Berlin (2012)
6.  Bichler, M., Kersten, G., and Strecker, S.: Towards a Structured Design of Electronic Negotiations.
Group Decision and Negotiation, 12, pp. 311–335 (2003)
7.  Herzwurm, G., Schoop, M., Reiser, A., and Krams, B.: E‑Requirements Negotiation: Elektronische
Verhandlungen in der verteilten Softwareentwicklung. In: Mattfeld, D.C., Robra­‑Bissantz, S. (eds.),
Tagungsband Multikonferenz Wirtschaftsinformatik, pp. 1859–1870 (2012)
8.  Ahmad, R., Tahir, A., and Kasirun, Z.M.: An empirical assessment of the use of different com‑
munication modes for requirement elicitation and negotiation using students as a subject. In:
Computers & Informatics (ISCI), 2012 IEEE Symposium on, pp. 70–74 (2012)
9.  Calefato, F., Damian, D., and Lanubile, F.: Computer­‑mediated communication to support distrib‑
uted requirements elicitations and negotiations tasks. Journal of Empirical Software Engineering,
17, pp. 640–674 (2012)
10.  Ahmad, S.: Requirements Negotiation: Making System Stakeholders‘ Multiple­‑Views One. Journal
of Communication and Computer, 8, pp. 290–299 (2011)
11.  Ahmad, S. and Muda, N.A.: An Empirical Framework Design to Examine the Improvement in
Software Requirements through Negotiation. International Journal on New Computer Architectures
and Their Applications, 1, pp. 599–614 (2011)
12.  Renzel, D., Behrendt, M., Klamma, R., and Jarke, M.: Requirements Bazaar: Social Require‑
ments Engineering for Community­‑Driven Innovation. In: 21st IEEE International Requirements
Engineering Conference Proceedings, pp. 326–327 (2013)
13.  Robinson, W.N.: Negotiation behavior during requirement specification. In: 12th International
Conference on Software Engineering, pp. 268–276 (1990)
 Requirements Analysis as a Negotiation Process 309

14.  Robinson, W.N.: Interactive Decision Support for Requirements Negotiation. Concurrent Engi‑
neering: Research and Applications, 2, pp. 237–252 (1994)
15.  Mu, K., Liu, W., Jin, Z., Hong, J., and Bell, D.: Managing Software Requirements Changes Based
on Negotiation­‑Style Revision. Journal of Computer Science and Technology, 26, pp. 890–907
(2011)
16.  Zhang, Y., Ying, J., Bai, J., and Zhang, J.: A Negotiation Framework for Managing the Require‑
ments Changes. Cybernetics and Information Technologies, 13, pp. 75–87 (2013)
17.  Dubois, E., Kritikos, K., and Kubicki, S.: An Automatic Requirements Negotiation Approach
for Business Services. In: 2011 IEEE 9th European Conference on Web Services, pp. 133–140
(2011)
18.  Boehm, B. and Ross, R.: Theory‑W software project management principles and examples. IEEE
Transactions on Software engineering, 15, pp. 902–916 (1989)
19.  Boehm, B., Bose, P., Horowitz, E., and Lee, M.J.: Software requirements negotiation and renego‑
tiation aids: A Theory‑W Based Spiral Approach. In: 17th International Conference on Software
Engineering, pp. 243–253. Association for Computing Machinery, New York (1995)
20.  Fisher, R. and Ury, W.: Getting to yes. Negotiating agreement without giving in. Houghton Mif‑
flin, Boston (1981)
21.  Khan, U.Z., Wahab, F., and Saeed, S.: Integration of Scrum with Win‑Win Requirements Negotia‑
tion Model. Middle­‑East Journal of Scientific Research, 19, pp. 101–104 (2014)
22.  Sofian, H.B., Salim, S.S., and Shahamiri, S.R.: A Requirements Negotiation Process Model that
Integrates EasyWinWin with Quality Assurance and Multi­‑Criteria Preference Techniques. Arabian
Journal for Science and Engineering, 39, pp. 4667–4681 (2014)
23.  Niazi, M.A.K., Abbas, M., and Shahzad, M.: Three Tier Unified Process Model for Requirement
Negotiations and Stakeholder Collaborations. International Journal of Advancements in Research
& Technology, 1, pp. 73–81 (2012)
24.  Erra, U. and Scanniello, G.: Assessing communication media richness in requirements negotiation.
IET Software, pp. 134–148 (2010)
25.  van de Walle, B., Campbell, C., and Deek, F.P.: The Impact of Task Structure and Negotiation
Sequence on Distributed Requirements Negotiation Activity, Conflict, and Satisfaction. In: Pro‑
ceedings of the 19th International Conference on Advanced Information Systems Engineering,
pp. 381–394 (2007)
26.  Gulliver, P.H.: Disputes and negotiations. A cross­‑cultural perspective. Academic Press, New
York (1979)
27.  Kersten, G.: Support for Group Decisions and Negotiations An Overview. In: Clímaco, J. (ed.)
Multicriteria Analysis, pp. 332–346. Springer, Berlin, Heidelberg (1997)
28.  Schoop, M.: Support of Complex Electronic Negotiations. In: Kilgour, D.M., and Eden, C. (eds.),
Handbook of Group Decision and Negotiation, 4, pp. 409–423. Springer, Netherlands (2010)
29.  Grünbacher, P., Köszegi, S., and Biffl, S.: Stakeholder Value Proposition Elicitation and Reconcili‑
ation. In: Biffl, S., Aybüke, A., Boehm, B., Erdogmus, H., and Grünbacher, P. (eds.), Value­‑Based
Software Engineering, pp. 133–154. Springer, Berlin (2006)
30.  Staskiewicz, D.: Document­‑ Centred Electronic Negotiations. Verlag Dr. Hut, Munich (2009)
31.  Köhne, F., Schoop, M., and Staskiewicz, D.: An Empirical Investigation of the Acceptance of
Electronic Negotiation Support System Features. In: European Conference on Information Sys‑
tems (2005)
32.  Schoop, M., Jertila, A., and List, T.: Negoisst: A Negotiation Support System for Electronic Busi‑
ness‑to‑Business Negotiations in E‑Commerce. Data & Knowledge Engineering 47, pp. 371–401
(2003)

View publication stats