An Overview of Requirements Elicitation


What is Elicitation?

An Overview of Requirements ElicitationA thorough discovery of business requirements is almost never readily available at an analyst’s fingertips—rarely can requirements be quickly looked up as one would gather information for a term paper or study for a test. Much of business or technical requirements is not documented anywhere—it resides in the minds of stakeholders, in feedback that has yet to be obtained from end users, and from a study of flowcharts and surveys that have yet to be created. And so requirements must be elicited, or drawn out, and the methodology in doing so must be logical and meticulous. The importance of elicitation cannot be overstated, for it is the linchpin to any requirements project. As one scholarly article notes: “Mistakes made in elicitation have been shown many times to be major causes of systems failure or abandonment and this has a very large cost either in the complete loss or the expense of fixing mistakes.” Adequate study and preparation for elicitation can go a long way to preventing these types of errors. The purpose of requirements elicitation, therefore, is to thoroughly identify the business needs, risks, and assumptions associated with any given project.

Prepare for Elicitation

  1. The first step in requirements elicitation is gleaning a comprehensive and accurate understanding of the project’s business need. During the elicitation process, an analyst’s strong understanding of the business need will help her guard against scope creep and gold plating, as well as select the proper stakeholders and elicitation techniques.

  2. An analyst’s next step in eliciting requirements is ensuring that an adequate amount and mix of stakeholders are secured for the project’s duration. For, as BABOK 2.0 (Business Analysis Body of Knowledge, the definitive guide to all things related to business analysis) notes, a good analyst must “actively engage stakeholders in defining requirements.” According to BABOK, a project’s stakeholders may include customers/end users, suppliers, the project manager, quality analysis, regulators, project sponsors, operational support, domain subject matter experts, and implementation subject matter experts. An analyst must recruit the participation of appropriate stakeholders based on the unique business needs of her project. After an analyst has identified and recruited her stakeholders, and chosen the method(s) by which she will elicit requirements (outlined below), it is advisable for her to schedule the time for conducting those methods with stakeholders as far in advance as possible to ensure adequate participation on their parts.

Elicitation Techniques

