An Overview of Requirements Elicitation

What is Elicitation?

A 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:

• BABOK Guide 2.0 (Note that the BABOK Guide covers not only elicitation but is a thorough reference to all aspects of business analysis.)

• Unearthing Business Requirements: Elicitation Tools and Techniques by Kathleen B. Hass and Rosemary Hossenlopp.

• A Survey on Requirements Elicitation by Martin Fehrenbach.

• “Techniques for Requirements Elicitation” by Joseph A. Goguen, et al inProceedings from Requirements Engineering: http://74.125.155.132/scholar?q=cache:ab2Qlyg2aogJ:scholar.google.com/+requirements+elicitation&hl=en&as_sdt=2001    

Author: Morgan Masters is Business Analyst and Staff Writer at ModernAnalyst.com, 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 http://www.ModernAnalyst.com

¹ Davey, Bill, et al. “Requirements Elicitation: What’s Missing?” Issues in Informing Science and Information Technology. Vol. 5, 2008. http://proceedings.informingscience.org/InSITE2008/IISITv5p543-551Davey466.pdf
²A 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.

³Ibid.

⁴Ibid.

⁵Davey, Bill, et al. “Requirements Elicitation: What’s Missing?” Issues in Informing Science and Information Technology. Vol. 5, 2008. http://proceedings.informingscience.org/InSITE2008/IISITv5p543-551Davey466.pdf

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

⁷“Techniques for Requirements Elicitation” by Joseph A. Goguen, et al in Proceedings from Requirements Engineering: http://74.125.155.132/scholar?q=cache:ab2Qlyg2aogJ:scholar.google.com/+requirements+elicitation&hl=en&as_sdt=2001