Techniques for eliciting requirements

Requirements elicitation also known as requirement gathering is a crucial phase in developing any software. It is an activity that aids project management in understanding how complex the development initiative is.

The gathering of the business requirements is done by constant communication ( via questionnaires and interviews) with the business stakeholders along with research activities.

These planned activities are done by a Business analyst and Project Manager

Elicitation tasks

• Prepare for elicitation
• Conduct requirement gathering
• Analyzing gathered information

1. Prepare for elicitation:

This step involves researching the project and preparing interview questions. Once a body of work is generated- the analyst follows up with the stakeholders

2. Conduct requirement gathering:

In this step, an analyst holds frequent interviews with stakeholders and understands the complexities of the software that is about to be developed. This step allows the analyst to explore and identify features and modules of the project

3. Analyzing gathered information:

This step is a crucial step where the analyst shifts through the gathered information and verifies it for accuracy. Any discrepancy is followed up with more questions and interviews. There are several methods of gathering requirements, however, the techniques may vary depending on the complexity of a project.

Explained below are commonly used techniques.

• Stakeholder identification
• Interview
• Questionnaires
• Document Research
• Process mapping
• Observation
• Prototyping
• Requirement sessions

1. Stakeholder identification:

This step includes understanding who the business users are. This information is crucial in understanding user’s needs and their behaviour. Information gathered in this stage can be used by UI/UX team to understand demographic needs and user types

2. Interview:

This is one of the easiest and the most common techniques of requirements gathering. In this step, an analyst asks prepared questions to the stakeholders to gather information. Interviews can either be formal or structured and informal or unstructured. This simple technique is useful in encouraging participation and build ongoing communications with the stakeholder.

3. Questionnaires:

This is a simple yet effective way of gathering requirements and removing any guesswork from the answers. The analyst compiles direct and non-ambiguous questions. Once a finite set of questions are ready, the analyst notifies the participants and allocates them a set timeline to respond by. Questions can be either open-ended ones, giving the participants the freedom to respond in their own words or they could be close-ended - with predefined responses.

Responses to Open-ended questions take a longer time to analyze since the interpretation of answers takes a longer time.

Responses to closed-ended questions can be analyzed quickly as predefined responses have been vetted out carefully

4. Document Research:

This research is helpful in understanding the current market scenario in reference to the business needs. This research phase includes understanding the business plans, existing problems, etc. This technique is useful in cases of migration information or updating an existing project.

The findings in this stage can be used to map the current baseline / AS-IS state and the future / TO-BE state.

5. Process mapping:

This is used to review systems, users, and processes happening within a system. A diagram is drawn using common nomenclature and subsequently, processes are mapped. This helps in identifying how information is exchanged between different components or users in the system.

6. Observation:

This method aims at understanding the activity or task that a user undertakes. This method includes the observer observing and record all the activities and the time is taken to perform a work process. Active observation includes the observer asking questions while the user is performing a task Passive observation means the observer is silently observing the user perform their tasks without making any attempts to interpret the actions This method works extensively for mapping shop-floor activities. Knowledge-based tasks cannot be extensively mapped using this technique

7. Prototyping:

In this technique, frequent interactive demonstrations are made for the client. This visual representation - allows the stakeholders to visualize how the product will look and function. This step involves creating mock-up of products or sites and using process diagrams to explain individual mockups. This method is popular in designing software as feedback from the stakeholders can be gathered immediately. The downside to this technique is that creating the demos can be rather time-consuming and stakeholders tend to focus on the design specs rather than requirements for the product.

8. Requirement sessions:

This step is a lot more process-oriented rather than product-oriented. This structured approach involves frequent long meetings where the main focus is on stakeholders across the organizations coming together to provide their views on the solution. The advantage of this approach is that one can get conflicting requirements resolved immediately on the spot. The documentation from this step can be completed in a shorter time. The consensus amongst a diverse group of users can be achieved easily. The downside of this technique is that stakeholder’s availability might be a cumbersome issue to manage and the success of such sessions lies in the deft hands of the person facilitating such meetings.

Conclusion

Of the Techniques available for gathering requirements, there is no single technique that can resolve it all for you. A deft Business analyst can help in this scenario in understanding the complexity of your problem and picking up specific techniques customized for your needs. Let us know your views about this article. Talk to us, we will be happy to assist you with your development needs.