3.3 Confirm Elicitation Results (Task 4.3)
Key Takeaways
- Task 4.3 validates that captured elicitation findings accurately reflect stakeholder intent and are consistent across disparate information sources.
- Confirms the critical transition from Elicitation Results (unconfirmed) to Elicitation Results (confirmed), establishing an accurate baseline for subsequent modeling.
- Crucial distinction: Confirming results checks whether the BA recorded what was communicated; it does not replace Verification (Task 7.2 - quality of specifications) or Validation (Task 7.3 - alignment with business value).
- Uncovers unstated assumptions and implicit needs by differentiating stated user wants from underlying business problems.
- Resolves contradictions and inconsistencies across stakeholder groups before detailed requirements specifications are developed.
3.3 Confirm Elicitation Results (Task 4.3)
Quick Summary: Elicitation sessions generate a vast amount of raw, unstructured data—interview notes, whiteboard sketches, audio recordings, and survey responses. BABOK v3 Task 4.3 (Confirm Elicitation Results) checks this information for accuracy, fidelity, and internal consistency against other organizational sources, converting Elicitation Results (unconfirmed) into Elicitation Results (confirmed).
Purpose and Scope of Confirmation
The primary objective of Task 4.3 is to verify that the business analyst's recorded notes, summaries, and initial models accurately represent what stakeholders actually expressed during discovery activities. Furthermore, it ensures that findings across different elicitation sessions do not contain unresolved contradictions, omissions, or unverified assumptions.
+-----------------------------------------------------------------------------------+
| BABOK Task 4.3 Structure |
+-----------------------------------------------------------------------------------+
| INPUT: |
| * Elicitation Results (unconfirmed) |
| |
| ELEMENTS: |
| 1. Compare Elicitation Results Against Source Information |
| 2. Compare Elicitation Results Against Other Information |
| |
| OUTPUT: |
| * Elicitation Results (confirmed) |
+-----------------------------------------------------------------------------------+
The Two Core Elements of Task 4.3
1. Compare Elicitation Results Against Source Information
The business analyst checks whether the captured information accurately reflects the stakeholder's statements and intent:
- Fidelity Review: Reviewing interview transcripts, workshop visual captures, or prototype feedback with the specific stakeholders who provided the information.
- Feedback Confirmation Loops: Sending structured meeting summaries, visual user story maps, or recorded decision logs back to participants for explicit validation.
- Uncovering Misinterpretations: Correcting instances where domain jargon, technical acronyms, or ambiguous phrasing led the BA to document an inaccurate interpretation.
2. Compare Elicitation Results Against Other Information
Individual stakeholders see the organization through the lens of their specific departmental objectives. The business analyst must cross-reference findings across multiple sources:
- Cross-Session Reconciliation: Comparing notes from front-line customer service agents against executive management directives to identify operational disconnects.
- Artifact & Policy Alignment: Comparing stated requirements against enterprise architectural standards, corporate security policies, and regulatory statutes.
- Historical Consistency: Checking current findings against legacy system documentation, past project retrospectives, and audit logs.
Stated Wants vs. Actual Needs: The Iceberg Principle
A critical responsibility during Task 4.3 is distinguishing between what stakeholders state they want (superficial solution desires) and what they actually need (underlying business problems to solve).
+-----------------------------------------------------------------------------------+
| The Requirements Iceberg Principle |
+-----------------------------------------------------------------------------------+
| |
| ABOVE WATER (Stated Wants): |
| * "We need an Export to Excel button on every single screen." |
| * "We must keep our custom 14-field manual entry form exactly as is." |
| * "The system must generate a 50-page PDF report every Monday morning." |
| |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WATERLINE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| BELOW WATER (Actual Business Needs): |
| * Need real-time automated data reconciliation between ERP and CRM. |
| * Need to eliminate duplicate data entry and human transposition errors. |
| * Need automated exception alerting when daily transaction thresholds fail. |
| |
+-----------------------------------------------------------------------------------+
When confirming results, the business analyst asks clarifying questions to unearth implicit assumptions and root needs:
- "You mentioned needing a weekly 50-page PDF report. What specific decisions do you make based on those numbers, and could an automated real-time alert fulfill that operational need?"
Clarifying the Confusion: The "Three V's" of Business Analysis
One of the most heavily tested areas on the CCBA exam is distinguishing between Confirming, Verifying, and Validating requirements.
| Phase | BABOK Task | Core Question Answered | Primary Focus |
|---|---|---|---|
| Confirm Elicitation Results | Task 4.3 (Elicitation & Collaboration) | "Did I accurately record and understand what the stakeholder communicated during our discovery sessions?" | Faithfulness to source dialogue, notes accuracy, cross-source consistency |
| Verify Requirements | Task 7.2 (RADD) | "Are the requirements specifications well-formed, unambiguous, complete, consistent, and testable?" | Structural quality, adherence to modeling standards, editorial correctness |
| Validate Requirements | Task 7.3 (RADD) | "Do these requirements deliver actual business value and align directly with our strategic goals and business case?" | Business value alignment, goal achievement, return on investment |
Techniques for Confirming Elicitation Results
- Document Analysis: Used to cross-reference unconfirmed elicitation notes against published regulations, operational logs, and contracts to detect factual inaccuracies.
- Interviews: Used to conduct focused one-on-one follow-up sessions with specific stakeholders to clarify ambiguous statements, resolve contradictions, or drill into unstated assumptions.
- Reviews: Formal or informal sessions (such as peer reviews, desk checks, or email sign-offs) where stakeholders review written summaries or visual drafts to confirm accuracy.
- Workshops: Used when multiple stakeholder groups provide conflicting accounts of a business process. Bringing stakeholders together in a structured reconciliation workshop facilitates open debate and consensus on the single source of truth.
Enterprise Scenario: Healthcare Claims Discrepancy
During discovery for an automated healthcare claims adjudication engine, the business analyst encounters conflicting elicitation results:
- Claims Processors (Operational SMEs): Stated that when a diagnostic code is ambiguous, they routinely apply an internal manual override rule based on physician history.
- Compliance Officers (Regulatory SMEs): Stated during interviews that any ambiguous diagnostic code must trigger a formal query back to the medical provider under federal billing compliance rules.
BA Action in Task 4.3:
- The BA documents both unconfirmed findings and compares them during cross-session reconciliation.
- Recognizing the direct contradiction and compliance risk, the BA convenes a focused review workshop with both the lead Claims Processor and the Compliance Officer.
- During the workshop, the compliance officer explains the legal liability of manual overrides, while the claims processor highlights that provider queries take 14 days and stall billing metrics.
- Outcome: The team agrees on a confirmed elicitation result: "The system shall automatically route ambiguous diagnostic codes to a dedicated clinical coder queue for expedited provider verification within a 48-hour SLA."
[!TIP] CCBA Exam Tip: Confirmation does not have to be a formal, signed document. While predictive environments may use formal sign-offs, adaptive/agile environments frequently use informal confirmation methods, such as an email summary, an updated acceptance criteria checklist on a Jira story, or a verbal check at the conclusion of a sprint planning session.
[!WARNING] CCBA Exam Trap: Never assume that silence implies agreement. If you send an elicitation summary to 20 stakeholders and receive zero replies, the results are not confirmed. A business analyst must obtain active confirmation through explicit feedback mechanisms.
A business analyst has completed five discovery workshops for a new customer onboarding portal and is reviewing the captured notes, process diagrams, and decision tables. What is the fundamental difference between the analyst performing Task 4.3 (Confirm Elicitation Results) versus Task 7.2 (Verify Requirements)?
During a requirements elicitation effort for an e-commerce checkout overhaul, the Customer Support Manager asserts that customer service reps must have the capability to instantly issue full cash refunds without supervisor approval. However, the Risk and Fraud Specialist states that all refunds exceeding $100 require dual-manager authorization. What should the business analyst do NEXT to confirm elicitation results?
A business analyst emails a 25-page meeting minutes and requirements summary to a group of 15 stakeholders following a week of intensive workshops. After five days, no stakeholder has replied or provided feedback. How should the analyst interpret this situation under BABOK v3 guidelines?