Elicit software requirements using a variety of techniques

Industry experts offer varying opinions as to the best approach for requirements elicitation. Likewise, individuals utilizing their own experience and techniques will exhibit practices and methods that continually change. There are many trusted techniques in this area and most will deliver some level of satisfactory results. However, in many cases, the individual -- more than the technique -- produces good requirements detail. Individuals must acquire skills and expertise in order to effectively execute these techniques.

Requirements elicitation is non-trivial and typically involves activities such as personal interviews, group facilitated sessions, brain-storming, surveys, prototyping, use cases, etc. Each has advantages and disadvantages, which often come from influences such as organizational culture, political atmosphere, individual assertiveness, and even peer issues. Management support and participation are required in order for those techniques to be effective. Likewise, a thorough understanding of many techniques, and when to use each, should be part of a library that the organization and the individual have at their disposal.

Additional challenges involve capturing the "voice of the customer" and finding the best way to represent this information. Many will use a document or spreadsheet to record the details from the user. These methods cause additional management effort from the analyst to represent the information, share it with others, and coordinate data updates. Since elicitation is not a "one-time" event, there is a need to continue updating these requirements. Each time the requirements are discussed you need to make sure they remain clear and understood. The end user, and the person capturing the user's needs, must strive to stay in sync with the wording, understanding, and associated details of the requirements.

During discussions with the user, you must also record the details involving the impact and traceability to any new or existing requirements. This often entails multiple discussions with those users or groups requesting the capability. It is difficult to determine when you have identified and captured all the needs of the user, or when you have a complete set of requirements. For that reason, iterative practices can advance the requirements cycle while allowing other phases of software development to proceed. Iterative or agile techniques do not eliminate the need to understand the user's requirements. However, they do permit design and development to start -- and even show -- results back to the user for their agreement and acceptance.

Within agile practices, requirements elicitation is still necessary. The difference between agile and traditional waterfall approaches often comes down to the level of detail that is stored as documentation for the organization. While some organizations are required by law to produce extensive documentation around requirements, many do so as a part of their methodology. To support this level of recordkeeping, many elicitation techniques must be used and repeated throughout the development lifecycle. For example, I might conduct a group session to gather initial requirement details, whereas after showing a prototype to the user, there may be a need to spend one-on-one time with individual users in order to gain their approval. This one-on-one time is often an elicitation, analysis, and clarification of the requirements gathered at the beginning.

The bottom line for successful elicitation is to develop strong personal skills focusing on a wide variety of techniques. Practitioners should learn which techniques work best under a variety of circumstances and at various points in time. Individuals and organizations will need to fine-tune these techniques according to their chosen development methodologies and realize that "it all depends on the user."