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 |
1---2name: business-analysis3description: Patterns for requirements elicitation, BRDs, process analysis, and stakeholder alignment.4---5
6# Business Analysis Skill
7
8
9> Patterns for requirements elicitation, BRDs, process analysis, and stakeholder alignment.
10
11## Business Analysis Deliverables
12
13| Deliverable | Purpose | Audience |
14| ----------- | ------- | -------- |
15| **Business Case** | Justify investment | Executives, sponsors |
16| **BRD** | Document requirements | All stakeholders |
17| **Functional Spec** | Detail system behavior | Dev team, testers |
18| **Use Cases** | Describe user interactions | Designers, developers |
19| **Process Maps** | Visualize workflows | Process owners, analysts |
20| **Data Dictionary** | Define data elements | Technical team |
21
22## Requirements Hierarchy
23
24```text
25Business Requirements (WHY)
26 └── Stakeholder Requirements (WHO needs WHAT)
27 └── Solution Requirements
28 ├── Functional (WHAT it does)
29 └── Non-Functional (HOW WELL it does it)
30 └── Transition Requirements (HOW we get there)
31```
32
33## BRD Structure
34
35### Standard Sections
36
371. **Executive Summary** — One-page overview for executives
382. **Business Objectives** — Measurable goals (SMART)
393. **Scope** — In scope, out of scope, boundaries
404. **Stakeholders** — Who's involved, their interests
415. **Current State** — As-is process, pain points
426. **Future State** — To-be vision, benefits
437. **Functional Requirements** — What the solution must do
448. **Non-Functional Requirements** — Quality attributes
459. **Assumptions & Constraints** — Known limitations
4610. **Dependencies** — External factors
4711. **Risks** — What could go wrong
4812. **Glossary** — Term definitions
49
50### Requirements Writing
51
52#### SMART Criteria
53
54| Letter | Meaning | Test |
55| ------ | ------- | ---- |
56| **S** | Specific | Is it clear what's needed? |
57| **M** | Measurable | Can we verify it's done? |
58| **A** | Achievable | Is it realistic? |
59| **R** | Relevant | Does it support objectives? |
60| **T** | Time-bound | Is there a deadline? |
61
62#### Good vs. Bad Requirements
63
64| Bad | Problem | Better |
65| --- | ------- | ------ |
66| "System should be fast" | Not measurable | "Page load < 2 seconds" |
67| "Easy to use" | Subjective | "Complete task in < 3 clicks" |
68| "Handle all cases" | Unbounded | "Support cases A, B, C" |
69| "Similar to competitor" | Vague | "[Specific features listed]" |
70| "Should probably..." | Uncertain | "Must" or "Should" (MoSCoW) |
71
72#### Requirement Attributes
73
74| Attribute | Purpose |
75| --------- | ------- |
76| ID | Unique identifier (REQ-001) |
77| Description | What is required |
78| Priority | MoSCoW or numeric |
79| Source | Who requested it |
80| Rationale | Why it's needed |
81| Acceptance Criteria | How to verify |
82| Dependencies | Related requirements |
83| Status | Draft/Approved/Implemented |
84
85## Elicitation Techniques
86
87### Technique Selection
88
89| Technique | Best For | Effort |
90| --------- | -------- | ------ |
91| **Interviews** | Deep understanding, complex topics | High |
92| **Workshops** | Consensus, group decisions | Medium |
93| **Surveys** | Broad input, quantitative data | Low |
94| **Observation** | Understanding real workflows | High |
95| **Document Analysis** | Existing systems, regulations | Low |
96| **Prototyping** | Validating concepts, UI | Medium |
97| **Focus Groups** | User perspectives, reactions | Medium |
98
99### Interview Best Practices
100
101- Prepare questions in advance
102- Start broad, then specific
103- Use open-ended questions
104- Listen more than talk (80/20)
105- Probe with "Why?" and "How?"
106- Summarize and confirm understanding
107- Document immediately after
108
109### Workshop Facilitation
110
111| Phase | Activities |
112| ----- | ---------- |
113| **Open** | Objectives, agenda, ground rules |
114| **Diverge** | Brainstorm, generate options |
115| **Converge** | Prioritize, decide |
116| **Close** | Summarize, next steps, thank |
117
118## Use Case Development
119
120### Use Case Template
121
122```text
123Use Case: [UC-001] [Name]
124Actor: [Primary actor]
125Precondition: [What must be true before]
126Trigger: [What initiates the use case]
127
128Main Flow:
1291. Actor does X
1302. System responds with Y
1313. ...
132
133Alternative Flows:
1342a. If condition, then...
135
136Exception Flows:
1372b. If error, then...
138
139Postcondition: [What is true after]
140Business Rules: [Applicable rules]
141```
142
143### Use Case Levels
144
145| Level | Scope | Example |
146| ----- | ----- | ------- |
147| **Summary** | Multiple sessions | "Manage Customer Account" |
148| **User Goal** | One sitting | "Place Order" |
149| **Subfunction** | Part of a step | "Validate Address" |
150
151## Process Analysis
152
153### Current State Analysis
154
1551. Map as-is process (BPMN, swimlane)
1562. Identify pain points
1573. Measure current performance
1584. Find root causes
1595. Quantify improvement opportunity
160
161### Process Mapping Notations
162
163| Notation | Best For |
164| -------- | -------- |
165| BPMN | Detailed, technical processes |
166| Swimlane | Cross-functional workflows |
167| Value Stream | Lean analysis |
168| SIPOC | High-level overview |
169
170### SIPOC Template
171
172| S | I | P | O | C |
173| - | - | - | - | - |
174| Suppliers | Inputs | Process | Outputs | Customers |
175| Who provides? | What's needed? | High-level steps | What's produced? | Who receives? |
176
177## Gap Analysis
178
179### Gap Analysis Framework
180
181```text
182Current State → Gap → Future State
183 │ │ │
184 ▼ ▼ ▼
185 As-Is What needs To-Be
186 Process to change Vision
187```
188
189### Gap Categories
190
191| Type | Examples |
192| ---- | -------- |
193| **Process** | Missing steps, manual work |
194| **Technology** | System limitations |
195| **People** | Skills, capacity |
196| **Data** | Quality, availability |
197| **Policy** | Rules, compliance |
198
199## Acceptance Criteria
200
201### Gherkin Format
202
203```gherkin
204Given [precondition]
205When [action]
206Then [expected result]
207And [additional result]
208```
209
210### Acceptance Criteria Checklist
211
212- [ ] Testable — Can write a test case
213- [ ] Clear — Unambiguous language
214- [ ] Complete — Covers happy path and edges
215- [ ] Independent — Doesn't require other criteria
216- [ ] Valuable — Ties to user need
217
218## Traceability
219
220### Traceability Matrix
221
222| Req ID | Business Objective | Design | Test Case | Status |
223| ------ | ------------------ | ------ | --------- | ------ |
224| REQ-001 | OBJ-01 | DES-005 | TC-012 | Passed |
225
226### Traceability Benefits
227
228- Ensure all requirements implemented
229- Impact analysis for changes
230- Test coverage verification
231- Audit compliance evidence
232
233## Prioritization Techniques
234
235### MoSCoW
236
237| Priority | Meaning | Guidance |
238| -------- | ------- | -------- |
239| **Must** | Critical for success | ~60% of effort |
240| **Should** | Important, not critical | ~20% of effort |
241| **Could** | Nice to have | ~20% of effort |
242| **Won't** | Out of scope (this release) | Documented |
243
244### Value vs. Effort Matrix
245
246```text
247High Value │ Quick Wins │ Major Projects │
248 │ (Do first) │ (Plan carefully)│
249Low Value │ Fill-ins │ Avoid │
250 │ (If time) │ (Don't do) │
251 └────────────┴─────────────────┘
252 Low Effort High Effort
253```
254
255### Kano Model
256
257| Type | If Present | If Absent |
258| ---- | ---------- | --------- |
259| **Basic** | Expected, no delight | Dissatisfied |
260| **Performance** | More is better | Less is worse |
261| **Delighter** | Unexpected joy | Not missed |
262
263## Common BA Pitfalls
264
265| Pitfall | Prevention |
266| ------- | ---------- |
267| Solution jumping | Ask "why" before "how" |
268| Missing stakeholders | Stakeholder analysis early |
269| Gold plating | Tie everything to objectives |
270| Assumption blindness | Document and validate assumptions |
271| Scope creep | Change control process |
272| Analysis paralysis | Timeboxed analysis, iterate |