Business Analysis 101: Elicitation and Collaboration - Confirming Elicitation Results, Scribe, Stakeholder Validation

What This Is

Confirming elicitation results (sometimes called scribing or stakeholder validation) is the activity where the Business Analyst reviews what was captured during elicitation (interviews, workshops, surveys, etc.) with the stakeholders to make sure the information is accurate, complete, and understood. It closes the loop on the “listen?and?record” phase and creates a shared baseline before the requirements move forward.

Real?world example: A financial services firm is redesigning its insurance?claims process. After a series of workshops with claims adjusters, policy?holders, and IT staff, the BA drafts a set of process maps and user stories. The BA then meets the same group (and a few senior managers) to walk through each artifact, capture any corrections, and obtain formal sign?off that the captured information truly reflects what was intended.

Key Terms & Techniques

• Scribe – The act of documenting elicitation output (notes, models, stories). Knowledge Area: Requirements Elicitation and Collaboration; Deliverable: Raw notes, meeting minutes, or transcription.
• Stakeholder Validation – A formal review with stakeholders to confirm that captured information is correct and complete. Knowledge Area: Requirements Elicitation and Collaboration; Deliverable: Validation sign?off matrix or approved artefacts.
• Baseline – A frozen version of a set of requirements that have been approved and can be used for change control. Knowledge Area: Requirements Life Cycle Management; Deliverable: Baseline document or version?controlled repository.
• Traceability Matrix – A table linking each requirement to its source, design, test case, and any other artefact. Knowledge Area: Requirements Life Cycle Management; Deliverable: Requirements traceability matrix (RTM).
• Walk?through – An informal, step?by?step review of artefacts with stakeholders to surface misunderstandings. Knowledge Area: Requirements Elicitation and Collaboration; Deliverable: Walk?through agenda, feedback log.
• Review Technique – Any structured method (e.g., Peer Review, Inspection, Walk?through) used to examine artefacts for defects. Knowledge Area: Solution Evaluation (when reviewing a proposed solution) or Requirements Elicitation and Collaboration (when reviewing requirements).
• MoSCoW Prioritization – Classifies requirements as Must, Should, Could, Won’t. Helpful during validation to confirm agreed priorities. Knowledge Area: Requirements Analysis and Design Definition; Deliverable: Prioritization matrix.
• Decision?Making Technique – Tools such as Voting, Multi?criteria Decision Analysis (MCDA), or Weighted Scoring used to resolve conflicts uncovered during validation. Knowledge Area: Requirements Elicitation and Collaboration; Deliverable: Decision?record.
• Change Control Process – The formal procedure for handling any modifications after validation. Knowledge Area: Requirements Life Cycle Management; Deliverable: Change request form, impact analysis.
• Stakeholder Map – Visual representation of stakeholder influence and interest, used to select the right people for validation. Knowledge Area: Stakeholder Analysis (part of Business Analysis Planning and Monitoring); Deliverable: Stakeholder map/chart.

Step?by?Step / Process Flow

1. Prepare the Validation Package – Gather all elicitation artefacts (notes, models, user stories, process maps) and organize them by stakeholder group. Attach a validation agenda that lists what will be reviewed and the expected outcome (e.g., sign?off, comment).
2. Invite the Right Stakeholders – Use the Stakeholder Map to select representatives who have authority, expertise, and interest. Send meeting invites with the validation package attached at least 48?hours in advance.
3. Conduct the Validation Session – Lead a walk?through or review technique (e.g., peer review). Read each artefact aloud, ask “Does this reflect what you said?” Capture any clarifications, disagreements, or new ideas on a feedback log.
4. Resolve Open Issues – Apply a decision?making technique (voting, MCDA) to settle conflicts. If a requirement’s priority is disputed, run a quick MoSCoW session with the group. Document the decision and update the artefact immediately.
5. Obtain Formal Sign?off – Have each stakeholder sign (or electronically approve) the validation sign?off matrix indicating “Approved”, “Approved with comments”, or “Rejected”. Store the signed matrix in the requirements repository.
6. Baseline the Validated Requirements – Freeze the approved version, create a baseline, and update the traceability matrix. Communicate the baseline to the project team and trigger the change control process for any future modifications.

Common Mistakes

Certification Exam Tips

Quick Check Questions

1. Scenario: After a series?of interviews, the BA drafts a process flow diagram. The claims manager says the diagram is missing a critical exception step. Which activity should the BA perform next?
   Answer: Conduct a walk?through with the claims manager to capture the missing step and update the diagram.
   Why: Walk?throughs are the BABOK?recommended technique for confirming details during validation.

2. Scenario: A stakeholder group disagrees on the priority of three new features. The BA needs a quick, consensus?based decision. Which technique is most suitable?
   Answer: Use MoSCoW prioritization combined with a voting decision?making technique.
   Why: MoSCoW provides a clear priority framework; voting resolves the disagreement efficiently.

3. Scenario: The BA has a signed validation matrix, but the project sponsor later requests a change to a requirement that was already baselined. What is the correct next step?
   Answer: Initiate a change control request and perform an impact analysis before altering the baseline.
   Why: Baselines are immutable until a formal change control process is completed, per the Requirements Life Cycle Management knowledge area.

Last?Minute Cram Sheet (10 One?liners)

1. Elicitation = activity; Requirements = output. (BA elicits information, not requirements.)
2. Validate = review artefacts with stakeholders; Baseline = freeze approved version.
3. Stakeholder Map lives in Business Analysis Planning & Monitoring; it guides who attends validation.
4. Walk?through and Inspection are review techniques; the former is informal, the latter is formal.
5. MoSCoW belongs to Requirements Analysis & Design Definition – used for prioritization during validation.
6. Traceability Matrix links each requirement to its source, design, test case, and change request.
7. Sign?off Matrix = the official validation deliverable; must be signed by each stakeholder group.
8. Change Control Process is part of Requirements Life Cycle Management – only way to alter a baseline.
9. Decision?Making Techniques (Voting, MCDA, Weighted Scoring) resolve conflicts uncovered in validation.
10. Baseline-Traceability-Change Control is the sequential flow after validation; remember the order for exam questions.