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"
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1---2name: business-analysis-skill3description: Patterns for requirements elicitation, BRDs, process analysis, and stakeholder alignment. Use when this capability is needed.4---56# Business Analysis Skill78> Patterns for requirements elicitation, BRDs, process analysis, and stakeholder alignment.910## Business Analysis Deliverables1112| 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 |2021## Requirements Hierarchy2223```text24Business Requirements (WHY)25 └── Stakeholder Requirements (WHO needs WHAT)26 └── Solution Requirements27 ├── Functional (WHAT it does)28 └── Non-Functional (HOW WELL it does it)29 └── Transition Requirements (HOW we get there)30```3132## BRD Structure3334### Standard Sections35361. **Executive Summary** — One-page overview for executives372. **Business Objectives** — Measurable goals (SMART)383. **Scope** — In scope, out of scope, boundaries394. **Stakeholders** — Who's involved, their interests405. **Current State** — As-is process, pain points416. **Future State** — To-be vision, benefits427. **Functional Requirements** — What the solution must do438. **Non-Functional Requirements** — Quality attributes449. **Assumptions & Constraints** — Known limitations4510. **Dependencies** — External factors4611. **Risks** — What could go wrong4712. **Glossary** — Term definitions4849### Requirements Writing5051#### SMART Criteria5253| 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? |6061#### Good vs. Bad Requirements6263| 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) |7071#### Requirement Attributes7273| 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 |8384## Elicitation Techniques8586### Technique Selection8788| 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 |9798### Interview Best Practices99100- Prepare questions in advance101- Start broad, then specific102- Use open-ended questions103- Listen more than talk (80/20)104- Probe with "Why?" and "How?"105- Summarize and confirm understanding106- Document immediately after107108### Workshop Facilitation109110| Phase | Activities |111| ----- | ---------- |112| **Open** | Objectives, agenda, ground rules |113| **Diverge** | Brainstorm, generate options |114| **Converge** | Prioritize, decide |115| **Close** | Summarize, next steps, thank |116117## Use Case Development118119### Use Case Template120121```text122Use Case: [UC-001] [Name]123Actor: [Primary actor]124Precondition: [What must be true before]125Trigger: [What initiates the use case]126127Main Flow:1281. Actor does X1292. System responds with Y1303. ...131132Alternative Flows:1332a. If condition, then...134135Exception Flows:1362b. If error, then...137138Postcondition: [What is true after]139Business Rules: [Applicable rules]140```141142### Use Case Levels143144| 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" |149150## Process Analysis151152### Current State Analysis1531541. Map as-is process (BPMN, swimlane)1552. Identify pain points1563. Measure current performance1574. Find root causes1585. Quantify improvement opportunity159160### Process Mapping Notations161162| Notation | Best For |163| -------- | -------- |164| BPMN | Detailed, technical processes |165| Swimlane | Cross-functional workflows |166| Value Stream | Lean analysis |167| SIPOC | High-level overview |168169### SIPOC Template170171| 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? |175176## Gap Analysis177178### Gap Analysis Framework179180```text181Current State → Gap → Future State182 │ │ │183 ▼ ▼ ▼184 As-Is What needs To-Be185 Process to change Vision186```187188### Gap Categories189190| 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 |197198## Acceptance Criteria199200### Gherkin Format201202```gherkin203Given [precondition]204When [action]205Then [expected result]206And [additional result]207```208209### Acceptance Criteria Checklist210211- [ ] Testable — Can write a test case212- [ ] Clear — Unambiguous language213- [ ] Complete — Covers happy path and edges214- [ ] Independent — Doesn't require other criteria215- [ ] Valuable — Ties to user need216217## Traceability218219### Traceability Matrix220221| Req ID | Business Objective | Design | Test Case | Status |222| ------ | ------------------ | ------ | --------- | ------ |223| REQ-001 | OBJ-01 | DES-005 | TC-012 | Passed |224225### Traceability Benefits226227- Ensure all requirements implemented228- Impact analysis for changes229- Test coverage verification230- Audit compliance evidence231232## Prioritization Techniques233234### MoSCoW235236| 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 |242243### Value vs. Effort Matrix244245```text246High 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 Effort252```253254### Kano Model255256| 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 |261262## Common BA Pitfalls263264| 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 |272273## Synapses274275### High-Strength Connections276277- [project-management] (High, Informs, Forward) — "Requirements feed project scope"278- [change-management] (High, Receives, Backward) — "Change impact on requirements"279280### Medium-Strength Connections281282- [root-cause-analysis] (Medium, Uses, Forward) — "Problem analysis for requirements"283- [testing-strategies] (Medium, Enables, Forward) — "Requirements enable test design"284285### Supporting Connections286287- [architecture-refinement] (Low, Informs, Forward) — "Requirements shape architecture"288- [writing-publication] (Low, Uses, Forward) — "Clear documentation writing"289290---291> Converted and distributed by [TomeVault](https://tomevault.io/claim/fabioc-aloha) — claim your Tome and manage your conversions.292<!-- tomevault:4.0:skill_md:2026-04-14 -->