Specialist Business Analyst

An autonomous agent that bridges business requirements and technical implementation — gathering requirements, writing user stories, creating process flows, and translating stakeholder needs into actionable specifications for development teams.

When to Use This Agent

Choose Specialist Business Analyst when:

• You need to translate vague business requirements into structured user stories
• Stakeholders have conflicting priorities that need alignment
• You want to create process flow diagrams and data flow models
• You need requirements traceability from business goals to technical specs

Consider alternatives when:

• You need market research and competitive analysis (use a market researcher agent)
• You need financial modeling and projections (use a financial analyst)
• Requirements are already clear and you need implementation (use a developer agent)

Quick Start

Copy
# .claude/agents/business-analyst.yml
name: specialist-business-analyst
description: Translate business needs into technical specifications
agent_prompt: |
  You are a Business Analyst. When gathering and analyzing requirements:

  1. Identify stakeholders and their goals
  2. Elicit requirements through structured questioning
  3. Write user stories with acceptance criteria (Given/When/Then)
  4. Create process flows and data models
  5. Identify edge cases and business rules
  6. Prioritize using MoSCoW or RICE framework
  7. Document non-functional requirements

  Always distinguish between what stakeholders WANT vs what they NEED.
  Focus on the problem before jumping to solutions.

Example invocation:

Copy
claude "Analyze requirements for adding a subscription billing feature to our SaaS product"

Sample requirements output:

Requirements Analysis — Subscription Billing
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Stakeholders:
  - Product: Wants flexible pricing tiers
  - Finance: Needs revenue recognition and tax compliance
  - Engineering: Wants minimal maintenance overhead
  - Customers: Want transparent billing with no surprises

User Stories (prioritized):

[MUST] US-001: Subscribe to a plan
  As a customer, I want to choose a pricing plan and enter payment
  Given I am on the pricing page
  When I select "Pro Plan" and enter my card details
  Then my subscription is activated immediately
  And I receive a confirmation email with invoice

[MUST] US-002: Upgrade/downgrade plan
  As a customer, I want to change my plan mid-cycle
  Given I have an active Basic subscription
  When I upgrade to Pro
  Then I am charged the prorated difference immediately
  And my new features are available instantly

[SHOULD] US-003: Pause subscription
  As a customer, I want to pause billing without losing my data
  ...

Business Rules:
  BR-001: Proration is calculated daily, not monthly
  BR-002: Downgrades take effect at end of billing cycle
  BR-003: Failed payment retries: 3 attempts over 7 days
  BR-004: After 3 failed attempts, subscription is paused (not cancelled)

Core Concepts

Requirements Elicitation Framework

Technique	When to Use	Output
Stakeholder Interviews	Initial discovery	Goals, constraints, priorities
User Story Mapping	Feature planning	Prioritized backlog
Process Modeling	Complex workflows	BPMN/flowcharts
Prototyping	UI-heavy features	Wireframes, mockups
Data Modeling	Data-centric features	ERD, data dictionary

User Story Template

Copy
## US-{ID}: {Title}

**Priority:** Must/Should/Could/Won't (MoSCoW)
**Points:** S/M/L/XL
**Epic:** {Parent Epic}

**As a** {user role}
**I want** {capability}
**So that** {business value}

### Acceptance Criteria

**Scenario 1: Happy path**
  Given {precondition}
  When {action}
  Then {expected result}

**Scenario 2: Edge case**
  Given {different precondition}
  When {action}
  Then {alternative result}

### Business Rules
- BR-{ID}: {rule description}

### Non-Functional Requirements
- Performance: {specific metric}
- Security: {specific requirement}

### Out of Scope
- {Explicitly excluded items}

Prioritization Framework (RICE)

RICE Score = (Reach × Impact × Confidence) / Effort

Feature               Reach  Impact  Confidence  Effort  RICE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Subscription billing  5000   3       0.9         3       4500
Plan upgrade/down     3000   2       0.8         2       2400
Pause subscription    1000   1       0.7         1       700
Gift subscriptions    500    2       0.5         3       167

Impact: 3=massive, 2=high, 1=medium, 0.5=low
Confidence: 0.5-1.0 (how sure are we about estimates)
Effort: person-months

Configuration

Option	Type	Default	Description
framework	string	"agile"	Methodology: agile, waterfall, lean
prioritization	string	"rice"	Method: rice, moscow, kano, weighted
storyFormat	string	"gherkin"	Acceptance criteria: gherkin, checklist
includeNFR	boolean	true	Include non-functional requirements
diagramFormat	string	"mermaid"	Diagram format: mermaid, plantuml
traceability	boolean	true	Link requirements to business goals

Best Practices

1. Separate the problem from the solution — Stakeholders often describe solutions ("we need a dropdown menu") when they should describe problems ("users struggle to find their preferred category"). Always ask "Why do you need this?" to get to the underlying problem before proposing solutions.

2. Write acceptance criteria before development starts — Vague acceptance criteria lead to rework. "Given/When/Then" format forces specificity. If you cannot write a concrete acceptance criterion, the requirement is not well understood enough to build.

3. Include out-of-scope items explicitly — Requirements documents that only list what IS included leave room for scope creep. Explicitly listing what is NOT included ("Gift subscriptions are out of scope for v1") prevents misunderstandings and keeps the team focused.

4. Prioritize ruthlessly with data, not opinions — Use RICE scoring to quantify priority based on reach, impact, confidence, and effort. Data-driven prioritization resolves stakeholder disagreements objectively. If two stakeholders disagree, compare RICE scores rather than relying on who speaks louder.

5. Validate requirements with real users before building — Create a prototype or mockup and test it with 5 actual users before writing code. Five user tests catch 80% of usability issues. Building the wrong thing is the most expensive mistake in software development.

Common Issues

Stakeholders keep adding requirements mid-sprint — Without a clear change management process, new requirements disrupt ongoing work. Establish a rule: new requirements go to the backlog and are prioritized in the next sprint planning. Only critical bugs or regulatory requirements can be added mid-sprint, and something else must be removed to compensate.

Requirements are too vague to estimate or build — User stories like "make the dashboard better" are not actionable. Apply the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, Testable. If a story fails any criterion, break it down further. "Add a revenue chart to the dashboard showing last 30 days with daily granularity" is estimable and testable.

Business rules conflict with each other — "Downgrades take effect immediately" conflicts with "customers should not lose features mid-cycle." Surface contradictions explicitly in the requirements document and escalate to stakeholders for a decision. Document the resolution as a business rule with the date and decision-maker.