Business Analyst

Business Analyst

Overview

This skill covers the structured practice of business analysis—translating business problems into clear requirements, mapping current and future-state processes, identifying gaps, managing stakeholder alignment, and producing the documentation (BRDs, use cases, process maps) that enables successful project delivery. It bridges the gap between business needs and technical or operational solutions.

When to Use

• You need to document what a system or process must do (requirements gathering)
• You're mapping a current business process to find inefficiencies
• You need to perform a gap analysis between current and desired state
• You're building a Business Requirements Document (BRD)
• You need to identify and manage project stakeholders
• Writing use cases or functional specifications

When NOT to Use

• Writing user stories and sprint backlog items (use product-manager skill)
• Conducting qualitative UX research (use ux-researcher skill)
• Technical architecture or system design
• Financial modeling or ROI calculations (use a finance skill)
• Project scheduling and resource planning (use a PM tool)

Quick Reference

Instructions

Step 1: Stakeholder Identification and Management

Stakeholder register:

Power-Interest grid:

• High Power + High Interest → Manage closely (key decision makers)
• High Power + Low Interest → Keep satisfied (executive sponsors)
• Low Power + High Interest → Keep informed (operational users)
• Low Power + Low Interest → Monitor (peripheral stakeholders)

RACI matrix for project roles:

Step 2: Requirements Gathering Techniques

Technique 1 — Structured Interviews: Run 45–60 minute sessions with key stakeholders. Use open-ended questions:

• "Walk me through how you currently handle X from start to finish."
• "What are the biggest pain points with the current process?"
• "What would have to be true for this to be considered a success?"
• "If you could change one thing, what would it be?"
• "What constraints do we need to work within (regulatory, technical, budget)?"

Technique 2 — Requirements Workshop (JAD session):

• Invite 6–10 stakeholders representing all affected groups
• 2–4 hour structured session with a facilitator
• Use whiteboards or collaborative tools (Miro, Mural)
• Activities: process walkthroughs, affinity mapping, scenario walkthroughs

Technique 3 — Observation (Process Shadowing):

• Spend 1–2 hours observing end users performing the actual process
• Note what they do, workarounds they use, and pain points
• Often reveals requirements that no one thinks to mention in interviews

Technique 4 — Document Analysis:

• Review existing SOPs, training materials, system documentation
• Analyze reports, dashboards, and data that support the current process
• Review help desk tickets for common user problems

Step 3: Business Requirements Document (BRD) Template

Document Title: [Project Name] Business Requirements Document Version: 1.0 | Date: [Date] | Status: Draft / In Review / Approved Author: [BA Name] | Sponsor: [Name]

1. Executive Summary One paragraph: business problem, proposed solution, expected business value, and scope.

2. Business Objectives

3. Project Scope In Scope:

• [List what the project will address]

Out of Scope:

• [List what is explicitly excluded to prevent scope creep]

4. Current State (AS-IS) Overview Brief description of how the process/system works today.

• Current pain points (supported by data where possible)
• Volume and frequency: "200 orders processed daily by 5 team members"

5. Future State (TO-BE) Overview Description of the desired end state and how it differs from today.

6. Business Requirements

7. Assumptions and Dependencies

• Assumption: ERP system will provide API access for integration
• Dependency: IT infrastructure upgrade must complete before this project starts

8. Constraints

• Budget: $150,000 total project cost
• Timeline: Must launch before Q4 peak season
• Regulatory: Must comply with SOC 2 Type II requirements

9. Risks

10. Approval

Step 4: Process Mapping (AS-IS and TO-BE)

AS-IS Process Map — document the current state exactly as it is:

• Use swimlane diagrams (one lane per role/system)
• Map every step, decision point, and handoff
• Note pain points with 🔴 and workarounds with ⚠️
• Capture time and volume data at key steps

Swimlane notation (text format):

Customer → [Submit order form] → [Order lands in shared inbox] 
                                          ↓
Sales Rep → [Manually copy to ERP] → [Check inventory] 
                                          ↓ (if in stock)
Warehouse → [Pick and pack] → [Update ERP] → [Email customer]
                                          ↓ (if out of stock)
Sales Rep → [Call customer] → [Offer alternative] → [Cancel or modify]

Pain points: ⚠️ Manual ERP entry takes 15 min/order; 🔴 3.2% error rate on data entry

TO-BE Process Map — design the improved future state:

• Eliminate the waste/pain points identified in AS-IS
• Show automation, integration, and self-service where appropriate
• Include new systems or tools introduced

Customer → [Submit order on web portal] → [System auto-validates] 
                                                    ↓ (auto-routed)
ERP System → [Inventory check (real-time)] → [Confirmation email auto-sent]
                                                    ↓ (if in stock)
Warehouse → [Pick slip auto-generated] → [Scan to update status] → [Auto-notification]
                                                    ↓ (if out of stock)
ERP System → [Auto-email with alternatives] → [Customer self-serves]

Step 5: Gap Analysis

A gap analysis identifies the distance between current state and desired state.

Gap analysis matrix:

Step 6: Writing Use Cases

A use case describes how a user achieves a goal through a system.

Use Case Template:

Use Case ID: UC-001
Use Case Name: Submit a New Customer Order
Actor: Sales Representative
Preconditions: Rep is logged into the system; Customer account exists
Trigger: Rep receives a customer purchase request

Main Success Scenario:
1. Rep selects "New Order" from the dashboard
2. System displays order form pre-populated with customer details
3. Rep enters product, quantity, and delivery date
4. System validates inventory availability in real time
5. Rep confirms and submits the order
6. System generates order confirmation number and emails customer
7. Use case ends

Alternative Flows:
4a. Product is out of stock:
   4a.1. System displays "Out of Stock" with expected restock date
   4a.2. Rep offers alternative or backorder option
   4a.3. If customer accepts backorder → continue step 5 with backorder flag

Exception Flows:
3a. Required fields missing:
   3a.1. System highlights missing fields with error message
   3a.2. Rep corrects and resubmits

Postconditions: Order is recorded in ERP; confirmation email sent to customer

Examples

Example 1: Write a Business Requirements Document for Order Processing Automation

Input: "Our order processing team manually enters 200 orders per day into our ERP. It takes 15 minutes per order, has a 3.2% error rate, and team members work overtime every peak season. We want to automate this."

BRD Executive Summary:

The Order Processing Automation project will eliminate manual order entry by integrating the customer-facing web portal directly with the ERP system. Currently, 200 daily orders require 15 minutes of manual data entry each, resulting in $180,000/year in processing labor cost and a 3.2% error rate that causes customer complaints and re-work. The automated system will reduce processing time to under 2 minutes per order, target a <0.5% error rate, and free 3 FTEs for higher-value work. Project scope includes web portal API integration, ERP workflow configuration, and automated customer notification. Out of scope: mobile app, EDI for supplier orders.

Key Business Requirements:

• BR-001: System shall automatically import all orders submitted via web portal into ERP within 60 seconds — Must Have
• BR-002: System shall validate required fields and inventory availability before order confirmation — Must Have
• BR-003: Customer shall receive automated order confirmation email with order number within 2 minutes — Must Have
• BR-004: System shall flag and route orders with validation errors to a supervisor queue — Must Have
• BR-005: Reports shall be auto-generated every Monday 8am without IT involvement — Should Have

Example 2: Map a Customer Onboarding Process

Input: "New customers take 3 weeks to become active. We want to understand why and fix it."

AS-IS discovery (from interviews + observation):

• Step 1: Customer signs contract (Day 0) → sent to sales rep via email
• Step 2: Sales rep manually emails implementation team (Day 1–2) — ⚠️ delay: emails buried
• Step 3: Implementation team schedules kickoff (Day 3–7) — 🔴 bottleneck: team at capacity
• Step 4: Kickoff call → IT team creates account (Day 8) — ⚠️ manual account creation = 24–48 hrs
• Step 5: Customer given credentials; begins setup (Day 10–14) — no guidance = high dropout
• Step 6: Training session scheduled (Day 15–21) — 🔴 bottleneck: only 2 trainers available

Gap identified: 7 days of delay from manual handoffs and queue waits; no self-service during setup.

TO-BE redesign:

• Contract signed → auto-triggers CRM workflow → implementation team auto-notified + calendar invite auto-sent (eliminates 1–2 day delay)
• Account provisioned automatically via API (eliminates 24–48 hr delay)
• Self-guided setup wizard with in-app tooltips (customer can start before training)
• On-demand training video library (reduces dependency on 2 live trainers)
• Target: 3 weeks → 5 business days

Gap analysis output:

Best Practices

• Document the AS-IS process before designing the TO-BE — you cannot improve what you don't understand
• Get sign-off on requirements before solution design begins — changing requirements mid-build is 10× more expensive
• Write requirements as behaviors ("System shall…") not as solutions ("System will have a button that…")
• Trace requirements back to business objectives — if a requirement doesn't support an objective, question it
• Use "shall" for mandatory requirements and "should" for desirable ones
• Walk through requirements with end users, not just management — managers often don't know the actual workflow

Common Mistakes

• Jumping to solution design before understanding the problem
• Writing vague requirements: "The system should be user-friendly" (untestable)
• Ignoring non-functional requirements (performance, security, availability)
• Getting scope creep from "nice to have" requests presented as requirements
• Skipping stakeholder identification and then facing surprises at sign-off
• Treating the BRD as a one-time artifact — requirements change; version and update it

Tips & Tricks

• Use "what, not how" as your mantra: requirements describe what the system must do, not how to build it
• The best requirement elicitation question: "And then what happens?" — keeps uncovering steps
• Silent workflow walk-through: ask stakeholders to do their job while you observe without interrupting, then ask questions at the end
• A one-page process map on a whiteboard is worth 10 pages of text description
• Prototype or mockup + structured walkthrough surfaces more requirements than any document review

Related Skills

• product-manager
• ux-researcher
• okr-planner
• meeting-facilitator