After securing the proper stakeholders, an analyst must determine the best techniques for eliciting requirements. Commonly used requirements elicitation methods (as identified by BABOK) include:

  • Brainstorming – The purpose of gathering your stakeholders for brainstorming is “to produce numerous new ideas, and to derive from them themes for further analysis [from BABOK].” An analyst should try to secure a representative from each participating stakeholder group in the brainstorming session. If an analyst serves as facilitator of a brainstorming session, she must ensure that while participants feel free to propose new ideas and solutions, they remain focused on the business need at hand and do not engage in scope creep, gold plating, or become distracted with other business issues. All ideas must be recorded so that they are not lost. According to BABOK, the brainstorming method is particularly useful if your project has no clear winning choice for a solution, or if existing proposed solutions are deemed inadequate. The brainstorming process and the resulting follow-up analysis will help ensure that the best possible solution is reached for any business objective.

  • Document analysis – Document analysis involves gathering and reviewing all existing documentation that is pertinent to your business objective or that may hold data related to a relevant solution. According to BABOK, such documentation may include, “business plans, market studies, contracts, requests for proposal, statements of work, memos, existing guidelines, procedures, training guides, competing product literature, published comparative product reviews, problem reports, customer suggestion logs, and existing system specifications, among others.” In other words, virtually anything that is written related to the project may be useful. This type of elicitation is especially useful when the goal is to update an existing system or when the understanding of an existing system will enhance a new system. However, document analysis alone is rarely enough to thoroughly extract all of the requirements for any given project.

  • Focus Group – Focus groups consist of a mix of pre-qualified stakeholders who gather to offer input on the business need at hand and its potential solutions. Focus groups are particularly helpful when key stakeholders are not particularly imaginative or forthcoming; a few more vocal stakeholders may help them think through and articulate solutions. Focus groups are also a good way for time-pressed analysts to get a lot of information at once. They may be conducted in person or virtually. (Key project sponsors or business owners should still be interviewed individually for thorough discovery.)

  • Interface Analysis – An interface analysis carefully analyzes and deconstructs the way that a user interacts with an application, or the way one application interacts with another. According to BABOK, a thorough interface analysis will describe the purpose of each interface involved and elicit high-level details about it, including outlining its content. This type of elicitation is essential for software solutions, which almost always involve applications interacting with one another and/or users interacting with applications. But, according to BABOK, interface analysis can also be useful for non-software solutions (such as defining deliverables by third parties).

  • Interviews – One-on-one interviews are among the most popular types of requirements elicitation, and for good reason: they give an analyst the opportunity to discuss in-depth a stakeholder’s thoughts and get his or her perspective on the business need and the feasibility of potential solutions. “Research has found that interviews . . . are the most effective way of eliciting requirements.” Whether an analyst chooses to have a structured (with predefined questions) or unstructured interview (with free-flowing, back-and-forth conversation), she must fully understand the business need in order to conduct a successful interview. It is a good practice for an analyst to share her interview notes with the interviewee afterward to ensure there were no misunderstandings and to jog the interviewee’s thoughts for any further insights.

  • Observation (job shadowing) – Observation is quite helpful when considering a project that will change or enhance current processes. According to BABOK, two basic types of observation are available to an analyst: (1) passive observation, where the analyst merely watches someone working but does not interrupt or engage the worker in any way, and (2) active observation, where an analyst asks questions throughout the process to be sure she understands and even attempts portions of the work. The nature of an analyst’s project will dictate the level of detail an observation should encompass. As with interviews, it is a good practice for an analyst to provide notes from her observations and/or a verbal description of her understanding of the work for the worker to review in order to be sure that there were no misunderstandings of the process.

  • Prototyping (storyboarding, navigation flow, paper prototyping, screen flows) – Prototyping is especially valuable for stakeholders such as business owners and end users who may not understand all of the technical aspects of requirements, but will better relate to a visual representation of the end product. To quote BABOK, “Stakeholders often find prototyping to be a concrete means of identifying, describing and validating their interface needs.” The prototyping process is normally iterative, improving as more input and evaluation are gleaned from stakeholders. Prototyping may be an interactive screen (normally consisting of hypertext only with no real data behind it), a mock-up (such as a PowerPoint), a navigation flow (such as a Visio diagram), or a storyboard. Simple, throwaway prototypes (such as pencil sketches) may be done in the initial stages of discovery, and more detailed, interactive prototypes may be done once business requirements have been identified. At the latter, more detailed prototype stage,prototype features must fulfill previously identified business needs as outlined in the requirements.

  • Requirements workshops – A requirements workshop involves gathering a previously identified stakeholders in a structured setting for a defined amount of time in order to elicit, refine, and/or edit requirements. To be successful, requirements workshops must include a recorder (or scribe) to record participants’ input, and a facilitator to direct the discussion. Because participants’ may also brainstorm together and listen to each others’ input, they can provide immediate feedback and refinements to identified business needs, which can ensure a fast, effective elicitation of requirements.

  • Survey/questionnaire – While they preclude the opportunity for in-person, ad hoc conversations, surveys are useful for quickly gathering data from a large group of participants. Because free online survey software is readily available, surveys are an inexpensive way to gather objective input from customers or potential end users. As with selecting stakeholders, a successful survey or questionnaire must have well-chosen participants. As one researcher notes, questionnaires “can be useful when the population is large enough, and the issues addressed are clear enough to all concerned.” Surveys can be structured to offer a series of finite choices for feedback, or they can offer open-ended input, depending on the needs of the project at hand. Open-ended surveys are useful for a broader discovery of business needs; however, the larger the number of participants in open-ended surveys, the more prohibitive they are to analyze. Survey wording must be unambiguous and precise. It is good practice for an analyst to politely request that survey participants respond by a reasonable deadline and that they keep any proprietary business information contained within the survey confidential.

Conduct Elicitation

An analyst’s project’s business needs and the stakeholder mix will determine which of the above elicitation method(s) are best. Elicitation does not normally occur solely prior to requirements however; it occurs throughout a project—during discovery, modeling, and even testing. Whenever elicitation takes place during a project’s life cycle, the same principles apply to make it successful—the correct mix of stakeholders, a thorough understanding of the business need, properly selected elicitation techniques, and meticulous attention to detail.

Confirm Elicitation Results

Once the elicitation methods have been employed, an analyst must document the elicitation quickly, while it is still fresh in her mind, and share the results with appropriate stakeholders to confirm their agreement with the findings. This stage is essential to ensure that the analyst has accurately grasped, and stakeholders have accurately communicated, the project’s needs.

Elicitation serves as the underlying research to requirements creation phase. Once an analyst has sufficient material, she can begin crafting requirements.

References for Further Study

For a more detailed study into requirements elicitation, please refer to:

Author: Morgan Masters is Business Analyst and Staff Writer at, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at

1 Davey, Bill, et al. “Requirements Elicitation: What’s Missing?” Issues in Informing Science and Information Technology. Vol. 5, 2008.
2A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.



