Home > Articles

Requirements Elicitation

Common requirements elicitation techniques that successful Business Analysts use to understand the problem and define a satisfactory solution.

This chapter is from the book

The first step in dealing with requirements is to get some. People often speak of “gathering requirements,” as though it were a simple collection process: The requirements are sitting around in people’s heads, and the business analyst merely asks for them and writes them down. It’s never that simple. In reality, stakeholders begin with random fragments of information: dissatisfaction with their current systems, bits of functionality they want, tasks to perform, important pieces of data, and ideas of what screen displays might look like.

Requirements elicitation is a better term for this foundational activity. To elicit something means to draw it forth or bring it out, particularly something that’s hidden or latent. The Merriam-Webster Thesaurus (2022) says, “elicit usually implies some effort or skill in drawing forth a response.” That skill is a significant asset that a business analyst brings to software development. Requirements elicitation does involve collection, but it also involves exploration, discovery, and invention. The BA guides this imaginative journey, working with diverse stakeholders to understand the problem and then define a satisfactory solution. The BA looks for potential requirements from many sources, including these:

  • User representatives and many other stakeholders

  • Documentation about business processes, current systems, and competing products

  • Laws, regulations, and business policies

  • Existing systems, which may or may not be documented

  • User problem reports, help desk records, and support staff

An experienced BA exploits multiple techniques for elicitation, choosing the appropriate tool for a particular situation. Factors to consider when selecting elicitation methods include the types of information needed; who has that information, where those people are located, and their availability; the effort that the method requires; the budget and time available; the development team’s life cycle model and methodologies; and the cultures of the developing and customer organizations (IIBA 2015).

This book does not go into elicitation techniques in detail, as those are thoroughly described in other resources (e.g., Davis 2005, Robertson and Robertson 2013, Wiegers and Beatty 2013, IIBA 2015). Table 3.1 lists several commonly used elicitation activities and the typical participants.

Table 3.1 Some common requirements elicitation techniques



Business analyst

  • Document analysis

  • Existing product and process analysis

  • System interface analysis

  • User interface analysis

  • Data mining and analysis

Business analyst and stakeholders

  • Interviews

  • Facilitated group workshops

  • Scenario analysis

  • Observing users at work

  • Process modeling

  • Focus groups

  • Brainstorming

  • Mind mapping

  • Prototyping

  • Collaboration tools such as wikis and discussion forums

  • Questionnaires and surveys

This chapter describes four core practices that are particularly valuable for eliciting both functional and nonfunctional requirements:

Practice #6. Understand what users need to do with the solution.

Practice #7. Identify events and responses.

Practice #8. Assess data concepts and relationships.

Practice #9. Elicit and evaluate quality attributes.

Practice #6 Understand what users need to do with the solution.

If you were holding a requirements elicitation discussion with some users about a new information system, which of these questions do you think would yield the greatest insights?

  • What do you want?

  • What are your requirements?

  • What do you want the system to do?

  • What features would you like to see in the system?

  • What do you need to do with the solution?

We favor the final question. While the first four questions can provide a good starting point to ask why a stakeholder wants those things, they all inquire about the solution, not the user’s problems, needs, or goals. Focusing on features can lead the team to implement incomplete functionality that doesn’t let users do all the things they must do. The feature-centered mindset also can lead to building functionality that seems like a good idea but goes unused because it doesn’t directly relate to user tasks. Regardless of your development approach, if you don’t understand what the users need to do with the features they request, you might release a product that you must rework later.

Karl once saw the limitations of elicitation questions that focus on the solution. A company held a daylong workshop with about sixty participants to brainstorm ideas for a large new commercial product. They stapled together the output from their six subgroups and called it a requirements specification. But it wasn’t. It was a mishmash of functionality fragments, feature descriptions, user tasks, data objects, and performance expectations, along with extraneous information, all stirred together with no structure or organization. Simply asking people to imagine what they wanted to see in the new product didn’t produce actionable requirements knowledge. Much more requirements development work was needed following the workshop.

Focusing on Usage

