In my opinion, the crisp gathering of business requirements is an art that every developer should master, yet it seems to be a skill generally lacking in most of us. In fact, it seems there are two extremes.

Some developers love to gather requirements, perform modeling, and make nice flowcharts. Their idea of the perfect project is one where all you do is gather and model the business requirements. On the other side are the majority of developers, who view the formal gathering of business requirements as a process of questionable value that takes time away from the red meat of development—design, coding, and testing. Whichever camp you’re in, this column—one of five in our analysis series—will show you some valuable methods of getting at the information you need.

A skill for all developers
The truth is that all developers, especially senior developers and team leaders, need to appreciate the value of gathering good business requirements and need to have some fundamental skills in gathering them. The value statement is easy to articulate. Gathering good requirements up front saves time and money and improves the overall quality of your product. Remember, your customers are going to require that the final solution meets their needs. The question is whether you discover their needs before you start to design and build or whether you’ll be forced to retrofit missed requirements into the solution after the fact.

Once you understand the importance of business requirements, your focus should shift to finding effective ways to obtain that information. You may already have a preferred approach with end users or others in the various business units. So you’re done, right? Wrong.

Even if you feel your current approach works great, it helps to have more than one tool in your toolbox. By returning to your subject-matter experts with another technique, you may unearth valuable information that they hadn’t previously thought to mention.

Getting to the answers
You’ll often need to use multiple information-gathering techniques to get a complete picture of the system you’re working on. Here are some techniques you can use as you set out to gather business requirements:

  • One-on-one interviews: The most common technique for gathering requirements is to sit down with the customer and ask what he or she needs. The discussion should be planned ahead of time based on the type of requirements you’re looking for. The interview can be tailored to discuss current processes, uncover future needs, or determine the problems the customer is trying to resolve.
  • Group interviews: These interviews have a similar purpose to the one-on-one interview, but they require more preparation and more formality to get the information you want from all the participants. You can uncover a richer set of requirements in a shorter period of time if you can keep the group focused.
  • Facilitated sessions: In this technique, you get a much larger group together and potentially keep them together until all the requirements are gathered. This may require the attendance of all primary and secondary stakeholders to make sure no piece of the requirements puzzle is overlooked. This technique requires heavy preparation and the use of a trained facilitator to keep the group on track and functioning productively.
  • Questionnaires: This approach is much more informal and can have limited value. However, questionnaires are good tools to use with stakeholders in remote locations or with those who will have only minor input into the overall requirements. A questionnaire can also provide a valuable means of gathering quick statistics, such as the number of people who would use certain features, or to get a sense of the relative priority of requirements.
  • Following people around: This method is especially helpful when gathering information on current processes. You may find, for instance, that some people’s work routines have become so habitual that they have a hard time explaining what they do or why they do it. You may need to watch them perform their work before you can understand the entire picture.

The special case of prototyping
Prototyping is a relatively modern technique for gathering requirements and can work well with Web development. In this approach, you gather preliminary requirements that you use to build an initial version of the solution—a prototype. You show this to the customer, who then gives you additional requirements. You change the application and cycle around with the customer again. This repetitive process continues for an agreed number of iterations or until the product meets the critical mass of business needs.

The difference between success and failure
Gathering comprehensive requirements can mean the difference between a project’s success and failure. Many developers have a tendency to gather requirements forever or to not gather them at all. Make sure your project includes the time required for developing a comprehensive list (without going overboard). Developers typically gather requirements in one-on-one interviews, but as we’ve seen, you can take advantage of a number of alternative techniques as well. Mastering these techniques will enable you to gather your requirements in a more effective and efficient manner.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching project management and life-cycle skills for the IS division. He’s also worked for Eastman Kodak and Cap Gemini America and has developed a project management methodology called TenStep. He holds a B.S. in computer science from Iowa State University.