Requirement Elicitation Techniques

The development process commences with the endeavor of understanding the client’s “business requirements”. This leads to creating a Vision and Scope document that describes the background leading to the decision to develop a new or modified system or capability and describes the system to be developed.

For the success of any project, an agreed upon understanding of the desired capability is extremely critical. It is good to consider iterative scoping meetings with the client for achieving this. The process of Requirements Elicitation, itself, generates more detailed and creative thinking about the problem that, in turn, affects the scope. The following are some popular and recommended techniques for requirements elicitation. These are techniques that can be used in combination as well.

a. Interviews: This technique uses a series of questions that focus on the client’s perspective, develops an understanding of the problem and finally evaluates the effectiveness of the meeting. For example, who is the customer for this system, what is the real reason for wanting to solve this problem, what environment is this product likely to encounter, What kind of product performance is required, etc. Although this is widely used and popular technique, there is chance that the predisposition, experience, understanding and bias of the interviewee and the interviewer may influence the information obtained. According to Gause, “The use of context free questions by the interviewer helps avoid prejudicing the response”. Context free question is a question that does not suggest a particular response.

b. Document Analysis: All effective requirements elicitation involves some level of document analysis such as business plans, markets studies, contracts, requests for proposals, statements of work, existing guidelines, analyses of existing systems, and procedures. Improved requirements coverage results from identifying and consulting all likely sources of requirements.

c. Brainstorming: Brainstorming is a powerful technique because the most creative or effective ideas often result from combining seemingly unrelated ideas. Also, this technique encourages original thinking and the proposal of unusual ideas. Brainstorming involves both idea generation and idea reduction. The goal of the former is to identify as many ideas as possible, while the latter ranks the ideas into those considered most useful by the group.

d. Requirements Workshops: This technique is considered very powerful for eliciting requirements because they can be designed to encourage consensus concerning the requirements of a particular capability. They are best facilitated by an outside expert and are typically short (1 - 3 days).

Other advantages that are achieved by this technique includes commitment of participants to the work products and project success, teamwork, resolution of political issues and reaching consensus on a host of topics.

Some of the benefits of this techniques are:

• Costs are lower than multiple interviews
• Gives a structure to the capture and analysis of the requirements process
• Dynamic, interactive, cooperative
• Involves users and cuts across organization boundaries
• Helps to identify and prioritize needs and resolve contentious issues
• Helps to manage user’s expectations and attitude towards change

A special category of requirements workshop is a Joint Application Development (JAD) workshop. JAD is a method for developing requirements through which customers, user representatives and developers work together with a facilitator to produce a requirements specification that both sides support. This is an effective way to define user needs early. Another special category of the requirements workshop is contained within the Rapid Application Development (RAD) model.

e. Prototyping: This technique helps in building a quick and rough version of the desired system or parts of the system. This illustrates the capabilities of the system to users and designers. This technique serves as an excellent means of communication mechanism for all reviewers in understanding the interactions with the system. This sometimes gives an overly optimistic impression of completion possibilities since an impression is created that the developers are further along than is actually the case. Prototypes can be combined very effectively with other approaches such as JAD and models.

f. Use Cases: A use case is a picture of actions that a system performs by depicting the actions. This should be accompanied by a textual description and should not be used in isolation from other requirements gathering techniques. These are always supplemented with quality attributes and other information such as interface characteristics. Use cases and scenarios (description of the sequence of events) are known for facilitating team communication. They provide a context for the requirements by expressing the sequence of events and a common language for the end users and the technical team.

g. Storyboards: This technique is a set of drawings depicting a set of user activities that occur in an existing or envisioned system or capability. Storyboards may be thought of as forms of paper prototyping. In this technique, the Customers, Users or developers start by drawing pictures of the screens, dialogs, toolbars and other elements they believe the software should provide. These drawings are evolved by the group till the real requirements and details are worked out and agreed upon. This technique is in expensive and eliminates the risks and higher costs of prototyping.

h. Interfaces Analysis: One of the major causes of overrun is missing or incorrect interface. Identifying the external interfaces early clarifies product scope, aids risk assessment, reduces product development costs, and improves customer satisfaction. The steps of identifying, simplifying, controlling and monitoring interfaces help to reduce the risk of problems related to interfaces.

i. Modeling: In the words of Alhir, “To solve a problem, appropriate knowledge about the problem and solution (architectural views), and depicted (diagrammed) using some language that enables it to be communicated and leveraged in the problem-solving process”. A model therefore, is a representation of reality or level of abstraction that is intended to facilitate understanding. The use of prototypes and models helps eliminate ambiguities and inconsistencies and are correlated with the most successful projects.

j. Performance and capability analysis: Stakeholders emphasis that concentrating on system functions and data results in a lack of attention to the total system requirements and often results in incomplete performance, capacity and external interface requirements. Thus it is vital to ensure that the requirements gathering process provides coverage for all requirements.

- Sujatha Das