Вы находитесь на странице: 1из 3

Reasons For Dissatisfaction of Software Development

Team & Suggestions To Solve The Problem

It has been observed that when any software project is started the people
involved are unhappy with each other during the time of the development
and afterwards. The clients are dissatisfied by the technical team and the
technical team is unhappy with the user representatives.

There are many reasons for this hostile behavior of the team members
representing the users and developers, but the major of all the reasons that
cause the dissatisfaction of the team is its inability to communicate. This
reason can then be further classified into the following sub categories.

• Users are reluctant to give away information: users assume that if the
technology will be applied, it will pose a threat to their importance or
need in the organization. That’s why they are reluctant to give away
the information to the requirements engineer.

• Developers do not pay attention to the users requests: few of the


software developers do not think the user involvement necessary and
think of user involvement as unnecessary and interruption in their
work. They do not pay the due attention towards the users and end up
making users feeling unhappy and neglected.

• Vocabulary is not clearly defined: terminology of the users and


developers differ extremely. The terms used by users to define a
function or requirement is not understood by the developer and the
terms used by developers are unfamiliar to the users. Therefore, the
users and developers do not understand each other clearly and
completely and end up unhappy and dissatisfied with each other.

• Requirements engineer do not posses enough capability to get the


desired information: communication skills are the greatest tool of a
requirements engineer, if the requirements engineer is good at
communicating its ideas and understanding the ideas of the users, it is
able to satisfy the users and give the appropriate information to the
developers.
• Team members do not understand each other’s field of work: users
think that the development team do not understand the business
objectives and goals, and development team underestimate the
technical knowledge of the users. They do not regard each others field
of work. Thus creating an unhappy environment.

For all of the above reasons the communication is not good between the
development team and the user representatives.

Apart from the reason of inability of the user representatives and the
development 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 the
employees in confidence and should pay attention towards the real users
of the system, not on the representatives of the real users. This will save
the development team from the future rework.

Most of the conflict between the users representatives and the


development team occur when a requirement change is suggested.
Customer involvement is the only way to avoid an expectation gap, a
mismatch between the product that customers expect to receive and the
product that developers build. It’s not enough simply to ask a few
customers what they want and then start coding. If the developers build
exactly what customers initially request, they’ll probably have to build it
again because customers often don’t know what they really need.

The features that users present as their “wants” don’t necessarily equate
to the functionality they need to perform their tasks with the new product.
To get a more accurate view of user needs, the requirements analyst must
collect user input, analyze and clarify it, and determine just what to build
to 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 shared
understanding – this common vision of the intended product – the certain
outcomes are reword, delayed completion, and customer dissatisfaction

Another reason is ambiguous requirements. Ambiguity is the great


bugaboo of requirements specifications (Lawrence 1996). One symptom
of ambiguity is that a reader can interpret a requirement statement in
several ways. Another sign is that multiple readers of a requirement
arrive at different understandings of what it means. Ambiguity also
results from imprecise and insufficiently detailed requirements that force
developers to fill in the blanks.

Most products have several groups of users who might use different
subsets of features, have different frequencies of use, or have varying
experience levels. If you don’t identify the important user classes for
your product early on some user needs won’t be met. After identifying all
user classes, make sure that each has a voice.

The solutions for the above problems are simple.

Communicating regularly the status and direction of the project to the


team members is the work of the management. This will reduce the
customer dissatisfaction. Meetings carried out between the user
representatives and the development team will provide them with enough
time to clearly state their requirements and constraints and this will leave
little room for the dissatisfaction and misunderstanding.

Thinking of each others work as important and regarding each others’


knowledge with respect will also solve the most of the issues between the
users representatives and the development team.

The management of the user organization should take its employees in


confidence before hiring a team for the development of a new system or
enhancing the features of a current system. This will reduce the internal
conflicts and save the development team from the rework and
unhappiness.

Conclusion: Poor understanding of the requirements cause most of the


future problems for the users and the developers. Therefore, requirements
gathering process should be allocated enough time and the opinions and
findings of a requirements engineer should be giving importance.

By: Sugandh Wafai.


MS(SE)
Registration # 0771137
Reference: Software Requirements 2nd Edition By Karl E. Weigers
Microsoft Press

Вам также может понравиться