8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 1/16
32569 Enterprise Business Requirements – Autumn 2009
UNIVERSITY OF TECHNOLOGY, SYDNEY
FACULTY OF ENGINEERING & IT
INDIVIDUAL ASSIGNMENT
Submitted To
Prof. Didar Zowghi
BY:
RAZA Mohammad Rizwan (10667311)
Due Date: 14th May 2009
RAZA, Mohammad Rizwan (10667311)
1
Enterprise Business Requirements
Subject No: 32569
Enterprise Business Requirements
Subject No: 32569
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 2/16
32569 Enterprise Business Requirements – Autumn 2009
Table of Contents
Table of Contents 2
1. Introduction to Requirement Engineering …………………………………3
2. Introduction to Requirement Negotiation …………………………………3
3. Benefits of Requirement Negotiation …………………………………54. Challenges to Requirement Negotiation …………………………………6
5. Solutions to the challenges ………………………………..10
6. Conclusion ………………………………...14
References ...…………………………………….. 15
RAZA, Mohammad Rizwan (10667311)
2
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 3/16
32569 Enterprise Business Requirements – Autumn 2009
1. Introduction to requirement engineering
Requirement engineering proposes to elicit customers’ requirement and in most of the
cases customer don’t know what is the requirement or requirement keeps on changing
with the inflows of ideas. Requirement engineering provides Business Analyst and
Software Engineers to understand and solve the specific problem. Moreover, it includes
the business impact of the software, customer requirement and the users’ interaction
with the system. The complete life-cycle includes Business analysts and stakeholders.
The need to elicit requirement is to track the entire business requirement of the customer
and to solve the requirement. It starts with the defining of scope and the nature of the
project. Further, the elicitation i.e., definition and elaboration of task is defined. After
the definition of the task negotiation occur leading into priorities of task. Finally, theunderstanding of analyst and the customer is matched to ensure that understanding
coincides. Finally, Pressman (2005) concludes that requirement engineering build a
bridge between design and development.
Primarily, according to Pressman (2005) and Davis et al. (1999) and many other
researchers, the requirement engineering tasks involve in the following stages.
1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management
This paper will discuss regarding the challenges associated with the requirement
negotiation.
2. Introduction to Requirement negotiation
Requirements Negotiation is a process used early in the planning stages or when the
requirement changes for each project to understand and elicit the task. Requirement
negotiation involves between stakeholders to balance functionality, performance and
other functional and non-functional requirement against cost and time. Moreover, it
RAZA, Mohammad Rizwan (10667311)
3
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 4/16
32569 Enterprise Business Requirements – Autumn 2009
provides a collaborative environment and mutual respect and trust among stakeholders.
It involves and engages in the explicit trade-off between functionality, time and budget.
The basic purpose of requirement negotiation is to reach a common agreement
considering requirements time, budget, scopes and technology constraints. The
requirements are prioritized, potential conflicts of functional and non-functional
requirement are identified, options are proposed, a shared vision of the real
requirements are identified. In the course of requirements engineering activities,
conflicts are identified between stakeholders wanting incompatible features, or conflicts
between requirements and resources, or between capabilities and constraints. Following
figure depicts the requirement negotiation phases.
(Fig. 1 Source: Adapted from www.goldpractices.com/practices/rto/index.php)
Figure 1 describes the steps of requirements negotiation process. The blue line
describes the first two steps i.e. 0.1 and 0.2. Further, it describes the negotiation process.
Moreover, it describes the ways of requirements elicitation, analysis, validation and
requirements management. The collection of agreed requirements will be the outcome
of requirement negotiation.
RAZA, Mohammad Rizwan (10667311)
4
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 5/16
32569 Enterprise Business Requirements – Autumn 2009
3. Benefits of Requirement negotiation: Following are the benefits and
objectives of requirement negotiation.
• Identifying complete requirements in the early stages of a project
• Little requirements changes during development
• Shared vision throughout the life cycle
• Control of “Scope Creep”
• Knowledge of the project constraints
• Changes can be adapted easily
• Manage tacit knowledge
• Managing complexity
• Dealing with uncertainty
• Finding better solutions
• Finishing the project within Time and budget
The objective of requirement negotiation should be that there will be no loser in an
effective negotiation and both sides should win (Pressman 2005). Further, according to
Ludwig Erhard “A compromise is the art of dividing the cake in such a way that
everyone believes he has the biggest piece”. Following are the three major objective of
requirement negotiation.
3.1 Problem of scope: The scope of the system is poorly defined, moreover,
technical details may confuse to understand overall system objectives (Christel
and Kang 1992).
3.2 Problem of understanding: The customer and users have little knowledge of
the needed requirement from the system. They don’t understand the
capabilities and limitations of the system.
3.3 Problems of volatility: The requirements may and often change as they gain
knowledge and capabilities of the system.
RAZA, Mohammad Rizwan (10667311)
5
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 6/16
32569 Enterprise Business Requirements – Autumn 2009
(Fig 2 Adapted from Chaudron 2008 Pg : 3)
4 Challenges to Requirement negotiation: There are various and different types of
challenges to requirement negotiation depending upon various circumstances.
Further, Damian and Zowghi (2002) describe the culture, conflict and distance as a
major factor influencing requirement negotiation. Boehm et. el (1998) and Briggs et.
el also argues that diverse culture and distributed environment is a major challenge
to requirement negotiation. Following are the various challenges associated with the
requirement negotiation:
1. Limited stakeholders accessibility:
The major challenge with requirement negotiation is limited or inaccessibility of the
stakeholder. Many times the required concern person is either very busy or don’t have
time to negotiate.
To overcome with this challenge project people have to communicate with the
stakeholders for their availability and share their valuable time to work with the project
RAZA, Mohammad Rizwan (10667311)
6
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 7/16
32569 Enterprise Business Requirements – Autumn 2009
people. In the new web-based system prospect and potential customers can be traced
and identified.
2. Globally distributed stakeholders:
In the current diversified organizational scenario, the companies and stakeholders are
scattered through out the world and distributed geographically, whereas, the developers
and business analyst are available at different location. According to Damian et. el
(2002), the global distribution of stakeholders with different time zones add more
challenges to requirement negotiation. Moreover, the culture and language can also be
termed as a challenge to requirement negotiation. Additionally, in case of outsourced
project the challenges are further complicated due to communication gap between thestakeholders.
To overcome this challenges the developers and project stakeholders should actively
communicate and participate with the team. Researchers like Fisher et al, (1991) suggest
another good strategy is to actively communicate through email, videoconferencing and
teleconferencing. Another solution is that developers should go to the project
stakeholders place and work together.
3. Stakeholders do not know how to tell the requirement
The stakeholders generally don’t know their full requirement. After gaining the
knowledge of the system, they modify or add the requirement. They need time to
understand their requirement. The developer or BA describe and discuss regarding the
project to gain idea from the stakeholders and to convince what is important and should
be avoided. Sometimes, the stakeholders know the opportunities or problems, however,they don’t know how to solve the issue.
The project requirement is negotiated after helping to gather the requirement by
stakeholders. The problem may be sub-divided into small work and analyzed properly,
and later on the developer can recommend some requirements to them.
RAZA, Mohammad Rizwan (10667311)
7
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 8/16
32569 Enterprise Business Requirements – Autumn 2009
4. Stakeholders always change their minds
Project stakeholders always change their minds because sometimes the business
requirement changes before the completion of the project and technology is out of the
date. In many cases, the project stakeholder gets better idea and wants to change the
scope of the project.
5. Conflicting priorities
The project stakeholders have different priorities, goals and objectives attached to the
system. The requirement may differ among each stakeholders and sometimes conflicts
between stakeholders.
To solve the conflicting priorities, requirement is negotiated and standardized
acceptable to all and should be without any conflict. One general priorities and
objectives will be set for the system.
6. Too many project stakeholders want to participate
There are many not required stakeholders which don’t have any interaction with system.
Further, they don’t have much to contribute. They only lengthen the requirement
negation process by interfering in the requirement negotiation process.
The best option is that thanks them and assures that you will call them when you will
need their help.
7. Stakeholders have limited idea regarding technology
The stakeholders have limited and little idea regarding technology. They don’t know the
requirement that will be solved by the technology and sometimes some requirement can
not be achieved.
The best way to deal with this issue is to define the roles and responsibilities of project
stakeholders.
RAZA, Mohammad Rizwan (10667311)
8
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 9/16
32569 Enterprise Business Requirements – Autumn 2009
8. Project stakeholders has limited vision
Project stakeholders generally vision everything with the previous perception of system
which they had com across or worked upon. According to Young (2001), in mostcircumstances they want to have the new system like the old system with some added
features. Moreover, they may be scared of change because it will be difficult to use.
9. Project stakeholders don’t understand modeling language
Project stakeholders take time to understand the modeling language and the requirement
attached with the project. Additionally, they don’t understand that some parts of the
project are almost same and inter-linked to each other. That means the programmers
can’t continue with Y part of the project by skipping X part. The work break down
structure and sequencing of the project should be described and negotiated with the
stakeholders to gain trust. Further, communication gap should be removed.
10. Developers don’t understand the business domain
According to Egyed et. el (1998) a common challenge of requirement negotiation is
that developers fail to understand the business requirement and the communication and
negotiation between project stakeholders and developers are very slow and ambiguous.
Developers and stakeholders should sit together to understand each other and to talk in
same terms and language. Developers require time to understand the business domain.
11. Project stakeholders require significant formality regarding requirements
Project stakeholder should adhere to attend meetings and presentations and has to show
professionalism to smoothly run the project. If the stakeholders are less concerned there
is a chance of increase in budget and the requirement may not be addresses and
negotiated in a proper way leading into confusion and delay in the project.
12. Stakeholders insist on new requirement after budget and time is defined
When the project scope, time and budget are defined then the stakeholder insists upon
new requirement which is somewhat difficult to incorporate.
RAZA, Mohammad Rizwan (10667311)
9
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 10/16
32569 Enterprise Business Requirements – Autumn 2009
13. Communication with the stakeholders are very slow and ambiguous:
Due to language, culture and many other issues, the communication with the
stakeholders are slow and ambiguous. Young (2001) discusses in his book thefollowing experience that a customer walks to his office during the completion of the
project and says “I know you think you understand what I said, but what you
don’t understand is what I said is not what I mean.”
4. Solutions to the challenges
There are a lot of problems and issues related to the project. The issues and problems
can be tracked and negotiated at the beginning of the project or whenever the issue
arises. Requirement negotiation is a continuous process and ends when only the project
ends. Requirement negotiation enable to negotiate the requirement wave off some
requirement that are no longer needed and some requirements are included depending
upon the need. The requirement may be of functional, performance, cost, schedule, risk
thresholds, etc. types. According to Allan (2003), first the requirement should beclassified into following three categories and then negotiated according to their priority:
1. Must Have
2. Nice to have
3. Not Necessary
The above process will make the negotiation process easier as both party will know the
importance of the issues. Moreover, they can negotiate and agree on some and they can
leave something to negotiate in the later meeting. Additionally, this reduces the time
and conflict in negotiation process.
Many researchers discussed and described to find the solution of challenges to
requirement negotiation. Daniela and Zowghi (2002), Egyed et. el. (1998) and Mah
(2001) are prominent among them and following are some of the solutions prescribed
by them.
.
RAZA, Mohammad Rizwan (10667311)
10
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 11/16
32569 Enterprise Business Requirements – Autumn 2009
4.1 Negotiate with the correct stakeholders
Identify and negotiate with the correct and influential stakeholders in order to save the
time and in order to accommodate his requirement for the success of the project. Davis
(2003) describes that in one instance the absence of financial representatives resulted
into a failure of the project because his requirement was of prime importance.
Additionally, GAO (2004) suggests to ensure that the prime stakeholders should be
identified in the beginning and the contractual requirement should be gathered from
them for example who will provide financial requirement etc.
4.2 Establish a teamwork mentality
During the requirement negotiation process all the stakeholders should work as a team
with a mutually satisfactory solution, moreover, share the vision and understanding
about the development goals and alternatives (Grunbacher, 2002). The requirement
negotiation should be done in a friendly environment keeping in mind all the interests of
all the stakeholders.
4.3 Plan team interaction
The requirement negotiation strategy and the interaction will be planned before the
meeting. Ground rules will be set for the easy negotiation process. During the
interaction Developers learn more about the business processes whereas, customers and
users know about the technical possibility. Boehm (2001) argues that requirements are
not discovered, rather than it is a process of learning and negotiation as people learn the
financial and technical constraints
According to Damian (2001) it is found that it is important to have an initial face-to-
face contact between the facilitator and the collaborators (stakeholders) before any
computer-mediated meeting occurs. This enabled them to get to know each other, get a
sense of physical stature, and establish a relationship of trust.
4.4 Use a Group Support System (GSS)
RAZA, Mohammad Rizwan (10667311)
11
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 12/16
32569 Enterprise Business Requirements – Autumn 2009
Group Support Systems can be used to address the complexity of requirements
definition and negotiation. Briggs (2002) explains that 50% stress and time can be
reduced on requirement negotiation process with the help of GSS. It allows multiple
people work together and share the information, moreover, it helps physically
distributed team and stakeholders available in different time zones to negotiate
effectively.
4.5 Maintain a list of requirements
The scope and the list of requirements must be handy before the team indulge into
requirement negotiation, so that the team should go away discussing and negotiating of
the requirement of no interest.
4.6 Establish a shared vocabulary
During the requirement negotiation process the developer and stakeholder should use
the common acronyms and key terms to avoid confusion. Some technical terms like
SLOC (Source Lines of Code) and POP (Period of Performance) will be common to
developers whereas business terms will be common to other stakeholders, however,
both have little knowledge regarding other’s terms. Moreover, jargon and acronyms can
hinder the process of requirement negotiation. Sometimes, one term may be different to
different people thus a common shared vocabulary should be defined and implemented.
4.7 Organize and Record requirements attribute
Before the negotiation, requirements need to be organized and should be identifiable
and distinguished. Requirement negotiation should be done in order of hierarchy and
priority.
The dependency and necessity attributes of negotiation should be recorded and
considered. The estimation of budget and time should be done by using bottom-up
approach to achieve near to actual result.
4.8 Manage by past experience
RAZA, Mohammad Rizwan (10667311)
12
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 13/16
32569 Enterprise Business Requirements – Autumn 2009
Davis (2003) suggests that negotiation is easier when everyone recognizes the effort for
past projects, and actual project duration.
4.9 Re-plan for every new release
Re-planning before every new release provides an ability to negotiate the current
situation regarding resource and requirement because both may change. Moreover, the
stakeholders, technology, environment and budget may change after a certain period of
time. Therefore, it is important to again negotiate the requirements with the stakeholders
and if there is a change can be incorporated in the project.
4.10 Negotiate workable solution
If the team accepts a schedule which can not be achievable it should be negotiated
because it gives false expectation of the release ultimately leading to a loss of trust and
faith. Although, the time is critical but accepting a technically less time will deliver the
desire product and quality may be compromised.
4.11 Provide training in the negotiation process
The developer and project managers should undergo the training of requirement
negotiation because of the programmers lack to manage stakeholders’ relationship or
soft skills as collaborative techniques.
4.12 Help of trained facilitator
The developer may find difficult to negotiate, therefore, help of trained facilitator can bean advantageous. A facilitator is independent in the negotiation and focus to build trust
and ensures stakeholders’ participation and co-operation in the negotiation.
4.13 The triple constraint (cost, time and scope)
While requirement negotiation always keep in mind the project management constraint
of cost, time and scope. If there is a variation in scope there will be a variation cost and
RAZA, Mohammad Rizwan (10667311)
13
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 14/16
32569 Enterprise Business Requirements – Autumn 2009
time also (Nelson, 2003). Therefore, if the stakeholders insist to change the requirement,
again work upon time and cost before accepting the proposal of change.
4.14 Evaluate and develop alternatives
4.15 Probe for underlying interests
4.16 Invent as many options as possible
4.17 Develop well-planned and realistic commitments
4.18 Ensure effective communication
4.19 Separate the people from the problem
4.20 Invent options for mutual gain
4.21 Insist on using objective criteria
6. Conclusion: Software requirement negotiation has evolved as an extensive process
to identify and negotiate the requirement and achieve the mutual goal. The requirements
are identified and negotiated acceptable to all. Moreover, scope, budget and time should
be taken care of during the process of negotiation. There are many different types of challenges are associated with the software negotiation and effective negotiator could
enhance the process of requirement negotiation.
RAZA, Mohammad Rizwan (10667311)
14
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 15/16
32569 Enterprise Business Requirements – Autumn 2009
References
Barker, Michael D. and Nevison, John M., 2000, “ How Much is 10 Percent Worth?”,
PM Network, April 2000
http://www.oakinc.com/pdf/10percent.pdf
Briggs, Robert O. and Gruenbacher, Paul, 2002, “ EasyWinWin: Managing Complexityin Requirements Negotiation with GSS ”, Proceedings of the 35th Annual Hawaii
International Conference on System Sciences, (HICSS-35’02), IEEE Computer Society,
0-7695-1435-9/02, 2002http://www4.in.tum.de/lehre/seminare/hs/SS04/requirements/winwin1.pdf
Chaudron M., 2008 ‘ Requirements Engineering ’ pp. 3
Davis, Alan M. and Leffingwell, Dean A., 1999 , “Making Requirements Management Work for You”, CROSSTALK, April 1999
http://www.stsc.hill.af.mil/crosstalk/1999/04/davis.asp viewed on 05/05/2009
Davis, Alan M., “The Art of Requirements Triage”, IEEE Computer, March 2003
http://www.computer.org/computer/homepage/0303/Davis/
Damian, Daniela E., Herlea, Eberlein, Armin; Shaw, Mildred L.G., and Gaines, Brian
R., “Using Different Communication Media in Requirements Negotiation”, IEEE
Software, May/June 2000
http://www.cs.uvic.ca/~danielad/journal/IEEE_Software/DDamian_IEEESoftware_artic
le.pdf
Damian, Daniela E., Zowghi, D., 2002, “An insight into the interplay between culture,
conflict and distance in globally distributed requirement negotiation”, IEEE,
Egyed, Alexander and Boehm, Barry, 1998, “Comparing Software System
Requirements Negotiation Patterns”, Center for Software Engineering, University of
Southern California,
http://sunset.usc.edu/~aegyed/publications/
Comparing_Software_System_Requirements_Negotiation_Patterns.pdf
Grunbacher, Paul and Hofer, Christian, 2002, “Complementing XP with Requirements
Negotiation”, Systems Engineering and Automation, Johannes Kepler University,
Altenbergerstr. 69, 4040 Linz, Austria, 2002
RAZA, Mohammad Rizwan (10667311)
15
8/4/2019 EBR Assignment3 Rizwan 10667311
http://slidepdf.com/reader/full/ebr-assignment3-rizwan-10667311 16/16
32569 Enterprise Business Requirements – Autumn 2009
http://www.agilealliance.org/articles/reviews/Grunbacher1/
articles/ComplementingXPWithRequirementsNegotiation.pdf
Mah, Michael, 2001, “Negotiation – Not Something You Typically Learned in
College”, The Cutter Edge, Cutter Consortium, August 2001
http://www.cutter.com/research/2001/edge010807.html
Pressman, R., 2006, Software Engineering, Mc Graw Hill, pp 174-205.
Young, R., 2001, Effective requirement practices, Addison-wesley
“Stronger Management Practices Are Needed to Improve DOD’s Software-Intensive
Weapon Acquisitions “ , GAO Study on Defense Acquisitions , GAO-04-393, 2004
http://www.gao.gov/cgi-bin/getrpt?GAO-04-393 viewed on 14/05/2009
www.goldpractices.com/practices/rto/index.php viewed on 05/05/2009
RAZA, Mohammad Rizwan (10667311)
16