Ascertaining the Requirements of a Software Project

Author: jesse12 | Posted: 05.03.2012

The assessment of requirements to be targeted in a project is amongst the most necessary preparatory activities that any good software developer pays attention to. While accessing these requirements the developer tries to interact with users who are currently using the software and also users who may use them in the future. Theoretically also according to waterfall projects, it has been stated that it’s imperative to realize the whole problem at hand first before embarking on a journey to solution designing and providing. The concept of agile projects on the other hand puts forward the view that only some basic understanding of a project is sufficient to get on with it and the subsequent gaps in the knowledge shall itself be filled in at later stages in the project.

A requirement gathering activity needs to be conducted for a project irrespective of its type. It’s for this reason important to understand that the process of requirement gathering suffers from an in-built anomaly. To know how, read on:

How a requirement gathering process works:

Suppose a client needs a new Intranet, he approaches a software development company to get the same done. The problem with the intranet is that though it functions alright in the main but the technology used in the intranet has turned obsolete. The client is also interested in adding some latest features to the intranet. The software developer performs the following steps to gather requirements:

A web software developer plans the meeting based on the key areas that needs to be addressed in the software i.e. assessing the old intranet, experiences of users, features required to be added etc. The software developer makes it a point to gather all this information from people who have maximum exposure with these categories.

She/he makes a list of major issues discussed during these meetings.

Instead of relying on third party impressions, he himself checks the way Intranet is functioning to create an opinion of his own.

She/he prepares a report when the requirement gathering activity comes to an end with some recommendation from his end too.

Once the report is prepared, the software developer goes back to his team with all the requirements of software but the requirements collected aren’t free from bias and have incomplete information. This happens because the communication of requirements takes place in a really fragmented format beginning from the client’s perception to the way consultant puts it forward. This is where a lot of noise gets attached to it making it imperfect. The actual information which the client thinks of expressing to the way the developer receives it has the chances of toning down or distorting it by a considerable 40%. The only purpose behind analyzing this distortion is to improve the requirement gathering process in all and to adopt a process which pays clear attention to avoiding all these natural bias in the process of communication.

Article was printed from http://www.articleside.com/software-articles/ascertaining-the-requirements-of-a-software-project.htm
Click here to return original format