EBR Assignment3 Rizwan 10667311

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




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


2




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


3




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.


4




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.


5




(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


6




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.


7




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.


8




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.


9




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.

.


10




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)


11




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


12




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


13




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.


14




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


15


http://www4.in.tum.de/lehre/seminare/hs/SS04/requirements/winwin1.pdf

http://www.stsc.hill.af.mil/crosstalk/1999/04/davis.asp


http://www.cs.uvic.ca/~danielad/journal/IEEE_Software/DDamian_IEEESoftware_article.pdf


http://sunset.usc.edu/~aegyed/publications/Comparing_Software_System_Requirements_Negotiation_Patterns.pdf



http://www4.in.tum.de/lehre/seminare/hs/SS04/requirements/winwin1.pdf

http://www.stsc.hill.af.mil/crosstalk/1999/04/davis.asp









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


16

http://www.agilealliance.org/articles/reviews/Grunbacher1/articles/ComplementingXPWithRequirementsNegotiation.pdf



http://www.gao.gov/cgi-bin/getrpt?GAO-04-393

http://www.goldpractices.com/practices/rto/index.php%20viewed%20on%2005/05/2009




http://www.gao.gov/cgi-bin/getrpt?GAO-04-393

http://www.goldpractices.com/practices/rto/index.php%20viewed%20on%2005/05/2009

Documents

EBR Assignment3 Rizwan 10667311