From sdlc-agents
Use this skill when working as a Business Analyst (the business-analyst role) — eliciting requirements from stakeholders, structuring requirements per BABOK v3 framework, classifying needs by type (Business / Stakeholder / Solution / Transition), and applying analysis techniques (5 Whys, MoSCoW, INVEST, Stakeholder Analysis). Read this skill before composing interview questions or filling the REQUIREMENTS document.
How this skill is triggered — by the user, by Claude, or both
Slash command
/sdlc-agents:babok-elicitationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill encodes a **focused subset of BABOK v3** (Business Analysis Body of Knowledge, IIBA, 3rd edition) for the the business-analyst agent. Full BABOK has 6 knowledge areas and 50+ techniques — we use only what produces value for a small-team SDLC pipeline.
This skill encodes a focused subset of BABOK v3 (Business Analysis Body of Knowledge, IIBA, 3rd edition) for the the business-analyst agent. Full BABOK has 6 knowledge areas and 50+ techniques — we use only what produces value for a small-team SDLC pipeline.
When you load this skill: treat its terminology and structure as the standard for REQUIREMENTS. Speak in BABOK terms (Business / Stakeholder / Solution / Transition requirements; Elicitation; Stakeholder Analysis), not improvised vocabulary.
| BABOK Knowledge Area | Use? | Why |
|---|---|---|
| Elicitation and Collaboration | ✅ core | the business-analyst's main job — extract truth from initiator |
| Requirements Analysis and Design Definition | ✅ core | Structuring elicited info into REQUIREMENTS |
| Requirements Lifecycle Management | ⚠️ light | Trace via Plane comment history; no formal versioning |
| Business Analysis Planning and Monitoring | ❌ skip | Solo-founder context; no separate planning role |
| Strategy Analysis | ❌ skip | Trim for now; revisit when product-strategy work emerges |
| Solution Evaluation | ❌ skip | Covered downstream by the reviewer (Final Reviewer) |
This is the single most useful BABOK insight for the business-analyst. Every requirement you elicit fits exactly one of these:
Higher-level needs of the enterprise. Why are we doing this? What business outcome do we expect?
Examples:
Failure mode: project starts without a business requirement → solution looks for a problem.
Needs of specific actors (users, operators, system administrators, business owners).
Examples:
Failure mode: missing actors → some role can't use the system. Always ask "who else?".
What the system must do (functional) and how well (non-functional).
Examples:
tracking_number exists in the order, the customer can click it on /account/orders/{id} and open external CDEK tracking page in a new tab."Failure mode: mixing FR and NFR; conflating "what" with "how it's built".
Temporary capabilities for moving from current to future state.
Examples:
tracking_number — backfill from external CDEK API in batched task"/api/v1/orders/legacy/ kept active for 30 days, returns deprecation header"enable_tracking rolled out to 10% → 50% → 100% over 3 days"Failure mode (most common): Transition Requirements forgotten entirely. Project ships, legacy data orphaned, users confused, rollback impossible.
Always explicitly ask: "What's needed to transition from today's state to this new state?"
BABOK lists 50+ techniques. These 7 cover 90% of the business-analyst's work:
Structured (you have a pre-written question list) or unstructured (open exploration). the business-analyst does structured interviews per phase — one phase = one focused question set.
Use when: the business-analyst's normal mode. Every interaction with the initiator is an interview.
Read existing documents (the draft, prior tickets, related issues, code comments).
Use when: the business-analyst starts every run with this — read root description + ALL comments before asking any new questions.
Generate alternative approaches without judgment. Useful for "could we also..." options.
Use when: the initiator is stuck on "how" but the "why" is clear. Offer 2–3 alternatives, let him pick.
Break a large capability into smaller sub-capabilities. Continue until each piece is testable.
Use when: scope feels too big to specify. "Order tracking" → "show tracking number" + "deep-link to carrier" + "auto-update on status change" + "notify customer".
5 Whys is the most accessible variant. Don't accept the first answer.
Example:
Use when: the draft sounds like a solution, not a need. Drill until you hit the actual pain.
Classify each requirement: Must / Should / Could / Won't.
Use when: scope creep risk. Early in interview, ask the initiator to MoSCoW the draft features.
List all actors. For each: their role, what they want, level of influence.
Format (the business-analyst's table):
| Stakeholder | Role | Needs | Influence |
|---|---|---|---|
| Customer | end user of storefront | self-serve order tracking | medium |
| Support team | operator | reduce ticket volume | low (consumer of value) |
| the initiator | initiator / product owner | fewer support escalations | high (decides scope) |
Use when: every Phase 1 (Vision & Stakeholders) must produce this.
When asking the initiator — group questions into ONE comment per run. Numbered, focused on the current phase only.
What about tracking number?
And cancellation flow?
And anything else for orders?
Reasons it's bad: vague, mixes scopes, no options for fast answers, no prioritization signal.
Phase 2 (Stakeholder Requirements). 3 questions:
1. **Customer perspective** — what does the customer want when checking order status?
A: just the carrier tracking number (link to CDEK)
B: carrier number + ETA + last-known location
C: full timeline (ordered → packed → shipped → out for delivery → delivered)
2. **Warehouse staff** — do they need an admin view of tracking numbers?
A: no, they only see waybills (out of scope here)
B: yes, list of orders with tracking_number for batch operations
C: yes, plus ability to manually edit tracking_number when CDEK API fails
3. **Support agents** — should the customer see tracking before status='shipped'?
A: only when status >= 'shipped' (avoids confusion)
B: always when tracking_number exists (some orders have it earlier)
Reasons it's good: scoped to the current phase, options are concrete, each question has clear options for fast reply, no scope leakage to other phases.
Next agent run integrates answers, advances to next phase or wraps up.
BABOK supports formal acceptance criteria. We use Gherkin-style (industry standard, machine-parseable):
Given <precondition>
When <action>
Then <observable result>
Bad acceptance: "Tracking number is displayed."
Good acceptance:
Given an order has tracking_number = "ABC123"
And the user is the order's customer
When the user opens /account/orders/{id}
Then "ABC123" is displayed
And clicking it opens https://cdek.ru/track/ABC123 in a new tab
Given an order has tracking_number = null
When the user opens /account/orders/{id}
Then the tracking section is hidden
Failure mode: vague acceptance ("works correctly", "is fast"). Reject and re-ask.
For each user story, validate:
If a story violates INVEST → split it (functional decomposition) or push to "Open questions".
INVEST is not BABOK proper — it's an Agile (XP) heuristic that BABOK references as a quality lens. We use it because user stories are central to Stakeholder Requirements.
The biggest failure mode of an LLM-based BA is sycophancy — accepting the initiator's draft as truth, extrapolating from it, and producing a clean-looking REQUIREMENTS document with zero Open Questions. Clean output ≠ good output. Silence ≠ confidence. Most often silence = "I didn't look hard enough".
Every phase, before composing section text, run this checklist. Treat it as a hard pre-flight gate, not a suggestion.
Skeptical, not cooperative. Your job is not to make the initiator feel heard — it's to find what's missing, ambiguous, or in tension before the system-analyst inherits a broken brief. If you finish a phase and you couldn't surface any concerns, the working assumption is "I didn't challenge hard enough" — not "the brief is watertight".
For the current phase's scope, list in your working notes:
A. What could be wrong (assumption challenge)
B. What's missing (gap detection)
C. What could quietly grow (scope-creep risk)
For each item: does the source (draft + comments + prior phases) unambiguously answer it?
If after the checklist you have zero OQs, your phase-completion comment MUST include a Pre-flight review paragraph naming:
Without this paragraph, OQ=0 is treated as failure-to-elicit, not success. Saying "no questions" is a stronger claim than asking 5 questions — back it up with evidence.
Research lens for why this matters and why default LLM behaviour fails here:
your project's plane-api.md (referenced from $KB_DIR/AGENTS.md) for protocol-level operations.artifact-templates skill for the canonical REQUIREMENTS structure.npx claudepluginhub volodchenkov/claude-sdlc-agents --plugin sdlc-agentsGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.