Simply put, elicitation is the process of discovering the requirements. In particular, elicitation often refers to engaging with stakeholders to understand their needs and expectations when it comes to the scope and detailed requirements of the project.
There are many requirements elicitation techniques.
When many BAs think of elicitation, they think of big complex, full day workshops.
In most cases, elicitation happens in much smaller sessions involving just a few stakeholders.
My Top 5 Requirements Elicitation Techniques
Hi, my name is Laura Brandenburg from Bridging the Gap. And today we’re going talk all about the requirements, elicitation techniques that are used by business analysts. I’m going a give you my five top requirements elicitation techniques, as well as a free checklist that you can download to help you get started right away.
When we think of requirements elicitation, most business analysts think of big, complex, full day workshops. Big events. The reality is in most cases, requirements elicitation happens in much smaller sessions and also techniques that don’t even involve stakeholder interaction at all. But those smaller sessions can involve just a few stakeholders. Let’s just take a step back and talk about what is requirements elicitation.
Simply put, elicitation is the process of discovering information that allows you to put together the requirements or draft and analyze the requirements. In particular, elicitation will often refer to engaging with stakeholders in some way to understand their needs and expectations when it comes to the scope and the detailed requirements of a project.
As I mentioned, there are techniques that do not explicitly involve stakeholder interaction. I’m going give you one of those in my top five as well. So let’s talk about these five requirement elicitation techniques.
Requirements Elicitation Technique #1 – Observation
Number one is observation. This is when you’re sitting with a user, or via screen share in a virtual environment, and you watch them do their work, or you have them demonstrate doing their work in a hypothetical way, like this is what I would do if I was processing a new account or processing an order or completing a refund.
There’s a distinction here in user experience circles. There’s sometimes a preference towards pure observation where the stakeholder doesn’t say anything that they would not say in their normal course of doing work and you as the business analyst don’t ask any questions, or for any clarifications. That is to achieve a different objective around really understanding the stakeholders full environment.
As a business analyst, we often will ask questions. We’ll have the stakeholder articulate what they’re thinking, why they’re doing what they’re doing, share the business logic, and we will ask those questions to really clarify the logic as well as alternative scenarios. If it looked like that one worked, what if we had clicked something else here, or if you didn’t receive that document. You start to ask questions so that you’re getting not just the stream of work for that particular instance, but for a broad range of instances.
Requirements Elicitation Technique #2 – Diagram Review / Walk-Through
The second requirement elicitation technique I want to share with you is to do a diagram review or a walkthrough. This could also be called prototyping. This is a great way to elicit unexpected information and to use the structure of a requirements model, like a workflow diagram, or a use case, or a wireframe or an entity relationship diagram, and to use that structure, to help collectively fill in that model which often leads to unexpected information surfacing.
You could start with a draft model. If it’s an entity relationship diagram, you could have a few key concepts drawn on the whiteboard or print it out in a sheet or up on a shared screen if you’re doing a sheet screen share. If you’re doing a wireframe, you could have kind of a skeleton with some navigation and some pieces in place. Or you could start with a blank page. It really depends on your stakeholder group and how adept they are at using that model. You could also start with a fairly finished draft of that model and walk through it piece by piece to get input and feedback from your stakeholder. All different ways to do walkthroughs and use the prototyping technique with different stakeholder groups.
Requirements Elicitation Technique #3 – Structured Interview
Now, the third technique I want to share with you is called a structured interview. This is by far the most common technique that business analysts use. It’s usually with either one or a small group of stakeholders in a meeting. It could be an in-person meeting, or it could be a virtual meeting. You want to be prepared for that kind of meeting with an agenda. You want a meeting agenda, and you want a requirements checklist. You want to know what questions you are going to ask. You might share that with your stakeholders ahead of time if you think they would benefit from doing some preparation. Some stakeholders are much better if you’re asking those questions on the fly and you don’t overwhelm them ahead of time with all the questions that you might have to ask.
You can download a sample requirements checklist absolutely for free. I really invite you to check that out as a way to start thinking through what questions would you ask in an interview. Of course, that checklist is for a specific type of requirement, so you want to be clear of what objective you are trying to accomplish in that meeting and what questions do you need to ask in order to discover the information to achieve that objective.
Requirements Elicitation Technique #4 – Documentation Review
I promised you one technique that did not involve stakeholder interaction, and that is our next technique. It’s called documentation review.
This is a requirement elicitation technique where you can discover a lot of information by analyzing any existing documentation to understand potential requirements. This can save a lot of stakeholder time. If your stakeholder time and your access to stakeholders is at a premium, you definitely want to prioritize what documentation you can review ahead of time so that you can be really prepared. It can help you come up with those questions for your structured interview or drafted diagram that you can use, or make your observation more clear as well, or more pointed and specific.
A big caveat on this is that as the business analyst, you don’t want to over invest in documentation reviews or make assumptions. You don’t want to use documentation that could be dated, might not reflect your actual stakeholder perspective to just decide what the requirements are. Often you need to come back to the stakeholders and validate the information that you’ve used or use it to develop, as I mentioned, the requirements checklist, the discovery checklist that will allow you to have a very productive, structured interview to ask those questions.
Requirements Elicitation Technique #5 – Survey or Questionnaire
Now, the fifth and final technique that is sort of a blend of stakeholder interaction, and that is to do a survey or a questionnaire. This is a great way to get information from a lot of people or from people with whom you don’t have a direct connection.
A survey is also a great way to receive more objective information in a low intensity way. Often people will write things into surveys that they may not share personally. On the flip side, sometimes the information is unclear and difficult to interpret without more context. We use surveys here at Bridging The Gap to gather feedback from potential customers and also to get feedback from our course participants after they complete the program.
Most BAs Use a Combination of Elicitation Techniques
You really want to be well adept at multiple techniques so that you can pick and choose what technique is going to work in your specific situation.
And again, if you want a quick way to get started, I invite you to download our free requirements checklist. It’s for a specific domain or specific area of requirements called supporting a customer. And then it will help you get started right away in just thinking through what questions to ask. Even if that’s not the area that you’re working on, just seeing the questions that are available and reinterpreting them for your specific situation is really going to help you get started in figuring out what questions to ask, which is often where business analysts get stuck in the first place.
I’d love to hear in the comments below what requirements elicitation techniques you use as a business analyst, where you want to improve on, and how you are finding that checklist, and how it’s helping you in your business analysis career.
Until next time, I’m Laura Brandenburg from Bridging the Gap. We build our profession one business analyst at a time, and success starts with you. Thanks for being here.
>>Get Your Requirements Free Checklist
Looking to improve your elicitation? Discover exactly what a sample requirements checklist looks like, with one sample from our Requirements Discovery Checklist Pack, which includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.