Elicitation Techniques Used By Business Analysts

Elicitation is one of those areas of business analysis that is both extremely simple and extremely complex.

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.

The Elicitation Techniques

Here is a list of the primary elicitation techniques used by business analysts:

  • Brainstorming – Free-form discussion to generate new ideas and solutions.
  • Document Analysis – Analyzing existing documentation to understand potential requirements.
  • Focus Groups – Facilitating small group discussions about a product or service, often used to get feedback from stakeholders external to your organization.
  • Interface Analysis – Analyzing the interface between systems, or between the user and a system, to understand the current state requirements or future state requirements to enable an integration.
  • Interviews – Conversations focused on asking specific requirements questions of an individual or group of stakeholders.
  • Observation – Observing a stakeholder completing a business process, or job function, to understand the details of that process.
  • Prototyping – Creating a visual representation of a possible solution to review with stakeholders, and elicit either confirmation or new ideas about the requirements.
  • Requirements Workshops – A more formal and highly structured meeting, typically of longer duration (at least a half day, and could span several days) designed to discover, analyze, and validate requirements documentation.
  • Survey/Questionnaire – A request for structured or unstructured feedback in the form of answers to specific questions. Useful to gather information from a large number of stakeholders and discover information about the potential impact of a decision.

Many new BAs feel they should be using all of the techniques and are worried they aren’t getting elicitation right. Or, they think about their experience in this area and it seems that most of the time they get information about stakeholder needs through casual conversations and reviews, so their experience with elicitation seems a bit informal.

This is an area of business analysis that it’s very common for professionals to have relevant experience in. It’s also an area where even the most senior business analysts never stop improving.

Let’s look at another reason that the techniques of elicitation can seem complex.

Most BAs Use a Combination of Elicitation Techniques

Once you start digging into each technique, you realize that it’s actually quite difficult to do as a stand-alone activity. For example, brainstorming often happens as part of a requirements workshop which can have an interview component as well. Or, in order to prepare for an interview, you need to do some document analysis first to come up with a list of questions. Or, in order to get your interviewees to give you good information, they need to see a prototype.

The elicitation techniques can be combined any which way to achieve the result you want out of their project. (And we won’t even get to selecting elicitation techniques from outside of business analysis, which is another way to further broaden your BA skill set.)

But Elicitation is Not About Using All the Techniques

Elicitation is not really about piling as many techniques on top of one another as possible. It’s about discovering the real needs behind the project.

Upon doing a deep dive into the elicitation techniques as part of preparing for my CBAP, I realized that my most common approach is a special blend of an interview and a requirements workshop.

I had always assumed a Requirements Workshop was the kind described by Ellen Gottesdiener in Requirements by Collaboration – a full day meeting in which participants collaborate together on requirements deliverables.

After reading the BABOK‘s description of a requirements workshop, I discovered while the time frame of 1-2 days is referenced, the creation of deliverables is not. In the general way the technique is described, it could include collaborative creation of deliverables. But it could also include group dialog, around a set of requirements, which are captured by a scribe, and then put together after-the-fact by a BA.

This is the type of meeting I typically facilitate.

Still, the BABOK specifically says these meetings typically last 1-2 days and mine typically last 1-2 hours. So I’d venture to say that the type of elicitation meeting I typically run is 2/3 requirements workshop and 1/3 interviews, a technique which can include interviewing more than one person.

Is this an elicitation technique you’d feel comfortable handling? Are you interested in learning more?

Elicitation can be complex. It can also be simple. And because of the people-factor in elicitation, there are always ways to improve your elicitation skills.

>>Get Your 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.

Click here to download a free sample checklist

12 thoughts on “Elicitation Techniques Used By Business Analysts”

  1. 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!

  2. 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

  3. @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.

  4. 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?

  5. 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.

    1. 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?

  6. 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)

  7. 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.

  8. 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.

  9. Michelle Swoboda

    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.

Sign up for weekly updates and access to the FREE Quick Start to Success workshop:

Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)

Laura Brandenburg

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.

Scroll to Top