Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Reasons for Dissatisfaction of Software Development

Reasons for Dissatisfaction of Software Development

|Views: 40|Likes:
Published by Sugandh Wafai

More info:

Published by: Sugandh Wafai on Dec 27, 2009
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





Reasons For Dissatisfaction of Software DevelopmentTeam & Suggestions To Solve The Problem
It has been observed that when any software project is started the peopleinvolved are unhappy with each other during the time of the developmentand afterwards. The clients are dissatisfied by the technical team and thetechnical team is unhappy with the user representatives.There are many reasons for this hostile behavior of the team membersrepresenting the users and developers, but the major of all the reasons thatcause the dissatisfaction of the team is its inability to communicate. Thisreason can then be further classified into the following sub categories.
Users are reluctant to give away information: users assume that if thetechnology will be applied, it will pose a threat to their importance or need in the organization. That’s why they are reluctant to give awaythe information to the requirements engineer.
Developers do not pay attention to the users requests: few of thesoftware developers do not think the user involvement necessary andthink of user involvement as unnecessary and interruption in their work. They do not pay the due attention towards the users and end upmaking users feeling unhappy and neglected.
Vocabulary is not clearly defined: terminology of the users anddevelopers differ extremely. The terms used by users to define afunction or requirement is not understood by the developer and theterms used by developers are unfamiliar to the users. Therefore, theusers and developers do not understand each other clearly andcompletely and end up unhappy and dissatisfied with each other.
Requirements engineer do not posses enough capability to get thedesired information: communication skills are the greatest tool of arequirements engineer, if the requirements engineer is good atcommunicating its ideas and understanding the ideas of the users, it isable to satisfy the users and give the appropriate information to thedevelopers.
Team members do not understand each other’s field of work: usersthink that the development team do not understand the businessobjectives and goals, and development team underestimate thetechnical knowledge of the users. They do not regard each others fieldof work. Thus creating an unhappy environment.For all of the above reasons the communication is not good between thedevelopment team and the user representatives.Apart from the reason of inability of the user representatives and thedevelopment team; the internal conflicts of the organization is also one of the reasons of unhappiness.Before getting any system developed the management require to take theemployees in confidence and should pay attention towards the real usersof the system, not on the representatives of the real users. This will savethe development team from the future rework.Most of the conflict between the users representatives and thedevelopment team occur when a requirement change is suggested.Customer involvement is the only way to avoid an expectation gap, amismatch between the product that customers expect to receive and the product that developers build. It’s not enough simply to ask a fewcustomers what they want and then start coding. If the developers buildexactly what customers initially request, they’ll probably have to build itagain because customers often don’t know what they really need.The features that users present as their “wants” don’t necessarily equateto the functionality they need to perform their tasks with the new product.To get a more accurate view of user needs, the requirements analyst mustcollect user input, analyze and clarify it, and determine just what to buildto let users do their jobs. The analyst has the lead responsibility for recording the new system’s necessary capabilities and properties and for communicating that information to other stakeholders. This is an iterative process that takes time. If you don’t invest the time to achieve this sharedunderstanding – this common vision of the intended product – the certainoutcomes are reword, delayed completion, and customer dissatisfactionAnother reason is ambiguous requirements. Ambiguity is the great bugaboo of requirements specifications (Lawrence 1996). One symptom

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->