In the world of Business Analysis, the value of elicitation cannot be underestimated. Elicitation is the process by which Business Analysts gather requirements from their stakeholders. While this is often done in an ad hoc manner, it does not need to be. According to the International Institute of Business Analysis (IIBA), there are four discreet steps that can be followed to effectively elicit requirements. IIBA calls these steps, “Tasks.”
The first task is “Prepare for Elicitation.” Think of this task as the planning step in the elicitation efforts. During this step, a Business Analysts needs to figure out all of the things that need to be done in an elicitation session–before the session actually happens. For example, the Business Analyst needs to have a thorough understanding of the Business Need, the Business Case, the Solution Scope, and the Stakeholders. With that in mind, the Business Analyst needs to select the best technique(s) to use for the elicitation session. Some common techniques include Brainstorming, Focus Groups, Interviews, Observation, Requirements Workshops, and Surveys/Questionnaires. (Please keep in mind that each of these elicitation techniques has its own unique preparation requirements, too!) At the end of the preparation, the Business Analyst should have two things: First, all of the resources (think of the people, places, and things) that are necessary for the elicitation activity should be scheduled. Second, all of the supporting materials (think of whiteboards, flip charts, etc.) should be collected.
The second task is “Conduct Elicitation Activity.” This is when the Business Analyst actually has the elicitation session with the stakeholders. This could be a brainstorming session, a focus group, etc. (Again, please keep in mind that each elicitation techniques has its own unique way of being conducted, too!) During the session, the Business Analyst (or an assigned Scribe) needs to document all of the requirements that come up. Oftentimes, there are attributes (e.g., the source, the risks, the priority, etc.) that also need to be documented with the requirements, and traceability should be considered for each requirement. At the end of the session, the Business Analyst should have a good collection of requirements as the result of the activity.
The third task is the lonely task: “Document Elicitation Results.” During this task, the Business Analyst goes back to work independently on bringing order to chaos. At the end of the elicitation session, the Business Analyst leaves with quite a collection of notes, whiteboards, flip charts, video/audio recordings, etc. All of this content needs to be transferred to a better format. Ultimately, the Business Analyst should start documenting the requirements in a format that will be easy for the solution designers to understand. Upon conclusion of this task, the Business Analyst will have two things: First, all the requirements should be in a format that can be easily understood. Second, if any concerns came up during the elicitation sessions, those should also be documented in a problem tracking database or in an issue log.
The final task is, sadly, often skipped. The Business Analyst must go back to the stakeholders and “Confirm Elicitation Results.” During this task, the Business Analysts needs to ask the stakeholders if the requirements have been accurately represented. This is a very important step in the elicitation process because it ensures that each requirement is represented as the stakeholder wanted. Once the Business Analyst has this confirmation, the requirements are considered “confirmed.” This enables the Business Analyst to move on to additional analysis of the requirements (e.g., prioritization, organization, modeling, verification, validation, etc.).
Now that we have an understanding of the four-step process, we should be able to do a much better job in our elicitation efforts. In upcoming blog entries, we’ll go over the techniques that we can use for elicitation.