5Davey, Bill, et al. “Requirements Elicitation: What’s Missing?” Issues in Informing Science and Information Technology. Vol. 5, 2008.

6A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

7“Techniques for Requirements Elicitation” by Joseph A. Goguen, et al in Proceedings from Requirements Engineering:

Like this article:
  55 members liked this article


Tony Markos posted on Wednesday, July 7, 2010 3:37 PM
Yes the techniques mentioned will elicite requirements. But how does the BA know that discovery is complete? When the subject matter experts say "Yup, ya got them all?" What is the lithmus test of completedness in requirements elicitation?

Marc Thibault posted on Wednesday, July 7, 2010 10:15 PM
Morgan: Good article that covers the ground well. There are two more topics that might be useful:

Given that what we're doing is defining success, I'd be looking for measurable criteria to tell us when we're finished. (The value of this is x today and it will be y when we're done)

Also, you mention risk in the introduction, but it never shows up again. Enumerating the risks to the aim is vital. Establishing the stakeholders' risk tolerance from the point of view of project cost and time is needed as an input to the project budget and schedule development.

Tony: That's what use cases are for. When nobody can think of anything else to do with the thing or find another actor to be served, when you run out of use cases, you've captured the breadth of the requirement. The depth of detail in each use case is a separate issue that you'll need to take up with the developers.
Adrian M. posted on Thursday, July 8, 2010 1:10 AM
Tony & Marc - the topic of "how do we know when we are done" with requirements elicitation is a good one.

I'm not sure that most organizations have figured this out very well. Many organizations simply use some sort of "boxing" either time boxing but telling the Business Analyst to do as much as they can by the deadline or budget boxing but doing as much as you with the allocated dollars.

I have never seen any project or organization where I was allowed to take my time until I'm done - that's because it's very hard to come up with objective criteria when when we are done.

Having said that, here's a fun answer to the question:

The Popcorn Way and the Business Analyst
Tony Markos posted on Thursday, July 8, 2010 4:26 PM

Properly used, data flow diagrams (not use cases) make holes in functional/process analysis glaringly clear. And, as they are uniquely focused on the essentials (i.e., a process is defined by its inputs and outputs), they are the quickest way of eliciting requirements.

undrkvabrtha posted on Tuesday, July 13, 2010 7:23 PM
Techniques and tools are one way of analyses...

The manner in which Requirements Elicitation techniques / tools have been presented in this article are commendable.

Well written. I guess one point to make though, is that techniques and tools are put to use best when they are altered to match circumstances or people.

Attempting to change your organization to match BABoK or other industry standards is not always the best approach.

On that count, there're some other tools I think may prove important:

1. Emotional Intelligence
2. Political Intelligence (understanding the political undercurrents)
3. The ability to alter industry concepts to suit The Big Boss' idea of how a business should be run
zarfman posted on Wednesday, July 14, 2010 11:14 PM


Most of my career has been spent in the areas of Finance and Accounting at the Controller and Vice President level. I will admit that, back in the day I spent a decade in the aerospace industry designing missile guidance systems and flight control systems. Clearly, I spent a lot of time in the classroom. Accordingly, I have my own set of biases.

What confounds me is how one not skilled in a particular art or science can be expected to conduct a competent analysis of that area.

For example, a BA may have a good understanding of accounts payable or accounts receivable systems. However, when faced with analyzing, understanding and implementing FASB 157 (calculation of fair value) they are hopelessly lost. I know this to be true, because it happened on my watch.

I can’t help but wonder if businesses wouldn’t be better of if our Universities trained our Accounting, Science, Engineering et al graduates how to convert their ideas and/or requirements into a form understandable by various analysts, programmers and DBA’s.

With regard to risks, Robert Bea at UC Berkley has done a lot of work in this area.
His work includes hurricane Katrina and the BP oil spill.

Like I said I have my biases.


undrkvabrtha posted on Sunday, July 18, 2010 9:15 PM

I agree. The concept of what a 'requirement' is varies amongst various types of analysts / managers. The shame is that many managers are convinced that a person without any background in a field can analyse it.

If, at university, there were a course, a subject or an area of study termed 'Requirements Management' a lot of businesses would be much happier, as would a lot of fresh graduates, high-school-dropout programmers, qualified analysts and DBAs.

My take'd be that anyone in a business administration or management area should know how to present a requirement, as requirements usually originate with the business, and not with the technicians.

It has been quite interesting reading up on Robert Bea. Thank you for the titbit!
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC