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
text
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
text
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
text
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
gherkin
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
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
text
High Value │ Quick Wins │ Major Projects │
│ (Do first) │ (Plan carefully)│
Low Value │ Fill-ins │ Avoid │
│ (If time) │ (Don't do) │
└────────────┴─────────────────┘
Low Effort High Effort