The question “What do you need to do with the solution?” is a more effective opening for discussing requirements. By understanding what the users need to do, the BA can deduce just what functionality is needed. A usage-centric approach makes it more likely that the solution will satisfy user needs, incorporating the necessary capabilities without wasting development effort on unneeded functions (Wiegers 2022).

Stories, scenarios, and use cases are variations on a common theme: asking users to describe an interaction they might have with a software system or a business to achieve some goal (Alexander and Maiden 2004). These descriptions of user goals and the interactions that lead to achieving them constitute the user requirements. User requirements appear in the middle section of the requirements information model in Figure 1.1, as reproduced in Figure 3.1. The user requirements should align with the business objectives from the vision and scope document and contribute to solving an identified business problem.

Figure 3.1

Figure 3.1 User requirements lie between business requirements and solution requirements.

Eliciting User Requirements

A person doesn’t launch an application to use a particular feature; they launch it to do something. It’s difficult for users to articulate their “requirements,” but they can easily describe how they might perform a business activity. During an elicitation discussion, the BA might ask a user representative, “Please describe a session you might have with the product we’re talking about. What would you be trying to accomplish? How do you imagine your dialogue with the system would go?” A description of a single interactive session like this is called a scenario.

A scenario identifies a sequence of steps that define a task to achieve a specific intent (Alexander and Maiden 2004). When you ask a user to describe a scenario, they’ll usually begin with the most typical or frequent activity they perform. This is sometimes called the normal flow, main flow, main success scenario, or happy path. From that initial scenario, the BA and user can then explore alternative scenarios (or flows), variations that also lead to a successful outcome. They can also discuss exceptions, possible conditions that could prevent a scenario from concluding successfully.

An effective way to organize these related scenarios is in the form of use cases (Cockburn 2001, Kulak and Guiney 2004). A use case structures all this information according to a template, which is described in the next section. The use case technique helps the team acquire and organize the mass of requirements information that any sizable system involves. If an elicitation participant says “I want to <do something>” or “I need to be able to <do something>,” the <do something> likely is a use case.

The various user classes will have different use cases, different things they need to accomplish with the solution. That’s why it’s a good idea to conduct group elicitation activities with members of each user class separately. As an example, Table 3.2 lists a few use cases for each of the user classes named earlier for the hypothetical Speak-Out.biz publication platform in Practice #4, “Identify and characterize stakeholders.”

Table 3.2 Some use cases for several Speak-Out.biz user classes

User class

Use cases


Draft an Article

Edit an Article

Publish an Article

Submit an Article to a Publication

View Article Statistics


Read an Article

Comment on an Article

Subscribe to an Author

Publication Editor

Create a New Publication

Accept or Reject a Submitted Article

Reply to an Author


Respond to a Reader Complaint

Suspend an Author’s Account

Each use case name is a concise statement that clearly indicates the user’s goal, the outcome of value that the user wishes to achieve. Notice that all the use cases in Table 3.2 begin with a definitive action verb. This is a standard use case naming convention.

Agile projects often rely on user stories as a technique for discussing system capabilities. According to agile expert Mike Cohn (2004), “A user story describes functionality that will be valuable to either a user or purchaser of the system or software.” A user story is intentionally brief, a starting point for further exploration of its details so that developers can learn enough to implement the story. User stories conform to a simple pattern, such as this one:

As a <type of user>, I want to <perform some task> so that I can <achieve some goal>.

Stories that focus on what users need to do with the solution, rather than on bits of system functionality, can serve the goal of usage-centric requirements exploration. Here’s a user story we might hear from a Speak-Out.biz author:

As an author, I want to view the page-view statistics for my published articles so that I can see which topics my readers enjoy the most.

This story addresses a piece of the functionality for the final use case shown for the Author user class in Table 3.2, View Article Statistics. The user story format offers the advantages of naming the user class and describing the intent. That information would appear in a use case specification, but it’s helpful to see it right up front like this.

There are ongoing debates about whether use cases are appropriate—or even allowed—for agile development. This isn’t the place to rehash those debates, but the short answer is: They are (Leffingwell 2011). Both use cases and user stories have their advantages and limitations (Bergman 2010). Both can be used to explore what users need to accomplish with the solution.

One of the BA’s challenges is to examine a particular scenario that describes a single usage session and consider how to generalize it to encompass a group of logically related scenarios. That is, the BA moves up the abstraction scale from a specific scenario to a more general use case. Similarly, the BA on an agile project might see that a set of related user stories can be abstracted into a larger epic that needs to be implemented over several iterations.

At other times, elicitation participants might begin with a complex usage description that the BA realizes should be split into multiple use cases. Those individual use cases often can be implemented, and executed, independently, although several could perhaps be chained together during execution to carry out a larger task. On an agile project, a user story that’s too large to implement in a single iteration is split into several smaller stories. Moving between levels of abstraction like this is a natural part of exploring user requirements.

Use cases facilitate top-down thinking, describing multiple scenarios and fleshing out the details of the user–system interactions. Use cases provide a context for organizing related pieces of information. Epics perform an analogous top-down function on agile projects. User stories describe smaller user goals or pieces of system functionality without much context or detail. Stories generally are smaller than use cases, describing slices of functionality that can be implemented in a single development iteration. Related user stories can be grouped together and abstracted into an appropriate use case or an epic. Any approach can be effective—use cases or user stories, top-down or bottom-up—provided the focus stays on usage.

Anatomy of a Use Case

Unlike the simple user story format, a use case specification follows a rich template like the one in Figure 3.2 (Wiegers and Beatty 2013). You may download this template from the website that accompanies this book. A collection of use case descriptions could serve as the contents of the user requirements document (“container”) that appears in Figure 3.1. Nothing says that you must complete this full template for each of your use cases. Write in whatever level of detail will clearly communicate the use case information to those who must validate, implement, or write tests based on it.

Figure 3.2

Figure 3.2 A rich use case specification template.

Applying Usage-centric Requirements Information

User requirements serve as a starting point for several subsequent activities. Both use cases and user stories need to be further elaborated into a set of functional requirements, which is what developers implement. This step takes place whether a BA does it analytically and documents the resultant details or whether each developer does it in their head on the fly (not the recommended approach).

Use cases and user stories both facilitate starting testing early in the development cycle. If a BA derives functional requirements from a use case and a tester derives tests, you now have two representations of requirements knowledge that you can compare. That comparison can reveal requirements errors, ambiguities, and omissions. See Practice #18, “Review and test the requirements,” for more on this topic. Documenting how the system should handle exceptions lets developers build more robust software and helps testers do a more thorough job.

User stories and use cases also lie at the core of requirements prioritization. The deciding stakeholder typically prioritizes user stories or use cases in a sequence that maximizes customer value. The team then fits them into iterations or increments based on the team’s available capacity, considering any relevant technical and functional dependencies. While user stories are each prioritized on their own, the individual flows within a use case could have different priorities. You might opt to implement the normal flow and its exceptions in one development increment, and then implement alternative flows and their corresponding exceptions in upcoming increments.

Usage-centric requirements exploration won’t reveal behind-the-scenes capabilities, such as a timeout to turn off some device or log out a user after a period of inactivity. Nonetheless, focusing elicitation on understanding what users must do with the system helps the team implement all the necessary—and no unnecessary—functionality. Usage-centric thinking also leads nicely into designing an optimal user experience (Constantine and Lockwood 1999).

Related Practices

Practice #2. Define business objectives.

Practice #4. Identify and characterize stakeholders.

Practice #7. Identify events and responses.

Practice #13. Prioritize the requirements.

Practice #16. Identify and document business rules.

Practice #18. Review and test the requirements.

Next Steps

  1. If your team has not explored the tasks that users want to perform with the solution you’re building, have conversations with your user representatives to identify their use cases. Explore alternative scenarios along with the normal flow. Make sure to note exceptions and how they should be handled.

  2. Try completing the use case template in Figure 3.2 for several of your use cases. How could you simplify the template and still meet the needs of your developers and testers?

  3. If your project is employing user stories, try documenting a group of related scenarios both in the use case format and as a set of user stories. Which approach seems most effective and efficient for your team?

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020