Mistakes in gathering requirements.

The worst possible way for the software requirements process is to have customers write up requirements and toss them over some imaginary wall.  The software development team works on the project for months and then shows up with a semi-completed project during acceptance testing.  Of course, the software is missing functions and does not work as desired by the client.  The problem is not that the business problem and solution changed during this time;  the problem is the business problem and solution were never defined.

Another common practice is sitting in a conference room with a customer and asking, “What do you want?”  Sitting in a conference room asking questions may not be a useful way to gather requirements, and it certainly should not be the only way.  This has nothing to do with how smart  or how good you are at asking questions.   Some developers will code what they thought the customer said and then show it to the customer.  This is commonly known as a code/test iteration.  A logical question is, “Why does it take so many code/test iterations to determine what a customer wants?” What were the reasons the developer and customer did not get it right in one or two tries (iterations)?  While this method is known as code/test, it is really a trial and error method to gather requirements.  The problem with trial and error is there are a lot of errors made along the way.

None of the solutions I mention actually address the root cause of the problem.   Many software professionals have thrown up their hands and accept that growth and changing functionality is just the nature of software development.  They incorrectly conclude the best strategy is to learn to adapt as the customer changes his or her mind.   In this scenario the solution to the problem is adaptation.   The teams need to be formed in such a manner so as to react as quickly as possible to the growing and changing environment.

The best way to gather requirements is to learn how to elicit requirements and study the core business.  The business analyst needs to be skilled at ethnology and a master of the metaphor.

You can read more in the free online book, Reboot!  Rethinking and Restarting Software Development, free at http://www.RebootRethink.Com

Published in: on June 26, 2009 at 01:01  Comments (1)  
Tags: ,

The URI to TrackBack this entry is: https://davidlongstreet.wordpress.com/2009/06/26/mistakes-in-gathering-requirements/trackback/

RSS feed for comments on this post.

One CommentLeave a comment

  1. Getting customers to tell you what funtionality they want is like getting your wife to tell you what she wants for her birthday:
    She won’t tell you, but will soon let you know when you’ve got it wrong.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: