Requirement Elicitation Techniques for Business Analyst

Requirement elicitation is one of the primary responsibilities of business analysts. Business analyst are required to deep into the customer’s requirement and provide solutions which are used to develop systems and satisfy customer’s system requirements.

Traditionally, requirement elicitation process was called requirement gathering and is still often addressed as requirement gathering but as a business analyst, you not just gathering requirements, you are eliciting them.

Requirement elicitation forms the backbone of business analysis and it is vital to create systems which satisfy the customer needs.

I have listed here the prescribed requirement elicitation techniques which are either used alone or with other techniques.

Requirement Elicitation Techniques

Brainstorming– in brainstorming requirement elicitation, you need to form a team of the entire stakeholder with at least one representative from each team. This team will brainstorm the new ideas. Ideally business analyst should facilitate these brainstorming session and ensure that brainstorming sessions remain focused and doesn’t lose track. When there are stakeholders from different, they tend to get lost and may suggest things which are outside the purview of your current project. Brainstorming can produce great ideas and suggestion. You should be ready to log these relevant ideas and suggestions.

Document Analysis – document analysis is a very useful requirement elicitation technique which is widely used in information technology. This technique is especially good when you are making change to an existing system like a change request or enhancement. Document analysis involves analyzing all the existing documentation related to a system or process.

Focus group – focus group consist of pre-qualified individuals who represent the concerned stakeholders. This is done when stakeholders may not have enough knowledge/data/information about the expected change in system. But despite that business analyst is required to interview senior members from stakeholder group to get in-depth information related to the system or process.

Interface analysis – interface analysis involve analyzing all kind of interfaces involved in the concern process. Idea behind this analysis is to deconstruct the way a user is going to interact with a system and the way system will interact with linked systems. This provides great information when you are making changes to a existing system. You can use this technique for studying the existing system and to demonstrate to the end users.

Interviews – interviews are great way of requirement elicitation. Interviews help in understanding the requirement given by users and to further enhance the clarity by asking relevant questions in requirement elicitation interviews. It is one of the widely used requirement elicitation technique in business analysis. A business analyst should not only discuss the asked changes but also the related scenarios in order to better understand the change and cover anything which may not be addressed at the broad level requirement description. Interviews are also great way of explaining changes to users because then by the nature of discussion you can inform users about any negative changes or additional change which may impact the overall functionality. It has been observed that end users sometime miss the hind side of the requirement which may produce undesirable effects.

Observation – observation is used in projects which require changes in the current system or process. There are two types of observation requirement gathering techniques. One is passive where business analyst simply watches the end user work and gathers data and the second type is active, where business analyst elicits requirements by asking relevant question while end user works. It helps in better understanding of the current processes.

Prototyping – a picture tells a thousands words. Prototyping work on these principal, End users may not fully understand the technical or business documentation. Diagrams depicting change in user interface or work flow diagram help them in understanding changes which may occur. Prototyping use pictures and diagrams to explain changes. It require walk through of the diagrams and make changes based upon the feedback received from stakeholders.

Requirement workshop – requirement workshop involve team discussion to identity and refine requirements. It includes a group which meet consistently to discuss changes and identity changes which are required to satisfy the business goals. Each activity and input must be recorded during these requirement workshops. You may use some tool to do that logging or simply meeting minutes may help based upon the nature of your requirement workshop.

Survey/Questionnaire – these are used for gathering information from large group of users. There is drawback of no personal interaction but when the size of group is high, surveys or questionnaire are extremely helpful in identifying and eliciting requirements. You may also use this method in initial stage to gather information about a system changes from the entire team of affected users and later on, refine the requirements by using alternative requirement elicitation techniques.

Conclusion

Requirement elicitation is a complex process in the current IT environment. It is often seen that on ground more than one technique are deployed to efficiently process of requirement elicitation or gathering.

Please share your feedback and experience on requirement elicitation with us.