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

Task	Technique	Output
Elicit requirements	Interviews, workshops, observation	Requirements list
Document requirements	BRD template	Business Requirements Document
Map current state	Swimlane diagram, flowchart	AS-IS process map
Design future state	TO-BE process map	Process redesign
Find gaps	Gap analysis matrix	Gap analysis report
Manage stakeholders	RACI / Power-Interest grid	Stakeholder register
Document user interactions	Use case format	Use Case document
Prioritize requirements	MoSCoW method	Prioritized requirements
Validate requirements	Walkthrough, prototype review	Sign-off document

Instructions

Step 1: Stakeholder Identification and Management

Stakeholder register:

Stakeholder	Role	Interest Level	Influence Level	Stance	Engagement Strategy
VP Operations	Executive sponsor	High	High	Champion	Weekly status briefing
IT Director	Technical owner	High	High	Neutral	Bi-weekly architecture review
Customer Service Mgr	Process owner	High	Medium	Skeptic	Involve in requirements workshop
End users	Operators	Medium	Low	Unaware	Survey + demo sessions

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:

Activity	Business Sponsor	BA	IT Lead	Process Owner
Define requirements	A	R	C	C
Approve BRD	A	R	I	I
Design solution	I	C	R	C
Test & validate	I	C	R	A
Sign off to launch	A	C	C	R
(R=Responsible, A=Accountable, C=Consulted, I=Informed)

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

Objective	Success Metric	Target	Timeline
Reduce order processing time	Avg processing time	From 4 hours to 30 min	By Q3
Eliminate manual data entry errors	Error rate	From 3.2% to <0.5%	By Q3

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

ID	Requirement	Priority	Source	Notes
BR-001	System must validate order completeness before submission	Must Have	Operations Mgr	Reduce downstream errors
BR-002	Automated email notification to customer upon order status change	Should Have	Customer Service	Reduce inbound call volume
BR-003	Ability to generate weekly summary reports without IT involvement	Should Have	VP Operations	Currently takes 4 hours/week

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

Risk	Likelihood	Impact	Mitigation
Data migration errors	High	High	Parallel run period of 4 weeks
User adoption resistance	Medium	Medium	Change management program

10. Approval

Role	Name	Signature	Date
Business Sponsor
IT Director

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:

Capability Area	Current State	Desired State	Gap	Priority	Action Required
Order validation	Manual check by rep	System validates automatically	Process + system gap	High	Build validation rules in ERP
Customer notification	Manual email by rep	Automated trigger	Automation gap	High	Configure email workflow
Reporting	Manual Excel export	Self-serve dashboard	Capability gap	Medium	Implement BI tool integration
Inventory visibility	Updated day-end batch	Real-time	Data gap	High	API integration with warehouse system

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:

Gap	Priority	Solution
Manual sales → implementation handoff	High	CRM workflow automation
Manual account creation	High	API provisioning
No self-service setup	Medium	In-app onboarding wizard
Training capacity constraint	Medium	Video library + recorded sessions

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

business-analyst