Sunday, May 23, 2010

Impact of Requirement bill on requirement process

There is a famous saying “Great minds think alike”. When many great minds are gathered to create new software, two rarely thought exactly alike where as only a collaborative relationship between software team and customer can lead to success. It is very often that problems arise because of unclear understanding of what requirements are and who the customers are. Usually customer expects the software team to figure out what they need without a lot of discussion and necessary documentation. Similarly, the development team believes that they know better and they can do better without customer’s involvement.

So, a Requirements bill serves the best purpose to clarify key misconceptions and to create a healthy and strong relationship between customer software during requirement engineering process. Here our focus of discussion is Requirements Bill of rights and responsibilities for Software Customers. Bill of rights is the expectations of customer while interacting with software team and bill of responsibilities includes the responsibilities the customer has to the software team. This bill can play a vital role in helping customer to understand the requirement gathering process and what the requirement analyst needs from him.

Before starting the project, customer and software team must review the requirement bill of rights and responsibilities. Companies should not hide the requirement bill; each and every thing must be clear before project kick-off. This understanding can reduce friction later, when one party expects something the other isn’t willing or able to provide.

Requirement bill has a lot of positive impacts on customers as well as software team during requirements gathering process. A few of them are listed below:

  • Software team can design or develop the software according to the customer’s needs and desires.
  • Both software team and customer understand the reality that it is impossible to know the entire requirement early and no doubt they can be change. And so they will have the ‘change factor’ in mind and will consider the sign-off just the concept of establishing baseline of the requirement agreement. This factor lessens expensive rework and schedule slippage.
  • Customers don’t get frustrated with the requirement engineering process if they are well aware of the requirement bill. They come to know that it is an excellent investment and less painful if they understand and respect the techniques and working style of the software team.
  • By presenting ideas and alternatives, analyst can suggest improvements in the existing software that the new software could provide that the users haven’t even envisioned.
  • Analyst can modify customer’s requirements to allow the developers to reuse existing software as they might know of software components that can address some need described by customer. Adjusting customer’s requirements when sensible reuse opportunities are available can save time that would otherwise be needed to build precisely what the original requirements specified.
  • Customer and software team can make timely decisions because software team/analyst can provide customer to make many choices and decisions to resolve many issues and customers who are authorized to make such decisions must do so promptly when asked.
  • Specific characteristic are explored by the analyst who make the software easier and pleasant to let the customers accomplish the tasks accurately and efficiently.
  • The customers respect analyst’s ideas as they know that only he/she can provide different feasible options against the requirements asked by them.
  • Desired project outcome is achieved because of clear communication.
  • Greatest value is delivered at the lowest cost.
Many times software is compromised by a lack of understanding or focus on the core functionality. It is a gigantic work to keep the software away from incompetence or inefficiency but it can be possible if the requirement bill of rights and responsibilities are shared between both the software team and customers before the start of every project.

No comments:

Post a Comment