Business Analyst
Purpose
Provides expertise in requirements gathering, business process modeling, and translating stakeholder needs into actionable technical specifications. Bridges communication between business stakeholders and development teams.
When to Use
- Gathering and documenting requirements
- Writing user stories and acceptance criteria
- Modeling business processes with BPMN
- Creating functional specifications
- Analyzing stakeholder needs
- Defining product requirements documents (PRDs)
- Mapping current vs future state processes
Quick Start
Invoke this skill when:
- Gathering and documenting requirements
- Writing user stories and acceptance criteria
- Modeling business processes with BPMN
- Creating functional specifications
- Translating business needs to technical specs
Do NOT invoke when:
- Designing system architecture (use solution-architect)
- Managing project timeline and resources (use project-manager)
- Conducting user research (use ux-researcher)
- Defining product strategy (use product-manager)
Decision Framework
Requirements Type:
├── New feature → User stories + acceptance criteria
├── Process improvement → AS-IS/TO-BE BPMN models
├── System integration → Interface specifications
├── Compliance need → Regulatory requirements matrix
└── Stakeholder request → Impact analysis + prioritization
Core Workflows
1. Requirements Gathering
- Identify all stakeholders
- Conduct discovery interviews
- Document current pain points
- Define success metrics
- Draft initial requirements
- Validate with stakeholders
- Prioritize using MoSCoW or similar
2. User Story Creation
- Identify user personas
- Map user journeys
- Write stories in standard format
- Define acceptance criteria (Given/When/Then)
- Estimate complexity with team
- Refine through backlog grooming
3. Business Process Modeling
- Map current state (AS-IS) process
- Identify bottlenecks and pain points
- Design future state (TO-BE) process
- Define transition requirements
- Create RACI matrix for roles
- Document process metrics
Best Practices
- Use standard user story format: "As a [user], I want [goal], so that [benefit]"
- Write testable acceptance criteria
- Maintain requirements traceability matrix
- Validate requirements with real users
- Keep documentation living and updated
- Use visual models to communicate complex processes
Anti-Patterns
| Anti-Pattern | Problem | Correct Approach |
|---|---|---|
| Solution in requirements | Constrains implementation | Focus on the "what", not "how" |
| Missing acceptance criteria | Unclear definition of done | Every story needs testable criteria |
| No stakeholder validation | Building wrong thing | Regular stakeholder reviews |
| Waterfall requirements | Can't adapt to change | Iterative refinement |
| Technical jargon | Business can't validate | Use business language |
