Business Analyst

Business Analyst

Overview

Run a structured business analysis workflow for requirements elicitation, process modeling, stakeholder alignment, and solution validation. This skill covers BRD/FRD creation, user stories, acceptance criteria, BPMN diagrams, gap analysis, and change impact assessment.

Features

• Requirements elicitation techniques (interviews, workshops, observation, document analysis)
• BRD and FRD document templates with section-by-section guidance
• User story writing with INVEST criteria and acceptance criteria patterns
• BPMN process modeling with swimlane diagrams
• Gap analysis framework and change impact assessment templates

Usage

1. Identify the user's BA need (requirements, process modeling, user stories, or solution validation) 2. Follow the corresponding workflow below 3. Produce structured outputs: BRD/FRD documents, user stories, BPMN diagrams, or gap analysis reports

Examples

• User: "Gather requirements for a new feature"

Agent: Runs Requirements Elicitation workflow, conducts stakeholder interviews, produces BRD with functional and non-functional requirements

• User: "Map our order fulfillment process"

Agent: Runs Process Modeling workflow, creates BPMN diagram with swimlanes, identifies bottlenecks and handoff points

• User: "Write user stories for login"

Agent: Runs User Story Writing workflow, produces stories with INVEST criteria and Given/When/Then acceptance criteria

When to Use

• Elicit and document business requirements (BRD, FRD, user stories)
• Map as-is/to-be processes and run gap or impact analysis
• Facilitate workshops and translate between business and technical teams
• Produce cost-benefit, SWOT, or root-cause analysis for business decisions

Workflow Selection

• User wants to gather or document requirements → Workflow 1: Requirements Elicitation
• User wants to map or improve a process → Workflow 2: Business Process Analysis
• User wants to evaluate a business decision → Workflow 3: Data-Driven Business Analysis
• User wants to produce documentation → Workflow 4: Documentation & Communication

When NOT to Use

• Dashboard design, metric catalogs, or analytical SQL → use bi-analyst
• Data platform or enterprise architecture decisions → use data-architect
• Cross-service system design, ADRs, architecture review → use senior-system-architecture
• Customer support SLAs, billing ops, or CS health scoring → use customer-ops-specialist
• Revenue recognition, month-end close, or ASC 606 contract analysis → use senior-revenue-accountant
• UX flows, wireframes, and design handoff → use product-designer
• Labeling/RLHF platform product roadmap and quality systems → use product-management-human-data-platform
• Cross-team program execution, RAID, exec status → use technical-program-manager
• MSA, SaaS, vendor/customer contract redlines → use commercial-counsel
• HR operational processes and employee lifecycle checklists → use people-operations-specialist
• Strategy, issue trees, steerCo business cases → use business-consultant
• Business model research, TAM, competitor monetization → use business-model-researcher

Core Workflows

1. Requirements Elicitation

Step-by-step process:

1. Prepare

• Review existing documentation, systems, and pain points
• Identify stakeholders (sponsors, users, implementers)
• Define scope boundaries (in-scope, out-of-scope)

2. Elicit

• Interview key stakeholders using open-ended questions
• Observe users in their current workflow (shadowing)
• Review existing reports, data, and system outputs
• Run workshops for complex or cross-functional needs

3. Analyze & consolidate

• Group requirements by theme (functional, non-functional, technical)
• Resolve conflicts between stakeholders
• Prioritize using MoSCoW or weighted scoring

4. Validate

• Walk through requirements with stakeholders
• Confirm understanding with prototypes or examples
• Get formal sign-off before proceeding

2. Business Process Analysis

Analysis workflow:

1. Map the current state (as-is)

• Identify actors, steps, decisions, and handoffs
• Note time spent, pain points, and error rates
• Document data inputs and outputs at each step

2. Identify gaps and inefficiencies

• Redundancies, manual workarounds, bottlenecks
• Missing integrations, duplicate data entry
• Compliance risks or audit gaps

3. Design the future state (to-be)

• Streamline or automate steps
• Eliminate non-value-add activities
• Define new roles, systems, and data flows

4. Plan the transition

• Phased rollout vs big-bang
• Change impact assessment
• Training and communication plan

3. Data-Driven Business Analysis

Analytical techniques:

4. Documentation & Communication

Key documents:

Data-Driven Business Analysis

Cost-Benefit Analysis

Simple ROI

ROI = (Benefit - Cost) / Cost × 100%

Multi-Year Analysis

Payback period: Year 1 (cumulative turns positive)

Cost Categories

Benefit Categories

SWOT Analysis

Template

Action mapping:

• Strengths + Opportunities → Invest/Grow
• Strengths + Threats → Defend
• Weaknesses + Opportunities → Fix gaps
• Weaknesses + Threats → Avoid/Mitigate

Root Cause Analysis

5 Whys

Problem: Orders are shipping late.

Why? → Warehouse backlog.
Why? → Picking takes longer than planned.
Why? → Items are not in expected locations.
Why? → Receiving team doesn't update bin locations.
Why? → No process requires bin location confirmation.

