| name | Business Analysis Skill |
| description | Patterns for requirements elicitation, BRDs, process analysis, and stakeholder alignment. |
Business Analysis Skill
Patterns for requirements elicitation, BRDs, process analysis, and stakeholder alignment.
Business Analysis Deliverables
| Deliverable | Purpose | Audience |
|---|
| Business Case | Justify investment | Executives, sponsors |
| BRD | Document requirements | All stakeholders |
| Functional Spec | Detail system behavior | Dev team, testers |
| Use Cases | Describe user interactions | Designers, developers |
| Process Maps | Visualize workflows | Process owners, analysts |
| Data Dictionary | Define data elements | Technical team |
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
- Executive Summary — One-page overview for executives
- Business Objectives — Measurable goals (SMART)
- Scope — In scope, out of scope, boundaries
- Stakeholders — Who's involved, their interests
- Current State — As-is process, pain points
- Future State — To-be vision, benefits
- Functional Requirements — What the solution must do
- Non-Functional Requirements — Quality attributes
- Assumptions & Constraints — Known limitations
- Dependencies — External factors
- Risks — What could go wrong
- Glossary — Term definitions
Requirements Writing
SMART Criteria
| Letter | Meaning | Test |
|---|
| S | Specific | Is it clear what's needed? |
| M | Measurable | Can we verify it's done? |
| A | Achievable | Is it realistic? |
| R | Relevant | Does it support objectives? |
| T | Time-bound | Is there a deadline? |
Good vs. Bad Requirements
| Bad | Problem | Better |
|---|
| "System should be fast" | Not measurable | "Page load < 2 seconds" |
| "Easy to use" | Subjective | "Complete task in < 3 clicks" |
| "Handle all cases" | Unbounded | "Support cases A, B, C" |
| "Similar to competitor" | Vague | "[Specific features listed]" |
| "Should probably..." | Uncertain | "Must" or "Should" (MoSCoW) |
Requirement Attributes
| Attribute | Purpose |
|---|
| ID | Unique identifier (REQ-001) |
| Description | What is required |
| Priority | MoSCoW or numeric |
| Source | Who requested it |
| Rationale | Why it's needed |
| Acceptance Criteria | How to verify |
| Dependencies | Related requirements |
| Status | Draft/Approved/Implemented |
Elicitation Techniques
Technique Selection
| Technique | Best For | Effort |
|---|
| Interviews | Deep understanding, complex topics | High |
| Workshops | Consensus, group decisions | Medium |
| Surveys | Broad input, quantitative data | Low |
| Observation | Understanding real workflows | High |
| Document Analysis | Existing systems, regulations | Low |
| Prototyping | Validating concepts, UI | Medium |
| Focus Groups | User perspectives, reactions | Medium |
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
| Phase | Activities |
|---|
| Open | Objectives, agenda, ground rules |
| Diverge | Brainstorm, generate options |
| Converge | Prioritize, decide |
| Close | Summarize, next steps, thank |
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
| Level | Scope | Example |
|---|
| Summary | Multiple sessions | "Manage Customer Account" |
| User Goal | One sitting | "Place Order" |
| Subfunction | Part of a step | "Validate Address" |
Process Analysis
Current State Analysis
- Map as-is process (BPMN, swimlane)
- Identify pain points
- Measure current performance
- Find root causes
- Quantify improvement opportunity
Process Mapping Notations
| Notation | Best For |
|---|
| BPMN | Detailed, technical processes |
| Swimlane | Cross-functional workflows |
| Value Stream | Lean analysis |
| SIPOC | High-level overview |
SIPOC Template
| S | I | P | O | C |
|---|
| Suppliers | Inputs | Process | Outputs | Customers |
| Who provides? | What's needed? | High-level steps | What's produced? | Who receives? |
Gap Analysis
Gap Analysis Framework
Current State → Gap → Future State
│ │ │
▼ ▼ ▼
As-Is What needs To-Be
Process to change Vision
Gap Categories
| Type | Examples |
|---|
| Process | Missing steps, manual work |
| Technology | System limitations |
| People | Skills, capacity |
| Data | Quality, availability |
| Policy | Rules, compliance |
Acceptance Criteria
Gherkin Format
Given [precondition]
When [action]
Then [expected result]
And [additional result]
Acceptance Criteria Checklist
Traceability
Traceability Matrix
| Req ID | Business Objective | Design | Test Case | Status |
|---|
| REQ-001 | OBJ-01 | DES-005 | TC-012 | Passed |
Traceability Benefits
- Ensure all requirements implemented
- Impact analysis for changes
- Test coverage verification
- Audit compliance evidence
Prioritization Techniques
MoSCoW
| Priority | Meaning | Guidance |
|---|
| Must | Critical for success | ~60% of effort |
| Should | Important, not critical | ~20% of effort |
| Could | Nice to have | ~20% of effort |
| Won't | Out of scope (this release) | Documented |
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
| Type | If Present | If Absent |
|---|
| Basic | Expected, no delight | Dissatisfied |
| Performance | More is better | Less is worse |
| Delighter | Unexpected joy | Not missed |
Common BA Pitfalls
| Pitfall | Prevention |
|---|
| Solution jumping | Ask "why" before "how" |
| Missing stakeholders | Stakeholder analysis early |
| Gold plating | Tie everything to objectives |
| Assumption blindness | Document and validate assumptions |
| Scope creep | Change control process |
| Analysis paralysis | Timeboxed analysis, iterate |
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"
- [academic-research] (Low, Uses, Forward) — "Clear documentation writing"
