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.Â
In what follows, I’ll share my top 5 elicitation techniques that can help you get started on just about any type of project.
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.
As you are using a structured interview, it’s really important that you actively engage your stakeholders. Here are a few of my top tips for building stakeholder engagement.
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.
Knowing What Questions to Ask
Part of being strong at any elicitation technique is knowing what questions to ask. Here’s the next video I recommend to help you cultivate this skill set.
For requirements discovery, I like to use structured and facilitated requirements workshops that, as part of the workshops activities, use other elicitation techniques in small groups, such as brainstorming, paper/whiteboard prototyping, “focus groups” – specific focused discussions in small groups. I will also use light versions of some analysis techniques as facilitated activities, like Decision Analysis to aid in initial high level prioritization of requirements elicited in the workshop. For the most part, my workshops are at most a half day with “non-critical” business personnel, and 1-3 hours with the more senior personnel. This timing creates more pressure on the BA and facilitator to have a very pointed workshop, and does require follow-up, but also builds better relationships with business stakeholders, i believe, because for most of them, time is money!
Thanks for referencing Requirements by Collaboration 😉 [http://www.ebgconsulting.com/Pubs/reqtcoll.php]
The length and timing of workshops varies by project and should always to be adapted to project, product and team circumstances.
Sometimes you have contiguous multi-day events as i provided examples of in chapter 11 (and which go by different names, David W above refers to them as “discovery” workshop).
In other cases, these collaborative events are shorter, done in spurts, are more informal, and are interspersed (and should be!) by other requirements elicitation and validation activities such as prototyping (both low-fidelity and high-fidelity), user acceptance testing a small chunk of working software, scenario walkthroughs, and more.
Adapt the workshop principles and practices. The key is the attend to the ingredients for success and “6 P’s (purpose, participants, principles, products, place, and process).
~ ellen
@Laura Thanks, I would also put forth that while we may have preferred methods based on past experience. We should strive to be adaptable to each client. While I have a strong preference for my methodogy, I do not always use it. I think the right technique is unique to the client. Each client reacts to the requirements process differently based on corporate culture and personal learning styles. Being adaptable in you solicitation skills is a win for all involved. I am of the personal belief that an effective BA is part psyco-analyst, part visionary and part improv actor. While that is a more anecdotal view, it has quite a bit of substance to the breadth of skills necessary for a BA to be ultimately successful.
Here here!
Wow, what a significant diversity of techniques and activities is listed here. Of course, they all come back to having productive conversations with our stakeholders about their needs or, at times, their explicit requirements.
@Ian, I really like the “tell me a story” style of questioning. It’s something I’ve turned to often as well, but never directly called it out as a technique. I think we’d do well to flesh that one our more as a profession. And I definitely don’t think it’s usefulness is limited to project where requirements are specified in user stories. I’ve used it for use case development and to gather requirements-related information that ended up being captured in other forms of specifications. That’s the beauty of elicitation, IMHO, when done independently from analysis it does not have to be tied to your choices to analyzing, modeling, or specifying requirements.
I suppose what I’ve gathered so far from the comments is that different BAs have different favorite techniques because of what they’ve seen work effectively in their past project work. That’s definitely been my personal experience – it’s hard to let go of your workhorse and try something new that might not work as well! Would you agree? And, if so, does this limit the possibilities you consider on a project?
As I stated in my tweet, I am a huge fan of having the client tell me a story of a day in the life of a user. I work with a company who provides COTS solutions to large companies. Frequently, I have found that our clients have Limited experience, if any at all, with true requirements solicitation. They are not sure where to start and have a high portion of implicit requirements due to the age of the systems currently in use. The “tell me a story” style, while not an official BABOK technique, allows the client to explain in their terms what the user experience is. It ensures that the BA must listen carefully and ask leading questions, when necessary. It has the tremendous effect of getting the client to recognize aspects of there process that may not have revealed themselves until much later in the process because solitication is happening naturally. I have found that at the beginning of any major requirements gathering process there is a great deal of pressure to get it all right and documented. This leads to clients relying heavily on the analyst to ask all the right questions, which is virtually impossible and can lead to missed areas. The “tell me a story” process ensures that the analyst will, at a high level, get a full picture of the system/process. It also has the added benefit of being greatly helpful to the creation of the user stories.
Yes, totally agreed. Generally I find “tell me a story” information gathering is effective and use it often in situation where I need to work with the challenging clients – those that uninterested to participate, sceptical etc. So far, I have not found a client that will not want to talk – yes, I may need to be persistent for a few attempts. Often, at the end of the meeting, I got more than the information I need – it is also effective to built good connection with my challenging clients.
Let me clarify – I use this method as the last resource to help clients to overcome their resistance issue as I find this is time consuming way of information gathering. I would have to do significantly more preparation before I enter the meeting to ensure good control of the meeting and minimising detour while engaging client through the free flow conversation.
Does anyone find a better way to work with the highly resistant users?
What worked for me in different companies and had the best results were:
– Group process walkthroughs with stakeholders (up to 8 people; if more – group management becomes difficult) to discuss and discover busness process requirements
– Individual interviews
– Prototyping walkthroughs (paper or Balsamiq simple prototypes)
I have found that getting certain information upfront during elicitation can make a big difference in getting the requirements and design right later. Most of these topics are covered in the BABOK and other BOK’s, but I look for this information first from known stakeholders.
1. Where did this requirement(s) come from? Is it a new approach to an existing problem or function, or a new problem or business venture? Is there a new department or person driving this need? How long has the need been known?
2. What tools/techniques/processes are in place now to handle this or similar requirements? Are they working well? What general improvements/changes are needed?
3. What benefits/payback/ROI will you or others see from satisfying this requirement(s)? What is the time frame in which you expect to see these benefits?
This answers the questions “Where have we been?”, Where are we going?”, and “What do we expect when we get there?”. This information helps reveal expectations, existing systems, additional stakeholders, and priorities upfront, and gives invaluable perspective on the requirements.
Workshop for Requirements Discovery. The kind I am involved in are typically 5 days, Monday to Friday. Six hours each day with SMEs, with Facilitator and Documenter, 2 hours a day to ensure the day was captured. Friday is actually for review, so that by end of week the SMEs/Managers will have a document in hand that belongs to them, because their input created it.
The most effective method I have used to drive out the best requirements is through prototyping (or CRP – conference room pilot). The stakeholders can actually see what a system can do. The caution here is that you must ensure that the requirement are driving the design and not the other way around.
My favorite method is a combination of interviews and requirements workshops. I have tried the survey method but not had a great deal of response from the stakeholders in the company.
I love learning about ‘how much skin’ each stakeholder has in the game in a one on one interview. I also enjoy the synergy in the room during requirements workshops.
It depends on situation. Sometimes I use User Story Mapping to figure out the big picture.