Business Analysis Skill

Patterns for requirements elicitation, BRDs, process analysis, and stakeholder alignment.

Business Analysis Deliverables

Requirements Hierarchy

Business Requirements (WHY)
    └── Stakeholder Requirements (WHO needs WHAT)
        └── Solution Requirements
            ├── Functional (WHAT it does)
            └── Non-Functional (HOW WELL it does it)
                └── Transition Requirements (HOW we get there)

BRD Structure

Standard Sections

1. •Executive Summary — One-page overview for executives
2. •Business Objectives — Measurable goals (SMART)
3. •Scope — In scope, out of scope, boundaries
4. •Stakeholders — Who's involved, their interests
5. •Current State — As-is process, pain points
6. •Future State — To-be vision, benefits
7. •Functional Requirements — What the solution must do
8. •Non-Functional Requirements — Quality attributes
9. •Assumptions & Constraints — Known limitations
10. •Dependencies — External factors
11. •Risks — What could go wrong
12. •Glossary — Term definitions

Requirements Writing

SMART Criteria

Good vs. Bad Requirements

Requirement Attributes

Elicitation Techniques

Technique Selection

Interview Best Practices

• •Prepare questions in advance
• •Start broad, then specific
• •Use open-ended questions
• •Listen more than talk (80/20)
• •Probe with "Why?" and "How?"
• •Summarize and confirm understanding
• •Document immediately after

Workshop Facilitation

Use Case Development

Use Case Template

Use Case: [UC-001] [Name]
Actor: [Primary actor]
Precondition: [What must be true before]
Trigger: [What initiates the use case]

Main Flow:
1. Actor does X
2. System responds with Y
3. ...

Alternative Flows:
2a. If condition, then...

Exception Flows:
2b. If error, then...

Postcondition: [What is true after]
Business Rules: [Applicable rules]

Use Case Levels

Process Analysis

Current State Analysis

1. •Map as-is process (BPMN, swimlane)
2. •Identify pain points
3. •Measure current performance
4. •Find root causes
5. •Quantify improvement opportunity

Process Mapping Notations

SIPOC Template

Gap Analysis

Gap Analysis Framework

Current State → Gap → Future State
     │           │          │
     ▼           ▼          ▼
  As-Is     What needs   To-Be
  Process   to change    Vision

Gap Categories

Acceptance Criteria

Gherkin Format

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

Acceptance Criteria Checklist

• • Testable — Can write a test case
• • Clear — Unambiguous language
• • Complete — Covers happy path and edges
• • Independent — Doesn't require other criteria
• • Valuable — Ties to user need

Traceability

Traceability Matrix

Traceability Benefits

• •Ensure all requirements implemented
• •Impact analysis for changes
• •Test coverage verification
• •Audit compliance evidence

Prioritization Techniques

MoSCoW

Value vs. Effort Matrix

High Value │ Quick Wins │ Major Projects │
           │ (Do first) │ (Plan carefully)│
Low Value  │ Fill-ins   │ Avoid           │
           │ (If time)  │ (Don't do)      │
           └────────────┴─────────────────┘
             Low Effort   High Effort

Kano Model

Common BA Pitfalls

Synapses

High-Strength Connections

• •[project-management] (High, Informs, Forward) — "Requirements feed project scope"
• •[change-management] (High, Receives, Backward) — "Change impact on requirements"

Medium-Strength Connections

• •[root-cause-analysis] (Medium, Uses, Forward) — "Problem analysis for requirements"
• •[testing-strategies] (Medium, Enables, Forward) — "Requirements enable test design"

Supporting Connections

• •[architecture-refinement] (Low, Informs, Forward) — "Requirements shape architecture"
• •[writing-publication] (Low, Uses, Forward) — "Clear documentation writing"