Root cause: Missing receiving process step.

Fishbone (Ishikawa) Diagram

Categories to investigate:

• People: Skills, training, staffing
• Process: Steps, handoffs, approvals
• Technology: Systems, integrations, data quality
• Data: Accuracy, timeliness, completeness
• Environment: Market, regulation, competition
• Materials: Suppliers, inputs, quality

Forecasting Techniques

Forecast accuracy metrics:

• MAPE (Mean Absolute Percentage Error): mean(|actual - forecast| / actual)
• Bias: Systematic over/under-forecasting

Benchmarking

Internal Benchmarking

Compare across teams, regions, or time periods

External Benchmarking

Benchmarking Steps

1. Define what to benchmark (KPI, process, cost) 2. Identify comparison sources 3. Normalize for scale/context 4. Identify gaps 5. Set improvement targets

Process Improvement

Lean Principles

1. Define value from customer perspective 2. Map value stream — every step from request to delivery 3. Create flow — eliminate waiting and batching 4. Establish pull — produce only what is needed 5. Pursue perfection — continuous improvement

Six Sigma DMAIC

Kaizen Event (Rapid Improvement)

• Duration: 3-5 days
• Team: 5-8 people from affected areas
• Output: Implemented improvements, documented new standard

Documentation & Communication

Business Requirements Document (BRD)

Template Structure

# [Project Name] — Business Requirements Document

## 1. Executive Summary
- Business problem and opportunity
- Proposed solution at a high level
- Expected benefits and success criteria

## 2. Business Objectives
| Objective | Metric | Target | Timeline |
|---|---|---|---|
| Reduce order processing time | Avg minutes per order | <5 min | 6 months |

## 3. Scope
### In Scope
- [Requirement area 1]
- [Requirement area 2]

### Out of Scope
- [Explicitly excluded item 1]

## 4. Stakeholders
| Role | Name | Responsibility |
|---|---|---|
| Project Sponsor | [Name] | Budget approval, escalation |
| Business Owner | [Name] | Requirements sign-off |
| End Users | [Group] | Validation, training |

## 5. Current State
[Process description, pain points, supporting data]

## 6. Future State
[Desired outcomes, process changes, user experience]

## 7. Functional Requirements
| ID | Requirement | Priority | Acceptance Criteria |
|---|---|---|---|
| FR-001 | [Description] | Must | [Measurable criteria] |

## 8. Non-Functional Requirements
- Performance: [e.g., page load <2s]
- Security: [e.g., SSO, role-based access]
- Availability: [e.g., 99.5% uptime]
- Compliance: [e.g., GDPR, SOX]

## 9. Constraints & Assumptions
- Budget limit: $XXX
- Timeline: Must launch by [date]
- Assumption: User volume will not exceed X

## 10. Risks
| Risk | Impact | Probability | Mitigation |
|---|---|---|---|
| Data migration delays | High | Medium | Start migration early, plan rollback |

## 11. Appendix
- Glossary
- Reference documents
- Approval signatures

Functional Requirements Document (FRD)

Template Structure

# [Project Name] — Functional Requirements Document

## 1. Introduction
- Purpose and audience (developers, QA, architects)
- Relationship to BRD

## 2. System Context
[Diagram showing system boundaries and interfaces]

## 3. Functional Requirements
### 3.1 [Feature Area]
#### FR-001: [Requirement name]
**Description:** [Detailed description]
**User stories:** [As a... I want... so that...]
**Acceptance criteria:**
- [Criterion 1]
- [Criterion 2]
**Business rules:**
- [Rule 1]
- [Rule 2]
**Data requirements:**
- Inputs: [Fields, sources]
- Outputs: [Fields, destinations]
**UI/UX notes:** [Wireframe references, interaction patterns]
**Error handling:** [Invalid input, system failure]

## 4. Data Dictionary
| Field | Type | Description | Source | Valid Values |
|---|---|---|---|---|
| customer_id | UUID | Unique customer identifier | CRM | Valid UUID format |

## 5. Interface Requirements
- API contracts
- File formats
- Integration touchpoints

## 6. Business Rules Engine
| Rule ID | Condition | Action | Priority |
|---|---|---|---|
| BR-001 | Order value > $10K | Require manager approval | High |

Presentation Framework

Pyramid Principle (Barbara Minto)

1. Start with the answer (main recommendation) 2. Group supporting arguments (3-5 key reasons) 3. Provide evidence (data, examples, logic)

SCQA for Business Presentations

• Situation: Context everyone agrees on
• Complication: The problem or change
• Question: What should we do?
• Answer: The recommendation with supporting data

Slide Structure

Slide 1: Title + Main Recommendation
Slide 2: The Problem (data + impact)
Slide 3: Options Considered
Slide 4: Recommended Approach + Why
Slide 5: Implementation Plan
Slide 6: Risks & Mitigation
Slide 7: Ask (decision, resources, next steps)

Business-Technical Translation

Common Translation Gaps

Glossaries

Maintain a shared glossary:

Communication Templates

Requirement Change Request

## Change Request

**Date:** [Date]
**Requested by:** [Name]
**Priority:** Low / Medium / High / Critical

**Current requirement:** [What exists]
**Proposed change:** [What should change]
**Business justification:** [Why]
**Impact on scope:** [Add / Remove / Modify]
**Impact on timeline:** [Days added/removed]
**Impact on cost:** [Additional budget needed]

**Approved by:** __________ **Date:** __________

Weekly Status Update

## [Project] Status — Week of [Date]

### Overall Health: 🟢 On Track / 🟡 At Risk / 🔴 Off Track

### This Week
- [Accomplishment 1]
- [Accomplishment 2]

### Next Week
- [Planned activity 1]

### Blockers
- [Blocker] — Owner: [Name]

### Decisions Needed
- [Decision] — From: [Stakeholder] — By: [Date]

Requirements & Process Analysis

Requirements Elicitation Techniques

Interview Guidelines

Before the interview:

• Send agenda and context 24 hours ahead
• Prepare 5-10 open-ended questions
• Identify the decision-maker vs. influencer vs. user

Sample questions:

• "Walk me through how you currently do X from start to finish."
• "What takes the most time or causes the most frustration?"
• "If you could wave a wand, what would change?"
• "What happens when this process breaks?"
• "Who else is involved, and what do they need?"

During the interview:

• Listen 80%, talk 20%
• Ask "why" at least 3 times (5 Whys technique)
• Capture exact quotes for later reference
• Sketch the process live if possible

After the interview:

• Send summary within 24 hours
• Confirm accuracy with the interviewee
• Log requirements in shared tracker

Prioritization Frameworks

MoSCoW

Weighted Scoring

Score = Σ (Criterion Weight × Rating)

Example criteria:

Process Modeling

BPMN 2.0 Core Elements

[Start Event] → [Task] → [Gateway (decision)] → [Task] → [End Event]
     ↓                                              ↑
   [Pool: Team A]                             [Pool: Team B]

As-Is vs To-Be Analysis Template

## Process: [Name]

### As-Is State
| Step | Actor | Time | Pain Point |
|---|---|---|---|
| 1. Receive request | Support | 5 min | Email, no tracking |
| 2. Log in system | Support | 10 min | Manual data entry |

**Issues identified:**
- Manual handoffs cause delays
- No visibility into status
- Duplicate data entry

### To-Be State
| Step | Actor | Time | Improvement |
|---|---|---|---|
| 1. Auto-create ticket | System | 0 min | Integration triggers ticket |
| 2. Route automatically | System | 0 min | Rules-based routing |

**Expected benefits:**
- 50% reduction in handling time
- Real-time status visibility
- Zero duplicate entry

Gap Analysis

Current vs Future State Matrix

Gap Resolution Strategies

User Story Format

Standard Template

As a [type of user],
I want [some goal],
so that [some reason/benefit].

Acceptance criteria (Given-When-Then):

Given [precondition]
When [action]
Then [expected result]

Example:

As a sales manager,
I want to see pipeline by stage and rep,
so that I can forecast revenue and coach underperformers.

Acceptance criteria:
Given I am on the sales dashboard
When I select a date range and team
Then I see pipeline value broken down by stage and rep
And I can drill into individual opportunities

INVEST Checklist (Good User Stories)

Workshop Facilitation

Workshop Types

Facilitation Tips

• Set ground rules: No devices, one conversation at a time, all ideas valid
• Use timeboxes: 10-15 min per activity
• Capture visibly: Whiteboard or shared screen
• Balance voices: Actively draw out quiet participants
• Park lot: Capture off-topic ideas for later
• Close with actions: Who does what by when

Tools & Frameworks

Requirements Management Tools

Excel for Business Analysis

Essential Functions

Analysis Templates

Stakeholder RACI Matrix:

          | Sponsor | PM | Dev | QA | BA |
Requirements | A/R   | C  | I   | I  | R  |
Sign-off     | A     | R  | C   | C  | R  |

A = Accountable, R = Responsible, C = Consulted, I = Informed

Risk Register:

Workshop Facilitation Tools

In-Person

• Whiteboard + markers (multiple colors)
• Sticky notes (3 colors minimum)
• Timer (visible to all)
• Parking flip chart

Remote

• Miro or Mural for collaborative whiteboard
• Zoom/Teams with breakout rooms
• Poll Everywhere or Mentimeter for voting
• Google Docs for live note-taking

Facilitation Techniques

Data Analysis Tools for BAs

BPMN Modeling Tools

BA Certification Paths

Communication Best Practices

Email

• Subject line = action + topic
• BLUF (Bottom Line Up Front) in first 2 sentences
• Bullets, not paragraphs
• Clear ask or decision needed

Meetings

• Agenda sent 24 hours ahead
• Start and end on time
• Document decisions and action items
• Follow-up email within 2 hours

Status Reporting

• Lead with health indicator (red/yellow/green)
• Focus on exceptions, not routine progress
• Quantify impact when possible
• Ask for help when blocked