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