In my years as a Business Analyst, one of the key tasks I performed regularly on any new or existing project was to elicit and document requirements. The actual process of eliciting, validating, prioritising and documenting a requirement is known as requirement engineering; it is structured, analytical and technical, it also involves a lot of work. The starting point for any requirement engineering process is usually described as the requirement discovery phase.
What is requirement discovery?
As mentioned above, requirement discovery is the first stage in a requirement engineering process. It is a procedure used by Business Analyst, project managers and transformation consultant to uncover the business objectives, and then mapping the objectives to the high-level requirement statements. At the discovery stage, the job of the Business Analyst is to identify the core reason for embarking on the project, uncover any difference of opinion amongst the stakeholders and ensure the stakeholder's expectation are all aligned.
The Business Analyst will usually organise and facilitate a requirement discovery workshop, so as to get the most from all the stakeholders. The requirement discovery is in most cases a precursor to the other requirement engineering activities. If the discovery process is carried out correctly, the Business Analyst will have a better chance of eliciting correct requirements further down the line and getting the requirements approved. Below are five ways that a Business Analyst can carry out a requirement discovery session; the good news is that these methods can also be used during a requirement deep dive (more on that in later blogs):
The Five why
The five why is also known in some sector as the root cause. The premise of the five why is that when you ask "why" up to five times, you arrive at the core (or root cause) of the issue at hand. In some cases, you do not need to ask why five times, because you can hit the core of the issue after the third why. However, by asking why, you start to peel the layer off the symptoms and drill into the main drivers. It is important to be able to drill into the real reason at the early stages of eliciting requirement so as to prevent the entire project from going astray further down the line. Using the five why will also help to remove the itchy feeling of wanting to solutionise before understanding the real issue we are trying to solve.
Interviews
Interviews allow the Business Analyst to ask the stakeholders different types of questions, to further understand how the project will align with the business objectives. A Business Analyst will usually come prepared with a series of questions, using different techniques. The techniques will include asking open-ended questions, closed-ended questions and leading questions. A good Business Analyst will come with a series of questions; however, they will usually allow the conversations or answers to drive the interview and only refer to the questions if they need to fill in the gaps or ensure nothing has been left out.
Use Cases
The Business Analyst can rely on "use cases" at the discovery stage to get a better understanding of how the users will interact with the system in a technical environment. The Business Analyst will use graphical annotations or symbols to describe the system boundaries and the types of interactions that will exist within the boundaries. The use case diagram is also a good tool to scope out a project at a later stage.
Scenarios & What ifs
A good tool that Business Analysts can use to draw out more high-level requirement from stakeholders is the scenario probing or asking what-if questions. This tool helps the stakeholder to describe different scenarios that could exist or be impacted by the project. This is also similar to asking the what-if questions; a Business Analyst will use the what-if question to understand exceptions or alternative courses of action based on a described scenario.
Brainstorming
Brainstorming is a very common technique that can be used during the discovery and deep dive stages. Brainstorming when used during the discovery stage can help uncover all the ideas that each stakeholder may have about the project. By identifying the ideas provided by each of the stakeholders, the Business Analyst is also able to see common views, problem areas, overlapping views and different views. The Business Analyst is able to utilise the output from a discovery brainstorming session to identify the high-level requirements, requirements that are not aligned with the business objectives and ambiguous requirements.
Eliciting requirement at the discovery stage is usually a difficult task and this is because most stakeholders do not really know the full details of what they want to achieve. They have an idea of what the outcome may look like, but it is often difficult to explain, especially if it’s a transformational project. It is not uncommon to have stakeholders give unrealistic requirement at this stage, which will prompt the Business Analyst to arrange further requirement workshops, hold face-to-face interviews and carry out further analysis work. The Business Analyst should also be able to use the requirement discovery session to identify the different stakeholders and their roles in the project, so as to prevent difficulties down the line.
To learn all about the tips and tricks on how to plan an effective requirement discovery session, check out “The Business Analyst’s Playbook”. This online course aims to help you hit the ground running on any project as a Business Analyst. The course contains a proven process that hundreds of Business Analysts have used to successfully complete projects in some of the top organisations in the UK and around the world.
Comments