| name | business-analyst |
| description | Business analysis expertise for translating business needs into technical requirements. Use when eliciting requirements from stakeholders, modeling business processes, writing functional specifications, performing gap analysis, defining data dictionaries, or creating acceptance test scenarios from business rules. |
| summary_l0 | Translate business needs into technical requirements with process modeling and gap analysis |
| overview_l1 | This skill provides business analysis expertise for translating business needs into technical requirements. Use it when eliciting requirements from stakeholders, modeling business processes, writing functional specifications, performing gap analysis, defining data dictionaries, or creating acceptance test scenarios from business rules. Key capabilities include stakeholder requirement elicitation, business process modeling (BPMN), functional specification writing, gap analysis between current and target states, data dictionary definition, acceptance test scenario creation from business rules, use case and user story development, and requirements traceability. The expected output is structured business analysis artifacts including requirements documents, process models, gap analyses, and acceptance criteria. Trigger phrases: business analysis, requirements gathering, business process, functional specification, gap analysis, data dictionary, stakeholder requirements, use cases, business rules. |
Business Analyst
Structured business analysis frameworks for bridging the gap between stakeholders and engineering teams. This skill provides templates, modeling techniques, and communication tools that translate business needs into actionable technical requirements.
When to Use This Skill
Use this skill for:
- Eliciting and documenting requirements from stakeholders
- Modeling business processes to identify inefficiencies and automation opportunities
- Writing functional specifications that engineers can implement without ambiguity
- Analyzing data structures and defining data dictionaries for new systems
- Performing gap analysis between current capabilities and desired future state
- Creating acceptance criteria and test scenarios from business rules
- Managing stakeholder communication throughout the requirements lifecycle
Trigger phrases: "requirements gathering", "business process", "functional spec", "gap analysis", "data dictionary", "acceptance criteria", "stakeholder interview", "use case", "BPMN", "as-is to-be", "swimlane diagram", "traceability matrix", "UAT plan", "requirements sign-off", "change request"
What This Skill Does
Provides a seven-step business analysis workflow that moves from stakeholder discovery through requirements documentation, process modeling, data analysis, gap identification, acceptance testing, and structured communication.
Overview
- Requirements Elicitation - Discover and capture stakeholder needs using structured techniques
- Business Process Modeling - Map current and target processes with standard notation
- Functional Specification Writing - Document testable requirements with traceability
- Data Analysis and Modeling - Define entities, relationships, and data quality rules
- Gap Analysis - Assess current state, define target state, and identify gaps
- Acceptance Criteria and Testing - Extract business rules into verifiable test scenarios
- Stakeholder Communication - Report status, manage changes, and secure sign-off
Instructions
Step 1: Requirements Elicitation
Requirements elicitation is the foundation of every successful project. Use multiple techniques to triangulate the true need, because stakeholders often describe solutions rather than problems.
Stakeholder Map:
STAKEHOLDER MAP
───────────────
ID Name/Role Interest Influence Engagement Strategy
──── ───────────────── ───────── ────────── ──────────────────────────────
S-01 [Name, Title] High High Manage closely (1:1 sessions)
S-02 [Name, Title] High Low Keep informed (weekly updates)
S-03 [Name, Title] Low High Keep satisfied (approval gates)
S-04 [Name, Title] Low Low Monitor (include in broadcasts)
Interview Guide:
INTERVIEW GUIDE
───────────────
Stakeholder: [Name, Role]
Objective: [What you need to learn]
CONTEXT (10 min)
- Describe your role in this process from start to finish.
- What are the biggest pain points you face today?
- Walk me through a typical day involving [process/system].
SPECIFICS (20 min)
- What information do you need to complete [task]?
- What decisions do you make, and what data drives them?
- What happens when [exception/error scenario] occurs?
VALIDATION (10 min)
- If we solved [stated problem], what would change for you?
- What would success look like in 6 months?
- Is there anything I have not asked that you expected me to?
Workshop Facilitation: For cross-functional requirements, run a 2-4 hour session (max 8-10 participants) with this agenda: context setting (15 min), current state walkthrough (30 min), pain point identification via silent brainstorm and dot voting (40 min), future state visioning (30 min), requirements extraction (30 min), wrap-up with action items (15 min). Assign a dedicated facilitator and scribe.
Observation: Watch users perform tasks and log each step with the tool used, time taken, and pain points observed. This reveals requirements stakeholders cannot articulate because the behavior is habitual.
Survey Design: Use surveys to validate requirements across a large user population after interviews identify themes. Include Likert scales for satisfaction, multiple choice for preferences, and limit open text to 2-3 questions.
Elicitation Output:
ELICITATION SUMMARY
───────────────────
Session type: [Interview / Workshop / Observation / Survey]
Date: [YYYY-MM-DD]
Participants: [Names]
REQUIREMENTS IDENTIFIED
ID Type Description Priority Source
─────── ──────────── ─────────────────────────────────────── ───────── ──────
REQ-001 Functional [System shall do X when Y occurs] High S-01
REQ-002 Non-functional[Response time under 3 seconds] High S-02
OPEN QUESTIONS: [Items needing follow-up]
CONFLICTS: [Disagreements requiring resolution by DATE]
Step 2: Business Process Modeling
Process models make invisible workflows visible, exposing bottlenecks, redundant steps, and handoff failures.
BPMN Quick Reference: Events (circles: start, end, intermediate), Activities (rounded rectangles: tasks, subprocesses), Gateways (diamonds: XOR for exclusive, AND for parallel, OR for inclusive), Flows (solid arrows for sequence, dashed for messages), Swimlanes (pools for organizations, lanes for roles).
As-Is Process Map:
AS-IS PROCESS: [Process Name]
─────────────────────────────
Process owner: [Name] Scope: [Start trigger] to [End state]
SWIMLANE DIAGRAM
Lane: [Role A] | [Task 1] ──> [Task 2] ──> <Decision?> ──> [Task 3]
| │ No
Lane: [Role B] | ▼
| [Task 4] ──> [Task 5]
METRICS: Cycle time [X days], Handoffs [N], Manual steps [N/total], Error rate [X%]
To-Be Process and Improvement Log:
IMPROVEMENT LOG: [Process Name]
───────────────────────────────
# Current Step Change Rationale Expected Impact
── ───────────────────── ────────────────────── ─────────────────────── ──────────────
1 Manual data entry Automate via API Eliminates errors -80% error rate
2 Email approval loop In-app approval queue Reduces wait time -2 days cycle time
3 Separate reporting Real-time dashboard Single source of truth -4 hrs/week manual
Decision Table:
DECISION TABLE: [Business Rule Name]
────────────────────────────────────
Conditions | Rule 1 Rule 2 Rule 3 Rule 4
───────────────────────────────|────────────────────────────────
Order value > $10,000 | Y Y N N
Customer tier = Premium | Y N Y N
───────────────────────────────|────────────────────────────────
Apply 15% discount | X - - -
Apply 10% discount | - X X -
Apply standard pricing | - - - X
Process Improvement Checklist: For each step ask: Can it be eliminated? Automated? Combined with adjacent steps? Does the handoff add value? Is the approval a legacy control? Does the step exist only because of a system limitation? Does it introduce delay longer than the work itself?
Step 3: Functional Specification Writing
Ambiguous specifications are the single largest source of defects. Write requirements that an engineer can implement and a tester can verify without asking follow-up questions.
Use Case Format:
USE CASE: [UC-001] [Name]
─────────────────────────
Actor: [Role] Goal: [What the actor accomplishes] Trigger: [Initiating event]
Preconditions: [What must be true before]
Postconditions: [What is true after success]
MAIN SCENARIO
1. [Actor does X] 2. [System responds Y] 3. [Actor provides Z] 4. [System confirms]
EXTENSIONS
3a. Validation fails → System displays error → Actor corrects, return to 3
4a. External service unavailable → System queues for retry → Notifies actor
BUSINESS RULES: BR-01 [rule], BR-02 [rule]
FREQUENCY: [X times per day/week]
User Story Decomposition: Split epics using these strategies: by workflow step (each step becomes a story), by data variation (simple type vs complex type), by business rule (standard rule vs exception). Ensure each resulting story can be completed in a single sprint.
Functional Requirements Template:
FUNCTIONAL REQUIREMENTS: [Feature Name]
───────────────────────────────────────
ID Requirement Statement Priority Source
─────── ───────────────────────────────────────────────────────────── ──────── ──────
FR-001 The system shall accept [data] in [format] via [channel] Must REQ-001
FR-002 The system shall calculate [result] using [formula] Must REQ-003
FR-003 The system shall reject [input] when [condition] Should Workshop
Rules: Use "shall" (mandatory), "should" (desirable), "may" (optional).
One behavior per requirement. Include measurable criteria. Avoid "user-friendly" or "fast".
Non-Functional Requirements: Categorize into Performance (response time, throughput), Scalability (concurrent users), Availability (uptime SLA), Security (encryption, access control), Compliance (GDPR, retention), Usability (task completion time), Accessibility (WCAG level), and Maintainability (coverage target). Each must have a measurement method.
Traceability Matrix:
TRACEABILITY MATRIX: [Project Name]
───────────────────────────────────
Business Need Requirement Design Element Test Case Status
─────────────── ───────────── ───────────────── ───────────── ──────
BN-001 FR-001 API endpoint /foo TC-001, TC-002 Implemented
BN-002 FR-003 Dashboard widget TC-004, TC-005 Not started
Check for: business needs without requirements, requirements without tests, orphan requirements.
Step 4: Data Analysis and Modeling
Poorly defined data structures lead to integration failures, reporting errors, and costly migrations. Define data models early and validate them with stakeholders who understand the business meaning of each field.
Entity-Relationship Model:
ER MODEL: [Domain Name]
───────────────────────
Entity: Customer
Attributes: customer_id (PK), name, email (unique), tier, created_date, status
Entity: Order
Attributes: order_id (PK), customer_id (FK), order_date, total_amount, status
RELATIONSHIPS
Customer 1──────M Order (A customer places zero or more orders)
Order 1──────M OrderLine (An order contains one or more order lines)
Data Dictionary:
DATA DICTIONARY: [Entity Name]
──────────────────────────────
Field Type Required Default Business Definition Constraints
────────────── ────────── ──────── ───────── ─────────────────────────────────── ─────────────────
customer_id UUID Yes Auto-gen Unique identifier at registration Immutable
email VARCHAR(255)Yes None Primary contact email Valid format, unique
tier ENUM Yes Standard Classification for pricing rules Standard/Premium/Enterprise
status ENUM Yes Active Current lifecycle state Active/Suspended/Closed
Data Flow Description: Document external entities (who sends/receives data), processes (what transforms data), data stores (where data persists), and data flows (what moves between them, in which direction, carrying what content).
Data Quality Rules:
DATA QUALITY RULES: [Entity/Domain]
───────────────────────────────────
ID Rule Type Field(s) Rule Description Action on Violation
────── ───────────── ─────────── ───────────────────────────────────── ────────────────────
DQ-001 Completeness email Must not be null or empty Reject record
DQ-002 Format email Must match standard email regex Reject with message
DQ-003 Uniqueness email No two active records share email Reject duplicate
DQ-004 Referential customer_id Must exist in Customer table Reject transaction
DQ-005 Consistency line_total Must equal quantity x unit_price Recalculate and log
Migration Requirements: For each source field, define: target field, transformation rule, and validation notes. Include a migration plan: extract, transform, validate against quality rules, load to staging, reconcile (counts, checksums, samples), stakeholder review, production cutover with rollback window.
Step 5: Gap Analysis
Gap analysis identifies the distance between current capabilities and the desired future state, providing a structured basis for investment decisions and prioritization.
Current State Assessment:
CURRENT STATE: [Capability Area]
────────────────────────────────
ID Capability Current Tool/Process Maturity Pain Points
──── ────────────────────── ────────────────────── ─────────── ─────────────────
C-01 Order processing Manual spreadsheet Ad hoc Error-prone, slow
C-02 Customer communication Individual emails Repeatable No templates
Maturity: Ad hoc → Repeatable → Defined → Managed → Optimized
Gap Identification Matrix:
GAP MATRIX: [Initiative Name]
─────────────────────────────
ID Capability Current State Target State Gap Description Severity
──── ──────────────── ─────────────────── ──────────────────── ─────────────────────────── ────────
G-01 Order processing Manual spreadsheet Automated system No system support; manual Critical
G-02 Customer comms Ad hoc emails Event-driven templates No automation or templates High
Impact Analysis: For each gap, assess two dimensions. Impact of leaving the gap open (operational, financial, strategic, customer effects). Impact of closing the gap (process improvement, cost savings, competitive positioning). Include effort to close: duration, cost, resources, and dependencies on other gaps.
Cost-Benefit Framework: Compare costs (implementation, labor, training, ongoing maintenance) against benefits (labor savings, error reduction, revenue enabled, penalties avoided) over a 1-3 year horizon. Calculate NPV, payback period, and ROI.
Recommendation Prioritization:
PRIORITY MATRIX
───────────────
Gap ID Recommendation Business Value Effort Risk Priority Score Sequence
────── ────────────────────────── ────────────── ────── ──── ────────────── ────────
G-01 Implement order automation High (9/10) High Med 7.5 Phase 1
G-02 Deploy comms templates Med (7/10) Low Low 8.0 Phase 1
Score = (Value x 0.5) + (Inverse Effort x 0.3) + (Inverse Risk x 0.2)
Step 6: Acceptance Criteria and Testing
Acceptance criteria translate business rules into testable conditions. They serve as the contract between business stakeholders and the engineering team.
Business Rule Extraction:
BUSINESS RULES: [Feature Name]
──────────────────────────────
ID Rule Name Rule Statement Source Type
────── ───────────────────── ───────────────────────────────────────────────────── ─────────── ─────────
BR-001 Discount eligibility Premium customers get 10% off on orders > $500 Policy doc Calculation
BR-002 Approval threshold Orders > $10,000 require manager approval Finance Authorization
BR-003 Account lockout Lock after 5 consecutive failed login attempts Security Security
Given/When/Then Scenarios:
SCENARIO 1: Premium customer receives discount (happy path)
Given a customer with tier "Premium" and an order totaling $600
When the customer submits the order
Then the system applies a 10% discount and the total becomes $540
SCENARIO 2: Standard customer does not receive discount
Given a customer with tier "Standard" and an order totaling $600
When the customer submits the order
Then no discount is applied and the total remains $600
SCENARIO 3: Order below discount threshold
Given a customer with tier "Premium" and an order totaling $400
When the customer submits the order
Then no discount is applied and the total remains $400
Write one scenario per business rule per path: happy path, error path, and boundary.
Acceptance Test Matrix:
TEST MATRIX: [Feature Name]
───────────────────────────
Business Rule Happy Path Error Path Boundary Edge Case Status
────────────── ────────── ────────── ───────── ───────── ──────
BR-001 SC-01 SC-02 SC-03 - Ready
BR-002 SC-04 SC-08 SC-09 SC-10 Ready
BR-003 SC-05 SC-06 SC-07 SC-11 Draft
UAT Planning:
UAT PLAN: [Release Name]
────────────────────────
Coordinator: [Name] Environment: [URL] Period: [Start] to [End]
ENTRY CRITERIA: Scenarios scripted, environment deployed, critical defects resolved, participants briefed
EXIT CRITERIA: 100% must-have scenarios executed, zero critical defects, business sign-off obtained
PARTICIPANTS
Name Role Scenarios Assigned Training Date
────────────── ──────────────── ─────────────────── ─────────────
[Name] [Business role] SC-01 through SC-06 [Date]
Defect Classification:
| Severity | Business Definition | Response SLA |
|---|
| Critical | Process blocked, no workaround | Fix within 4 hours |
| High | Major function impaired, costly workaround | Fix within 1 day |
| Medium | Minor impairment, acceptable workaround | Fix within 1 week |
| Low | Cosmetic, no business impact | Fix in next release |
Step 7: Stakeholder Communication
Effective communication prevents misalignment and builds trust. Use structured templates so status, changes, and decisions are unambiguous.
Status Report:
STATUS REPORT: [Project Name] - Week of [YYYY-MM-DD]
─────────────────────────────────────────────────────
Overall: [GREEN / AMBER / RED]
COMPLETED: [Item 1], [Item 2], [Milestone reached]
PLANNED: [Item 1], [Item 2]
RISKS/ISSUES
ID Type Description Impact Mitigation Owner Due
──── ───── ─────────────────────────────── ──────── ────────────────────── ─────── ──────
R-01 Risk API dependency may slip 1 week Timeline Parallel dev path [Name] [Date]
DECISIONS NEEDED: [Description, options, recommendation, needed by DATE]
Requirements Sign-Off: Distribute document with review deadline. Reviewers submit comments. BA consolidates and resolves conflicts. Updated document sent for final review (3 business days). Approvers sign to confirm completeness. "Approved with comments" requires all comments resolved before implementation. Sign-off establishes the agreed baseline but does not prevent future change requests.
Change Request:
CHANGE REQUEST: [CR-001]
────────────────────────
Requested by: [Name] Date: [YYYY-MM-DD] Priority: [Critical/High/Medium/Low]
DESCRIPTION: [What is requested and why]
IMPACT ASSESSMENT
Area Impact Description Severity
───────────── ───────────────────────────────────────────── ────────
Requirements [Requirements added/modified/removed] [H/M/L]
Timeline [Schedule impact in days/weeks] [H/M/L]
Budget [Cost impact] [H/M/L]
Testing [Test cases to add/modify] [H/M/L]
RECOMMENDATION: [Approve, reject, or defer with rationale]
Impact Notification: When a change affects stakeholders, communicate: what happened (factual summary), who is affected, what it means (consequences), what is being done (actions and dates), and what you need from them (specific asks with deadlines).
Decision Record:
DECISION: [DEC-001]
───────────────────
Date: [YYYY-MM-DD] Decided by: [Name] Status: [Proposed/Accepted/Superseded]
CONTEXT: [Why this decision was needed]
OPTIONS: A) [description, pros, cons] B) [description, pros, cons] C) [description, pros, cons]
CHOSEN: [Option and primary reason]
CONSEQUENCES: [What this enables, what it rules out]
REVIEW TRIGGER: [Condition to revisit: date, metric threshold, or event]
Quick Reference: Technique Selection Guide
| Situation | Recommended Technique | Step |
|---|
| "What do stakeholders need?" | Interviews + stakeholder map | Step 1 |
| "How does the current process work?" | As-is process map + observation | Step 2 |
| "What should the system do?" | Use cases + functional requirements | Step 3 |
| "What data do we need?" | ER model + data dictionary | Step 4 |
| "Where are we vs where we need to be?" | Gap matrix + impact analysis | Step 5 |
| "How do we know it works?" | Given/When/Then + UAT plan | Step 6 |
| "How do we keep everyone aligned?" | Status reports + change requests | Step 7 |
Common Mistakes to Avoid
Mistake 1: Capturing Solutions Instead of Requirements
Bad: "The system shall use a dropdown menu for country selection"
Good: "The system shall allow the user to select their country from a list of 195 recognized countries"
Mistake 2: Skipping the Current State
Bad: Jump straight to designing the future system
Good: Map the as-is process first, then identify which steps to automate, eliminate, or improve
Mistake 3: Writing Untestable Requirements
Bad: "The system shall be easy to use"
Good: "A new user shall complete the registration process in under 3 minutes without assistance"
Mistake 4: Ignoring Data Migration
Bad: Assume data from the old system will "just work" in the new one
Good: Define field-by-field mapping, transformation rules, and a validation plan before development begins
Mistake 5: Informal Change Management
Bad: Stakeholder emails a new requirement; developer implements it immediately
Good: Change request submitted, impact assessed, approved by designated authority, then scheduled
Common Rationalizations
| Rationalization | Reality |
|---|
| "The stakeholder told me exactly what to build, so I can skip elicitation" | Stakeholders describe solutions, not problems. Building the dropdown they asked for instead of the country-selection capability they needed means a rework cycle the moment a 196th country appears. |
| "The current process is obvious, I'll jump straight to the to-be design" | Skipping the as-is map hides the legacy approval step that exists only to compensate for a system limitation. You automate the workaround and ship the bottleneck into the new system. |
| "'User-friendly' and 'fast' are clear enough for the engineers" | Those words are untestable, so QA cannot sign off and every reviewer interprets them differently. "Registration completes in under 3 minutes without assistance" is the difference between a passing test and an endless argument. |
| "Data migration will just work once the new schema is ready" | Unmapped source fields and missing transformation rules surface as silent data loss at cutover, not in development. A field-by-field mapping with quality rules is the only thing that catches a NULL email before it reaches production. |
Verification
Related Skills
- [[product-manager]] -- product strategy, prioritization, and roadmap planning that consumes these requirements
- [[technical-writer]] -- documentation standards and user-facing content for the specs this skill produces
- [[plan-before-code]] -- engineering planning and exploration before implementation begins
- [[test-driven-development]] -- writing automated tests from the acceptance criteria defined here
- [[requirement-enhancer]] -- sharpen the testability and completeness of individual requirements
Version: 1.0.0
Last Updated: March 2026
Iterative Refinement Strategy
This skill is optimized for an iterative approach:
- Execute: Perform the core steps defined above.
- Review: Critically analyze the output (coverage, quality, completeness).
- Refine: If targets are not met, repeat the specific implementation steps with improved context.
- Loop: Continue until the definition of done is satisfied.
