Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Requirements Analysis: Take Emotion Out of Software Purchasing Decisions

If your IT team runs up against rancor and indecision each time a purchase decision needs to be made, a requirements analysis can help you provide your boss with the documentation and consensus necessary to choose the right software development product in a timely manner.


advertisement
urchasing a software development product that different users will utilize in different ways is one of the trickiest tasks IT shops face. When selecting a tool such as a bug-tracking system, for example, one must resolve the requirements of four different groups: developers, testers, project managers, and senior managers. Attempting to satisfy all these groups during a buying decision often results in emotional turf wars and lengthy deliberations.

If you're part of an IT team that runs up against this time-wasting rancor each time a purchase decision needs to be made, a well-documented, well-executed requirements analysis can help you choose the right software development products in a timely manner. Using the process I outline in this article, you'll be able to provide the documentation and consensus necessary for your boss to go with your recommendation.

Take Emotion Out of the Process
The two typical approaches for choosing which software development tools a team will use are:

  1. The Dictatorial Approach—One person, usually a senior manager, decides what everybody will use. This approach is very straightforward, but since the manager doesn't do the jobs of all the people who will use the system, it can lead to bad purchases.
  2. The Ad-Hoc Committee Approach—A team (composed of individuals with differing interests in the benefits of the tool) collectively decides which one to buy. This approach can be extremely frustrating, because vocal, opinionated individuals can either force a poor decision or spend so much time arguing that no decision is ever made.



    Often, arguments aren't based on the relative merits of one system over another, but instead on people's deep-rooted insecurities. In my experience, people often cling like limpets to a product that catches their fancy but offer little tangible reason for their choices.

A properly planned and executed requirements analysis will avoid such emotions and result in a better purchase. Plus, it will assure a decision within a reasonable time frame.

Editor's Note: Guest commentator Simon Galbraith is co-founder and marketing director for Red Gate Software, a vendor of bug-, defect-, and issue-tracking software.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap