9.1 Core Elicitation & Analysis Techniques

9.1 Core Elicitation & Analysis Techniques

Quick Summary: BABOK® Guide v3 Chapter 10 defines 50 techniques that business analysts use to execute tasks across all knowledge areas. Among these, the core elicitation and analysis techniques—Interviews, Requirements Workshops, Document Analysis, Focus Groups, and Observation—form the backbone of requirements discovery, stakeholder engagement, and operational fact-finding.

---

1. Interviews

An Interview is a formal or informal approach to elicit information from an individual or small group of stakeholders by asking prepared and spontaneous questions. It remains the most widely utilized elicitation technique across both predictive and adaptive initiatives.

Interview Formats

Questioning Strategies: Open-Ended vs. Closed-Ended

• Open-Ended Questions: Prompt expansive, narrative responses that encourage the interviewee to describe workflows, pain points, and aspirations (e.g., "How does your team handle exceptions during commercial loan underwriting?"). Used early in elicitation to discover unknown scope and tacit knowledge.
• Closed-Ended Questions: Restrict answers to specific, discrete choices, binary responses, or numerical values (e.g., "Is the collateral appraisal conducted before or after credit committee review?"). Used to confirm facts, validate assumptions, and finalize unambiguous acceptance thresholds.

+-----------------------------------------------------------------------------------+
|                         Interview Lifecycle Protocol                              |
+-----------------------------------------------------------------------------------+
|  1. PREPARE: Define objectives, select interviewees, draft questions, set agenda. |
|  2. OPEN: Build rapport, state interview purpose, confirm recording/note policy.  |
|  3. CONDUCT: Ask open/closed questions, actively listen, probe deeper, take notes. |
|  4. CLOSE: Summarize key findings, identify open items, explain next steps.       |
|  5. FOLLOW-UP: Transcribe notes, document requirements, send for formal sign-off. |
+-----------------------------------------------------------------------------------+

---

2. Requirements Workshops (Joint Application Design / JAD)

A Requirements Workshop is a structured, highly collaborative working session that brings key cross-functional stakeholders together for a concentrated period to discover, define, negotiate, prioritize, and reach consensus on requirements and solution designs.

Core Workshop Roles and Responsibilities

   ┌─────────────────────────────────────────────────────────────────────────────┐
   │                   Workshop Dynamics & Conflict Management                   │
   │                                                                             │
   │  [Facilitator]  <── Neutral Guardrail ──>  [Diverse Stakeholders]           │
   │        │                                           │                        │
   │        ▼                                           ▼                        │
   │  • Enforces Ground Rules                   • Operations vs. Technology      │
   │  • Uses Parking Lot for Off-Topic Items   • High Urgency vs. High Quality  │
   │  • Drives Consensus / Multi-Voting         • Direct Collaboration & Signoff │
   └─────────────────────────────────────────────────────────────────────────────┘

Strengths and Limitations of Workshops

• Strengths: Rapid consensus building; immediate resolution of conflicting stakeholder viewpoints; high stakeholder ownership of resulting requirements; significantly reduces elapsed project discovery duration.
• Limitations: High scheduling overhead and logistics cost; risk of dominant personalities overpowering quieter SMEs; groupthink or premature compromise; requires advanced facilitation mastery.

---

3. Document Analysis

Document Analysis is an elicitation technique used to harvest business analysis information, business rules, data schemas, process definitions, and constraints by evaluating existing organizational artifacts and system documentation.

Suitable Document Sources

• Standard Operating Procedures (SOPs), training manuals, and process guidelines.
• Regulatory filings, statutory compliance mandates, and industry legal frameworks.
• Existing system specifications, interface control documents, database schemas, and data dictionaries.
• Business charters, contracts, request for proposals (RFPs), and vendor service level agreements (SLAs).
• Help desk defect logs, user ticket histories, and operational error reports.

Document Analysis Execution Steps

1. Evaluate Suitability: Determine whether existing documents are current, credible, authoritative, and relevant to the initiative's scope.
2. Analyze Content: Extract substantive business concepts, entity definitions, workflow sequences, calculation formulas, and validation constraints.
3. Identify Gaps & Contradictions: Note discrepancies between documented procedures and current operational reality.
4. Confirm Findings: Validate extracted requirements with domain SMEs through targeted interviews or structured walkthroughs.

[!NOTE] Document Analysis Advantage: It creates a baseline understanding before engaging stakeholders, preventing "stakeholder fatigue" and ensuring interviews are used for high-value validation rather than basic orientation.

---

4. Focus Groups

A Focus Group is an elicitation technique that brings together 6 to 12 pre-qualified, representative stakeholders and end users, led by a trained moderator, to elicit qualitative feedback, emotional impressions, subjective attitudes, and preferences regarding a proposed product, service, or concept.

+-----------------------------------------------------------------------------------+
|                         Focus Group Composition Types                             |
+-----------------------------------------------------------------------------------+
|  HOMOGENEOUS FOCUS GROUP:                                                         |
|  * Participants share similar backgrounds, job roles, or user personas.           |
|  * Maximizes psychological safety and uninhibited sharing of common experiences.  |
|  * Example: A session composed exclusively of Senior Branch Underwriters.         |
|                                                                                   |
|  HETEROGENEOUS FOCUS GROUP:                                                       |
|  * Participants represent diverse departments, technical proficiencies, or roles. |
|  * Exposes contrasting perspectives, cross-departmental tensions, and tradeoffs.  |
|  * Example: A session with Patients, Triage Nurses, Doctors, and Billing Clerks.   |
+-----------------------------------------------------------------------------------+

Focus Group vs. Requirements Workshop: Key Differences

• Focus Group: Explores attitudes, perceptions, user experiences, and qualitative sentiments. It does not seek consensus or produce formal requirement specifications.
• Requirements Workshop: Focuses on collaborative scoping, rule definition, negotiation, and agreement to produce actionable, verified requirements deliverables.

---

5. Observation (Job Shadowing)

Observation is an elicitation technique where the business analyst studies stakeholders in their actual work environment to understand workflows, physical constraints, operational workarounds, and user-system interactions.

Observation Modes

The Hawthorne Effect

[!WARNING] The Hawthorne Effect occurs when workers alter their behavior, increase productivity, or strictly follow official rules solely because they are conscious of being observed. Business analysts must counteract this bias by observing over extended periods, establishing trust, combining observation with data analytics, and conducting unannounced spot-checks when appropriate.

---

Situational Technique Selection Framework

   ┌─────────────────────────────────────────────────────────────────────────────┐
   │                   Technique Selection Decision Rules                        │
   ├─────────────────────────────────────────────────────────────────────────────┤
   │ • Tacit, unwritten knowledge or complex physical task?  ──> OBSERVATION     │
   │ • Deep individual insights, confidential/sensitive?     ──> INTERVIEW       │
   │ • Cross-functional alignment, urgent consensus needed?  ──> WORKSHOP (JAD)  │
   │ • Baseline discovery, legacy system, zero SME time?     ──> DOC ANALYSIS    │
   │ • Market perception, customer sentiment, UX attitude?   ──> FOCUS GROUP     │
   └─────────────────────────────────────────────────────────────────────────────┘

---

Enterprise Scenario: Healthcare Claims Processing Optimization

MetroHealth Insurance initiated a multi-million-dollar modernization of its legacy claims adjudication engine. The lead business analyst applied a multi-technique elicitation strategy:

1. Document Analysis: Reviewed 450 pages of federal HIPAA mandates, state insurance guidelines, and legacy COBOL system interface specifications to extract 120 baseline business validation rules.
2. Passive Observation: Observed 15 claims adjusters for three full shifts. The BA discovered that adjusters maintained unapproved "cheat-sheet" spreadsheets to manually calculate deductible offsets due to legacy UI latency—a critical tacit workflow omitted from official manuals.
3. Requirements Workshop: Facilitated a 3-day JAD session with Claims Adjusters, Fraud Investigators, Medical Reviewers, and IT Architects. The neutral facilitator resolved a heated dispute regarding automated fraud flagging thresholds, securing agreement on a unified triage rule set.
4. Homogeneous Focus Group: Convened 8 independent primary care providers to evaluate the proposed provider portal UI mockups, capturing qualitative feedback that the batch invoice submission workflow was counterintuitive.

---

[!TIP] CCBA Exam Tip: Scenario questions frequently describe a project where "stakeholders do not know what they do not know" or "have performed routine tasks for so long they cannot articulate the steps." In such cases, Observation is always the most effective elicitation technique to uncover tacit knowledge.

[!WARNING] CCBA Exam Trap: Be careful when distinguishing the role of a Facilitator from a Subject Matter Expert (SME) in a workshop. A facilitator must never contribute requirements, advocate for specific design solutions, or vote on priorities. If a question describes a facilitator deciding on a requirement, that facilitator is violating BABOK core principles.