luvv to helpDiscover the Best Free Online Tools

Requirements Elicitation

Learn Requirements Elicitation for Business Analyst for free: roadmap, examples, subskills, and a skill exam.

Published: December 20, 2025 | Updated: December 20, 2025

What is Requirements Elicitation?

Requirements elicitation is the structured process of discovering, clarifying, and validating what stakeholders really need a solution to do (and not do). For Business Analysts, it is the gateway to building the right product the first time.

Why it matters for Business Analysts

  • Aligns business goals with user needs so delivery teams build the right features.
  • Reduces rework by clarifying ambiguous requests early.
  • Surfaces constraints, risks, and tradeoffs before they derail delivery.
  • Creates shared understanding across business, design, and engineering.

Who this is for

  • New or aspiring Business Analysts learning core BA practices.
  • Product owners, UX researchers, and PMs needing structured elicitation.
  • Engineers/QA who often translate ideas into stories and tests.

Prerequisites

  • Basic understanding of the business domain you work in.
  • Comfort with speaking to stakeholders and taking structured notes.
  • Familiarity with user stories and acceptance criteria (helpful but not required).

Learning path (practical roadmap)

  1. Frame the problem – Define business goals, success metrics, and context. Capture assumptions and constraints.
    Mini task: 15-minute problem frame
    • Write: Problem statement (one sentence).
    • List: 3 success metrics and 3 key constraints.
    • Draft: In-scope vs out-of-scope bullets (max 5 each).
  2. Identify and map stakeholders – Who is impacted, who decides, who operates, who pays? Map influence/interest and communication cadence.
  3. Plan elicitation – Choose techniques (interviews, workshops, observation, surveys, document analysis). Prepare scripts, prompts, and activities.
  4. Run sessions – Facilitate interviews/workshops, ask clarifying questions, and capture structured notes.
  5. Synthesize – Convert notes into functional and non-functional requirements with acceptance criteria; document assumptions and constraints.
  6. Prioritize – Apply MoSCoW, RICE, or value vs effort. Negotiate tradeoffs explicitly.
  7. Validate – Review with stakeholders, play back scenarios, adjust wording and scope boundaries.

Worked examples

Example 1: Interview plan for a billing feature

Objective: Understand failures in invoice approval and late-payment drivers.

Participants: Finance lead, 2 AP clerks, Sales ops, IT support.

Sample interview prompts
  • Walk me through your last invoice approval. Where did it slow down?
  • What information do you check before approving? What is often missing?
  • When do you escalate? What triggers it?
  • What would a “good day” look like for you?
  • If we could only improve one thing, what would it be and why?

Notes structure: Goals, pain points, current steps, data needed, exceptions, ideas.

Example 2: Clarifying an ambiguous requirement

Stakeholder says: “We need faster login.”

Rewrite as a Non-Functional Requirement (NFR): “99th percentile login time must be under 2 seconds during peak load (Mon–Fri 9–11am, 2–4pm).”

Acceptance criteria:

  • Given peak load, when 10,000 users log in within 10 minutes, 99% see the dashboard in under 2s.
  • System logs performance metrics with timestamps for audit.

Example 3: User story and acceptance criteria

User story: As an accounts payable clerk, I want to auto-flag invoices without PO numbers so I can resolve them quickly.

Acceptance criteria:

  • Invoices missing PO numbers are flagged with status “Needs PO.”
  • Flag includes reason and link to vendor profile.
  • Users can add or link a PO and clear the flag.
  • Flagged invoices are included in the “Exceptions” queue.

Example 4: Scope boundaries and assumptions

  • In scope: Web UI for invoice flagging; email notifications to AP group; audit log entries.
  • Out of scope: Mobile app; vendor onboarding flow; invoice OCR improvements.
  • Constraints: Must use existing identity provider; deployment window limited to weekends.
  • Assumptions: Vendor records have unique IDs; AP team checks exceptions dashboard daily.

Example 5: Prioritization with MoSCoW

  • Must: Flag missing PO; Exceptions queue; Add/link PO.
  • Should: Bulk clear flags; Email digest.
  • Could: Slack notifications; Configurable thresholds.
  • Won't (this release): Mobile push alerts.
Tradeoff scenario

Conflict: Security wants SSO before release; Sales wants release by quarter end.

Decision pattern:

  • Risk: Without SSO, manual account sync is error-prone.
  • Value: Release unlocks revenue recognition.
  • Compromise: Release to a pilot group without SSO, restrict data access; plan SSO as first post-release Must.

Drills and exercises

  • Create a 10-question interview script for two personas: requester and approver.
  • Rewrite 3 vague requirements into testable acceptance criteria.
  • List top 5 constraints and 5 assumptions for your current project.
  • Draft an in-scope/out-of-scope list (max 6 items each) for a small feature.
  • Run a 30-minute mock workshop with a colleague: map current vs desired process.
  • Prioritize 8 candidate requirements using MoSCoW. Justify two tradeoffs.
  • Validate with a stakeholder: conduct a 15-minute playback and capture 3 changes.

Common mistakes and quick fixes

  • Mistake: Asking solution-led questions ("Do you want a button?").
    Fix: Ask outcome-led questions ("What decision are you trying to make here?").
  • Mistake: Recording opinions as facts.
    Fix: Tag notes by type: fact, assumption, opinion, risk; validate later.
  • Mistake: Skipping non-functional requirements.
    Fix: Add performance, security, reliability, and usability prompts to every session.
  • Mistake: No acceptance criteria.
    Fix: Use Given-When-Then to force testability.
  • Mistake: Overpromising scope.
    Fix: Maintain in/out-of-scope list, review at each milestone.
  • Mistake: Unresolved conflicts.
    Fix: Document tradeoffs, owners, decision date, and revisit with impact.

Mini project: Elicit a feature for a cafe pre-order app

  1. Problem frame: Customers abandon lines; cafe wants to speed up peak service. Target: 20% more orders at 8–10am.
  2. Stakeholders: Baristas, cashiers, store manager, customers, POS vendor, IT.
  3. Elicitation plan: 4 interviews (barista, cashier, manager, customer) + 1 workshop (15min process map).
  4. Run sessions: Capture steps, pain points, exceptions (e.g., out-of-stock, custom drinks).
  5. Synthesize: Stories (select pickup time, customize drink), NFRs (peak latency under 1.5s), constraints (existing POS API only).
  6. Prioritize: Must: customize + pickup slot; Should: reorder past items; Could: tip suggestions.
  7. Validate: Playback with manager and 2 baristas; adjust acceptance criteria.
Deliverables to produce
  • Problem statement and success metrics
  • Stakeholder map and roles
  • Interview notes and workshop outcomes
  • 5 user stories with acceptance criteria
  • NFR list (performance, reliability, security)
  • In/out-of-scope, constraints, assumptions
  • Prioritization with rationale

Subskills

Master these focused areas to progress faster:

  • Problem Discovery And Context: Frame the business problem, goals, metrics, and current-state process.
  • Stakeholder Interviews: Plan and conduct interviews that surface needs, pains, and constraints.
  • Workshop Facilitation: Run collaborative sessions to align, map processes, and resolve differences.
  • Requirements Gathering Techniques: Use interviews, observation, surveys, document analysis, and prototypes.
  • Asking Clarifying Questions: Turn vague statements into precise, testable requirements.
  • Identifying Constraints And Assumptions: Make limits and unknowns explicit to reduce risk.
  • Defining Scope And Boundaries: Keep delivery focused with in/out-of-scope and interfaces.
  • Functional Requirements: Specify behaviors, rules, and user interactions.
  • Non Functional Requirements: Capture performance, security, reliability, and usability.
  • Requirements Prioritization: Rank by value, risk, and effort; negotiate tradeoffs.
  • Requirements Validation With Stakeholders: Playback, review, and sign-off with acceptance criteria.
  • Handling Conflicts And Tradeoffs: Facilitate decisions and document impacts.

Next steps

  • Pick one mini project and finish the deliverables this week.
  • Practice two stakeholder interviews and rewrite at least three NFRs.
  • Then take the skill exam to check your readiness. Everyone can take it; logged-in learners get progress saved.

Skill Exam

Start the exam below when ready.

Requirements Elicitation — Skill Exam

This exam checks your understanding of elicitation planning, interviews, workshops, scope, constraints, acceptance criteria, and prioritization. Everyone can take it for free. If you are logged in, your progress and score will be saved automatically. You can retake the exam anytime.Rules: Closed-book is recommended but not required. Aim for 70% or higher to pass. Read each scenario carefully; some questions have multiple correct answers.

15 questions70% to pass

Have questions about Requirements Elicitation?

AI Assistant

Ask questions about this tool