Login | Register   
LinkedIn
Google+
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  : Page 3

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
Focus on Requirements, Not Features
What many people call a requirements analysis is in fact a comparison of feature wish lists. These are not the same thing. Organizations that purchase using feature lists generally choose the product that has the widest feature set, which encourages bloatware. (Would you rather own a digital watch with a built-in calculator and telephone dialer or a Rolex?) Requirements analysis must focus on your current and future needs, not a laundry list of features that may not solve your particular problems.

Given the example of a bug-tracking system, the overall requirements might be:

  1. Making it easy to find issues and reproduce them
  2. Enhancing and enforcing software development processes
  3. Providing a comprehensive overview of the project and team progress
  4. A system that is simple to secure and administer
  5. Low implementation and management costs

Every company's requirements are slightly different, but in this case try to focus on the areas expected to make an impact on the effectiveness of the implemented system.



State up front whether every requirement is equally important or whether some things are more important than others. You can use this later when totaling up the scores for the different products under evaluation. (The requirements analysis spreadsheet included with this article uses a simple rating scale where 5 is the most important requirement and 1 the least important.)

If you can agree on requirements before you begin serious evaluation, it will be easier to deal with the inevitable requests for features. You will be in a position to judge features based on their ability to meet the key requirements you've defined, not on the fact that they sound cool or suit the fancy of one person. Obviously, you can't be 100-percent strict here, since some of your requirements might come out of understanding what is possible with a product.

Look for Improvement, Not Perfection
Once you understand your requirements, you can use a requirements analysis spreadsheet to help determine the best product to buy (see the sample spreadsheet for an example). Now comes a slightly counter-intuitive bit: the best product to buy is not the perfect product. You are trying to arrive at a solution in a reasonable timeframe that allows you and the people around you to work together better than you did before.

You don't need to evaluate every possible product. You need to evaluate products only until at least one satisfies your requirements. If you set out on a quest for the perfect product, you'll probably never make a decision. Companies that seek product perfection generally end up writing their own solutions, which they usually regret later.

After you've identified products for analysis, you should ask those involved in the decision-making process to use the spreadsheet to rate how well each product would meet their requirements. Although you want to avoid ending up in a vendor feature war, sometimes you will be forced to discuss specific features. Here is an example of how you might handle a situation involving two features found in some bug-tracking systems:

  1. The ability to save an attachment with an issue—This is likely to be very useful in making the issue reproducible, so it should receive a high score on one of your major requirements in the analysis spreadsheet.
  2. The ability to integrate with SourceSafe—This would allow you to log every issue in SourceSafe, reducing the risk of two people doing redundant work. This feature could, however, ultimately burden your team with additional overhead that other process-related aspects of the system should handle. If you wouldn't use this feature, it shouldn't influence your rating.

Try to include all interested parties in the rating process and convene a quick meeting to agree on the ratings for each product (or just average the ratings if time is short). At this point, you can also rank the different requirements in order of their importance.

Next, simply multiply the rankings and the ratings in the analysis spreadsheet to calculate overall scores for each requirement. Adding the overall scores gives you a composite score for each product. The highest-scoring product probably is the right solution for your company.



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap