Monday, 14 May 2012 04:00

Methods for Eliciting - Not Gathering - Requirements

Written by
Rate this item
(32 votes)

methods-for-elicitingThe word "gather" does not truly communicate the nature of the Business Analyst's (BA) job. You do not gather requirements-they are not just lying around on the ground waiting to be picked up.

The word "elicit" more closely matches the job, because it connotes a more active role for both the BA and for those with whom the BA works. The dictionary defines elicit as:

  1. To draw forth or bring out (something latent or potential)
  2. To call forth or draw out (as information or a response)

There are many ways to elicit requirements from your stakeholders. A BA should be proficient in all of these: interviews, workshops, focus groups, brainstorming, observation, and surveys/questionnaires. While all of these methods involve three basic parts: preparation, conducting, and follow-up, they do have differences.


Interviews, either with an individual or with a group of people, offer the opportunity for rich, detailed communication.


  • Define interview goal: Determine exactly why you are holding the interview and what you want to achieve in it.
  • Select participants: Decide who needs to be involved in the interview in order to achieve that goal.
  • Determine logistics: When and where will the interview be held, and how will the interviewees be invited?
  • Design the interview: Decide on the format that is most appropriate for the interviewees and the goal. Should it be structured with a detailed agenda and formal set of questions, or unstructured with a looser agenda, depending more on ad hoc interaction? Should the questions be open-ended requiring sentences or paragraphs to answer, or closed-ended requiring short, even one-word answers?

Conduct the Interview

Take time at the beginning to ensure that the interviewee(s) knows the purpose of the interview, who you are, and what your role is. Wrap up the interview with questions like "Is there anything else you would like to add?" and a hearty "Thank you!"

Follow up

Like any other meeting, interview minutes should be published. This allows the interviewees to see what you learned in the interview and validate that what you heard is what they intended to say.


A workshop is a structured method for interacting with a group of people. Workshops can generate much information quickly if well facilitated and if participants are active.

Prepare for Workshop

  • Define purpose: Determine exactly why you are holding the workshop and what you want to achieve in it.
  • Select participants: Decide who needs to participate in the workshop in order to achieve that purpose. Make sure to consider the personality types involved and ensure that you'll get participation from the entire group, not just a few dominant people.
  • Determine logistics: When and where will the workshop be held, and how will the participants be invited?
  • Conduct preliminary interviews: Some workshop methods include collecting some information from the participants before the workshop to provide a starting point. Such methods provide specific guidance about what preliminary information should be collected.

Conduct the Workshop

Be sure to accurately capture all of the information that the workshop produces. Depending on the size of the group, you may want to assign a record-keeper so you can focus on facilitation

Follow up

Some types of workshops result in the assignment of action items to the facilitator or participants, in which case, they must be managed to closure. The workshop results should be published so the participants and other interested parties can see what you learned in the workshop.

Focus Groups

A focus group is an interactive session with a carefully selected group of people designed to capitalize on the synergy of a group.

Prepare for the Focus Group

  • Select participants: Decide who needs to participate in the focus group in order to achieve its purpose.
  • Define roles, topics, and logistics: Define who (among the people running the focus group) must do what, and the specific topics that the participants will discuss. Also define the basic logistics such as when and where the focus group will be held, and how the participants will be invited.

Run the Focus Group

Carefully facilitate the group to ensure free and open interaction among the participants. Participants must feel free to interact openly or the focus group could fail.

Follow up

The focus group report records what was learned, including both agreements and disagreements among the participants.


Brainstorming is a method of quickly generating many creative ideas from a group of people.

Prepare for Brainstorming

  • Define topics and time limits: Define precisely what will be the focus of the brainstorming session, and how long it will be allowed to go on.
  • Select participants: Decide who needs to participate in the brainstorming session in order to achieve its purpose.
  • Determine evaluation criteria: Decide how the ideas that come out of the brainstorming session will be judged afterward. Be sure that the evaluation does not go on during the brainstorming session.

Conduct Brainstorming

Encourage a free flow of ideas. This requires careful facilitation to ensure that participants feel comfortable with adding any idea to the list, and that no criticism or even discussion of the ideas goes on during the brainstorming session.

Follow up

Apply the evaluation criteria to the ideas that were generated to reduce the list to only those ideas that are reasonable or viable.


Observation is watching people as they go about their jobs. Observation can be an effective way to gain a realistic and detailed understanding of how work is done in the production environment; however, it is time consuming and may disrupt work.

Prepare for Observation

  • Define goals and individuals to be observed: Decide what you are trying to accomplish in the observation and who you should observe in order to achieve those goals
  • Decide on mode: Observation may be done in either of two ways:
    • Passive/invisible: Observing in a way that does not disturb the workers. "Invisible" refers to the fact that the workers are not even aware that observation is taking place.
    • Active/visible: Interacting with those who are being observed. For example, asking questions and having them describe what they are doing and why.


If people believe that they are being evaluated, they are likely to do the work "by the book," instead of the way they normally do it. So those who are being observed must be assured that the observation is not for the purpose of judging them. As the observation goes on, keep detailed records of what is observed and questions that must be answered later.

Follow up

After obtaining answers to any remaining questions, publish the results of the observation.


Surveys allow you to collect information from many people in a relatively short period. A survey can be an effective way to collect quantitative information; however, writing the questions requires great skill and care to avoid ambiguity that could compromise the utility of the results.

Prepare for the Survey

  • Define purpose, target people, and logistics: Decide what you are trying to learn from the survey, who you should target in order to achieve those goals, and how the survey should be distributed (for example, paper, e-mail, internet, telephone).
  • Choose survey type:
    • Open-ended questions vs. closed-ended questions: Open-ended surveys are more difficult to analyze, yet closed-ended surveys limit the responders' options.
    • Anonymous vs. signed vs. optional: People may be more forthcoming if they do not have to provide their names, but anonymity does not allow for any follow-up questioning.
    • With vs. without pre-survey or post-survey interviews: Pre-survey and post-survey interviews increase the valuable data that you can get from the survey, but add significant effort.
  • Define target response level and follow-up activities: Getting many people to respond to a survey is difficult. If you are expecting more than a small minority of the target people to respond, it will require follow-up work beyond merely distributing the survey.
  • Write questions: This step is more challenging than it sounds. Writing questions that cannot be misinterpreted (resulting in misleading results) requires great skill and concentrated effort.
  • Test the survey: Because it is so difficult to write questions well, it is advisable to test the survey to see if people misinterpret any of the questions, and to see if it provides the information that is sought.

Distribute the Survey

Get the survey into the target people's hands, and encourage them to respond. If follow-up activities are planned to increase the response rates, do them.

Follow up

After the response period has ended, analyze the data, and summarize and report it to the appropriate people.

Jill Liles is the Senior Product Marketing Manager at Global Knowledge http://www.globalknowledge, where she primarily focuses on marketing activities for Cisco training courses. She also coordinates all marketing for Canada. In her spare time she volunteers with her local Susan G. Komen Foundation affiliate and crafts jewelry. This article draws from Global Knowledge's Requirements Development and Management course.

Copyright © Global Knowledge Training LLC. All rights reserved

Read 156377 times


+3 # Jay Henderson 2009-06-30 03:57
What would be the difference between a group interview, a workshop, and a focus group? They sound about the same to me.
Reply | Reply with quote | Quote
-32 # Dennis Masters 2012-06-05 15:53
Reply | Reply with quote | Quote
+13 # Stuart Scott 2012-06-06 17:13
Jay, here are the differences as I see them. in a group interview, I pose a series of questions, and ask for each person's response. I'm seeking to learn about their unique perspectives. I'm not looking for consensus. I'm seeking to understand a little better how a situation looks to various people, and I want to hear some give and take.

In a focus group, I'm looking to see how people respond to a set of specific alternatives. I want to know their likes and dislikes.

In a workshop, I am creating an environment in which a team of people will come together to create agreement. It could be agreement on how to run a part of the business, or agreement on system requirements, or agreement on a plan of action. But it is a building process, not merely a process of hearing opinions and preferences.

Reply | Reply with quote | Quote
0 # Aaron Gothelf 2009-06-30 05:42
Jill, Great job! I particularly liked the heading of the article; Business requirements don't just lie there for the BA to collect them. Elicitation is perhaps the most crucial phase of any project, since errors in requirements found down the road are extremely expensive to correct. Thanks! Aaron Gothelf A REAL BUSINESS ANALYST
Reply | Reply with quote | Quote
+2 # Glen B. Alleman 2009-06-30 05:58
Jill, Take a look at to see issues with "eliciting" requirements and the approaches to deal with these issues. Glen B. Alleman VP, Program Controls Aerosp ace and Defense Denver, Colorado
Reply | Reply with quote | Quote
0 # J 2009-06-30 06:03
Group Interview: Aa meeting with multiple subject matter experts that can contribute to the subject. These may be a one time meeting or multiple meetings to resolve the business needs. Workshop : A workshop is an event where many SME's are assembled in one location for a short period of time (usually one to three days) to have concentrated meetings to address requirements for a project very quickly. Focus Group: A focus Group is more for testing the viability of a product or solution.
Reply | Reply with quote | Quote
-3 # Dan 2009-06-30 07:17
Personally, I prefer negotiate rather than gather or elicit. Negotiate implies an iterative discussion with all sides fully communicating their business problems and policies. Gather and elicit connotes a one-sided interrogation. A BA needs to be proficient in business modeling as well. You can't just rely on the unstructured English language as a means of communicating the negotiated requirements. From an IT perspective, I expect BAs to have a working knowledge of the Unified Modeling Language (UML).
Reply | Reply with quote | Quote
0 # Kupe Kupersmith 2009-06-30 11:32
Interesting comment about negotiate rather than elicit or gather. I tend to think requirements is a collaborative effort from all parties involved. Those impacting requirements and those impacted. Understanding the needs of the business to effectively develop the right solution takes a village!
Reply | Reply with quote | Quote
0 # Cecilie Hoffman 2009-06-30 11:59
The verb "gather" creates a difficult-to-ac hieve expectation that BAs just have to conduct an interview and pluck well-formed requirements out of SME's heads like gathering apples from a tree. "Elicit" is better because it implies that it will take a little work to collect/pull the information from the source. I like "negotiate" because it implies a collaborative effort. And, I concur with the comment that BAs need to have business process modeling skills as well as requirements elicitation/neg otiation skills. Nice article.
Reply | Reply with quote | Quote
0 # greta blash 2009-07-01 00:55
In order for group sessions of any type to be successful they need to be planned with a goal well-specified and facilitated rather than just run as an open forum. Not only are business process modeling skills important - but also data modeling skills, especially clearly defined business rules and data definitions, to ensure that the results are correctly understood.
Reply | Reply with quote | Quote
+7 # paul horvath 2009-07-01 03:06
I have to disagree with the use of "negotiate" when it comes to requirements - whether they are being elicited, collected, gathered, hunted for or otherwise stumbled upon. Requirements represent the needs of the business that will allow them to meet their goals / objectives - it is not up to the BA to "negotiate" the needs of the business. It is up to the BA to understand the needs of the business, and as best possible, proactively provide solutions that allow them to be successful at achieving their goals / objectives. Ne gotiation will come into play when a solution is recommended, and the BA needs to collaboratively work with the business to determine which requirements will be included in the scope of the project that provides the solution. Depending on the amount of funding available for the project (and other factors like time lines and resources), some requirements will be addressed, and others will not.
Reply | Reply with quote | Quote
0 # deepthi pasupuleti 2009-08-19 01:15
agree with paul1795. Business Analyst should not negotiate on the requirements or scope of the project. but on the timeline, resources, budget etc.
Reply | Reply with quote | Quote
0 # Ron Phillips 2009-08-25 04:25
Wow! Words do carry a lot of impact, don't they? I think that the kernel of the matter is *participation* . The stakeholders need to play an active role and not just regurgitate information for the BA to scoop up. I routinely will start by giving stakeholders a mini-session on what a use case is and how we use them to take snapshots of what we want, and engage those stakeholders in actually writing and reviewing the use cases. I've had really positive experience with that, and a lot of success. Ron
Reply | Reply with quote | Quote
0 # Ellen Gottesdiener 2010-05-19 08:48
Thanks for your article! Elicit ation is both art and science. Great analysts need to draw on all the techniques you mention, selecting a combo that fits the situation. Coll aboration is crucial, but doesn't just happen. Collaboration needs to be 'engineered' for effective elicitation. In my book _Requirements by Collaboration: Workshops for Defining Needs_ i discuss ingredients for successful requirements workshops including: shar ed purpose the right people shared space wise groups pre-work focus questions serio us play trust process variety donenes s tests collabora tive closure flexibl e structure using both sides of the brain frequent debriefs. we also need know a variety of requirements models (e.g. analysis models) to draw upon that are appropriate to the domain. (and not be "one trick ponies" with our reqts. models). whew, that's alot to know and manage, while managing ourselves to be neutral and fully present throughout a workshop!
Reply | Reply with quote | Quote
0 # Vidya Sagar Obulam 2011-01-30 00:40
GOOD WORK... Here are few more steps for requirement elicitation : Skills to organize interviews Faci litate JAD Sessions Great observation power Resolving conflicts, eliminating cause of conflicts, reaching consensus Think ing Abstract and making patterns Docume ntation skills Listenin g and communication Let me know if i am wrong or if i miss some thing. Can some one know how to post an article in this site? Sagar
Reply | Reply with quote | Quote
0 # David Williams 2011-03-04 03:43
Thank you for a great article, and the responses it generated. And, special thanks to Glen B. Alleman for pointing out an excellent paper on the "Issues in Requirements Elicitation".
Reply | Reply with quote | Quote
0 # ted_block 2011-11-22 04:38
A BA may end up negotiating project scope, but never business requirements. What your business partners need isn't negotiable...wh at they get for their money may be.
Reply | Reply with quote | Quote
0 # enhal 2011-11-28 11:56
please make an articel about "eliciting on the comprehension achievement"... .thanks
Reply | Reply with quote | Quote
0 # rachana 2012-02-26 16:03
Great! I enjoyed thoroughly while raeding this article as well as the comments and learnt many things as a new player in this field .. looking forward for more such articles in future :) Thanks a lot!
Reply | Reply with quote | Quote
0 # Stuart Scott 2012-05-20 20:54

Your first paragraph caught me with the sentence "You do not gather requirements-th ey are not just lying around on the ground waiting to be picked up." I strongly agree.

I have no issue with the verb "elicit." But it isn't a very "sweaty" word; it doesn't richly convey the effort sometimes required to get behind the ambiguity that stands in the way of a deeper understanding.

There have been times when I've felt I had to STALK the information that's missing, to sneak up on it from behind, so to speak. This has been especially true about pinning down the meanings of basic terms used in a business. Terms like "account" or "customer" or "product." Sometimes the words whose meanings seem most obvious actually hide multiple, conflicting meanings.

Finding the boundaries of the problem space is another issue that requires a lot of probing and testing and negotiating. Which is, for me, the fun part of the work.

Stuart Scott
Reply | Reply with quote | Quote
+3 # Tom T 2012-06-06 13:59
The words which come to mind in reading this are "prospecting" or "mining" or "discovering", all of which imply some sort of investigation or "digging". Unfortunately, my team and I are always told we need to "gather" the requirements, so off to the orchard we go with our requirements basket...
Reply | Reply with quote | Quote
+1 # Kimberly johnson 2012-06-14 01:06
My experience on eliciting concise requirements on a subject matter that you are not the expert of , that proved very successful for me was like this.
1. Creative and crafty interigation skills (elicitation)
2. Gather your intel, seek out correct resources, this takes skill, you dont have to know it all, but know enough to get to the truth. (the truth of whst is needed, what is wanted, who needs it, why, benefits, how it will be used, who will use it, and never leave out the min wage end user) etc..,
3. Compile all evidence, stay open minded, your idea is not always the best idea, think outside of your cubicle, ask stupid questions and you'll be amazed at how different the information that came from your resources takes on a whole new meaning and perspective. Then, you will probably have to start from #1 again, but when you arrive back at this step the 2nd time around, you can feel confident you've elicited concise info that you can now gather, brainstorm, and begin building solid requirements with.
And dont forget, a devils advocate will save you more than anything. Always have one with you. It can be difficult to ask stupid questions, or play dumb, but your end result will be worth it.
Reply | Reply with quote | Quote
+1 # Stuart Scott 2012-06-14 10:05
Kimberly, thanks for reminding me of the power of "stupid" questions and the devil's advocate. When I facilitate workshops, I often invite someone to volunteer to be the "designated ignoramus" whose job is to ask the "stupid" questions that others want to ask, but feel too embarrassed to ask. I always find a willing volunteer, and once he or she breaks the ice, others soon follow.

One of my favorite simple questions is "When you said x, did you mean this, or did you mean that?" This question forces me to listen for possible alternative interpretations , and to test whether what I thought I heard was what the other person meant. It reminds me that nothing is so clear it cannot be misunderstood, and when I make assumptions I am very often wrong.
Reply | Reply with quote | Quote
0 # ademq 2012-07-16 08:36
actully,Ihad aresearch in form of term paper and it was of great use for me.thanks.
Reply | Reply with quote | Quote
-2 # Ngozi 2012-11-07 06:43
Iactually agree that the word elicit is more appropriate. It means to draw out or bring out something that is latent or dormant. Most BA's out there would probably agree with me that it connotes a more active part for the BA in terms of probing the stakeholders. It brings out the meat of the discussion as opposed to when you feel that you are gathering. That word makes the BA think his/her role is that of note taking. Eliciting is a more active word!
Reply | Reply with quote | Quote
+2 # Tony Heap 2013-09-03 16:26
I don't think that requirements are even out there to be elicited, never mind gathered! The term implies that there is one true set of requirements out there, and we will find them so long as we work hard enough to get at them.

My experience is that the things we call requirements are often created out of thin air, either by the stakeholders or by me, as we collaboratively work through the detail of how to achieve the project objectives. Also common is where we come up with a number of alternative "requirements", and we select the one we like best.

For example:

"We have a couple of ways you could get the report out of the system - either you can log in and download it, or the system can drop it on a shared drive. Which do you prefer?"

"Could the system email it to me?"

"Good idea - yes it can. Is that your preference?"

"Yes please - that would be best as it would save us a lot of time."

"OK let me check with the tech team to make sure it's easy enough to do. Assuming it is, we'll put that as the requirement."

In my view, requirements are created, or better still, designed.
Reply | Reply with quote | Quote
0 # Riz 2014-08-20 05:09
Guys , i have a situation in one of the Digital Projects that i am about to work . The client isn't actually sure about the requirements and they don't know what they want . As a BA i have to guide them and gather the requirements as well . What should be my strategy going further on such projects with regard to gathering the requirements .
Reply | Reply with quote | Quote
0 # Brian P 2016-11-16 09:13
If the client doesn't know what they want, you're not ready to elicit requirements... because there aren't any. What you need to do is to organize brainstorming sessions with both the client and some of the client's customers, to determine their "pain points" and some potential end states. You can also develop customer personas to help the client understand what their customers need and want. With this in hand, you can then start developing user stories that will ultimately drive requirements and a technical solution. I've done this successfully using a condensed version of Google's "design sprint" technique, and it's a great way to help clients who "don't know what they don't know."
Reply | Reply with quote | Quote
0 # Daz 2015-09-03 05:11
This is very similar to what is done in project management meetings with clients.
Reply | Reply with quote | Quote

Add comment

Security code

search Articles

© BA 2016

DBC canada 250