Skill: Requirements Analysis

Purpose

Analyze stakeholder requests, feature descriptions, and business needs to extract clear, actionable requirements that can be translated into user stories.

When to Use

• Stakeholder submits a new feature request
• Vague or incomplete requirements need clarification
• Breaking down epics into user stories
• Validating requirements completeness
• Identifying gaps in specifications

---

Analysis Framework

1. Input Categorization

Classify incoming requests:

Category	Description	Example
Feature Request	New functionality	"Add dark mode"
Enhancement	Improve existing	"Make search faster"
Bug Report	Fix defect	"Login fails on Safari"
Technical Debt	Improve internals	"Refactor auth module"
Compliance	Regulatory need	"Add GDPR consent"

2. Requirement Extraction

Extract key elements from input:

## Requirement Analysis: {{requestTitle}}

### Raw Input
{{originalRequest}}

### Extracted Requirements

#### Functional Requirements
1. **FR-001:** [Specific function the system must perform]
2. **FR-002:** [Another specific function]

#### Non-Functional Requirements
1. **NFR-001:** [Performance: e.g., "Response time < 200ms"]
2. **NFR-002:** [Security: e.g., "Data encrypted at rest"]
3. **NFR-003:** [Usability: e.g., "Accessible to screen readers"]

#### Business Rules
1. **BR-001:** [Business constraint or rule]
2. **BR-002:** [Another business rule]

#### Assumptions
1. [Assumption made during analysis]
2. [Another assumption]

#### Dependencies
1. [External system or team dependency]
2. [Technical prerequisite]

#### Out of Scope
1. [Explicitly excluded item]
2. [Another exclusion]

---

Analysis Questions

Functional Clarity

Ask these to clarify functional requirements:

Question	Purpose
Who is the primary user of this feature?	Identify persona
What problem does this solve?	Understand value
What is the expected outcome?	Define success
What triggers this functionality?	Identify entry points
What are the edge cases?	Discover exceptions

Non-Functional Clarity

Question	Purpose
How many users will use this?	Scale requirements
How fast should it respond?	Performance needs
What data sensitivity is involved?	Security needs
Who needs access?	Authorization scope
What happens if this fails?	Reliability needs

Business Context

Question	Purpose
Why is this needed now?	Priority justification
What's the cost of not doing this?	Risk assessment
Are there regulatory drivers?	Compliance needs
Who approves the final delivery?	Acceptance authority

---

Completeness Checklist

Before converting to stories, verify:

## Completeness Check: {{feature}}

### Clarity
- [ ] Clear problem statement
- [ ] Defined user(s)
- [ ] Measurable success criteria
- [ ] Understood business value

### Scope
- [ ] In-scope items listed
- [ ] Out-of-scope explicitly stated
- [ ] Dependencies identified
- [ ] Assumptions documented

### Feasibility
- [ ] Technical approach viable
- [ ] Resources available
- [ ] Timeline realistic
- [ ] Risks identified

### Testability
- [ ] Acceptance criteria clear
- [ ] Test scenarios identifiable
- [ ] Edge cases documented

### Gaps Identified
{{#if gaps}}
{{#each gaps}}
- [ ] {{gap}} - [Action needed]
{{/each}}
{{else}}
No gaps identified - ready for story creation.
{{/if}}

---

Gap Analysis

When requirements are incomplete:

## Gap Analysis: {{feature}}

### Missing Information

| Gap | Impact | Question to Ask | Priority |
|-----|--------|-----------------|----------|
| [Missing element] | [Impact on delivery] | [Clarifying question] | High/Medium/Low |

### Recommendation

{{recommendation}}

### Escalation Needed
{{#if escalationNeeded}}
Escalate to stakeholder for:
{{#each escalationItems}}
- {{item}}
{{/each}}
{{/if}}

---

Output Templates

Requirements Summary

## Requirements Summary: {{feature}}

**Request:** {{originalRequest}}
**Analyst:** Business Analyst Agent
**Date:** {{date}}
**Status:** Complete | Gaps Identified

### Problem Statement
{{problemStatement}}

### User Personas
| Persona | Need | Priority |
|---------|------|----------|
| {{persona}} | {{need}} | {{priority}} |

### Key Requirements
1. {{requirement1}}
2. {{requirement2}}
3. {{requirement3}}

### Success Criteria
- [ ] {{criterion1}}
- [ ] {{criterion2}}

### Technical Constraints
- {{constraint1}}
- {{constraint2}}

### Recommended Stories
1. As a {{persona}}, I want to {{action}} so that {{benefit}}
2. As a {{persona}}, I want to {{action}} so that {{benefit}}

### Open Questions
{{#if openQuestions}}
{{#each openQuestions}}
- {{question}}
{{/each}}
{{else}}
None - requirements are complete.
{{/if}}

---

MoSCoW Prioritization

Categorize extracted requirements:

Priority	Meaning	Criteria
Must Have	Essential	Without this, solution fails
Should Have	Important	Significant value, not critical
Could Have	Nice to have	Enhances but not required
Won't Have	Out of scope	Explicitly excluded this time

---

Used By Agents

Agent	Analysis Use
Business Analyst	Primary - extracts and documents requirements
Product Owner	Reviews and prioritizes requirements
Software Architect	Assesses technical feasibility
QA Engineer	Derives test scenarios from requirements

Best Practices

1. Don't assume - If unclear, ask
2. Document everything - Including what's out of scope
3. Validate understanding - Confirm with stakeholder
4. Think edge cases - Consider failure scenarios
5. Keep user focus - Requirements serve users, not technology
6. Trace to value - Every requirement should have clear business value