Requirement elicitation for a Business Analyst.

Introduction: Requirement elicitation is a process of gathering valuable information from the stakeholders based on the business needs. It is the foundation of successful projects as it lays clear expectations of the project. When the requirements are elicited correctly, the same can be conveyed to the developers and a good software can be produced. The role of a business analyst is to act as a lesion between the technical team and the business stakeholders. Why elicitation matters? If we get the requirements wrong then we have to repeat building the features, that will lead to waste of resources and loss of time. It will unnecessarily delay the project and cause budget overruns. On the other side if we elicit the requirements from the stakeholder correctly without any misinterpretation then we can have clarity of what the stakeholder needs and we will have reduced rework so we can utilize the resources effectively and finish the project within the budget. Key techniques Brainstorming: brainstorming is the process of generating ideas in early discovery. Brainstorming elicitation technique can be done either individually or in groups. The ideas collected can then be reviewed, analyzed where relevant included within the system requirements. Ideas can come from what stakeholders have seen. Workshop: Workshop can contain 6 to 10 members working together to identify requirements. Workshops tend to be of a defined duration, rather than outcome and may need to be briefly repeated in order to clarify or obtain further details. Surveys: Survey can be useful to collect limited system requirements details from users who have a input or who are geographically remote. The design of the survey can be either off line or web based. The survey can be sent to hundreds of users at a very low cost. Good for getting input from users who are situated in long distance. Observation: It is also known as shadowing users. It is the process of observing the user or even doing a part of their job. There are two types of observation active observation and passive observation. Passive observation is just shadowing and active observation is also means doing a part of the user’s job. Prototyping: Prototyping is the process of using mock-ups to help stakeholders visualize. It helps stakeholders visualize how the system will look before it is even built. No single technique works for all situation so we need to come elicitation techniques based on the situation. Experts generally recommend blending techniques for completeness. We need to be a good listener and ask open ended questions. We need to map the stakeholders based on who decides, who uses and who influences. After elicitation of requirements, we will validate the requirements and ask for feedbacks to confirm accuracy. For a BA elicitation of requirements is a very important task. This is where the work of a BA starts, with out requirements we can’t build features. Even if we build features, it will not be useful if it doesn’t fulfil business needs. The above discussed elicitation techniques like workshop, observation are very useful to gather requirements from the stakeholders. Adapting best practices like active listening and asking ended questions will help in gathering requirements in a better way. To put it in simple words elicitation is not just gathering requirements, it’s building understanding and trust.