Ask the Expert

Elicit software requirements using a variety of techniques

What are some of the challenges associated with requirement elicitation? How does an iterative approach help that process?

    Requires Free Membership to View

More information on software requirements
Approaches to defining requirements within agile teams

Using iterations to help balance priority and risk

Software requirements elicitation and documentation
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."

This was first published in October 2008

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: