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