Requirement Analysis Skill

This skill transforms raw interview data into structured, actionable requirement specifications.

When to Use This Skill

Use this skill after completing a requirement elicitation interview (e.g., via /good-question) when you have:

• Collected answers across multiple requirement dimensions
• Raw notes from developer conversations
• Unstructured information that needs formalization

Do not use this skill:

• During active interviews (use it after information gathering is complete)
• For code analysis or implementation tasks
• When requirements are already well-structured

What This Skill Does

1. Structure Requirements

Transform raw interview data into a formal specification organized by:

• Purpose: Problem statement, stakeholders, value proposition
• Data: Input/output specifications, data models, transformations
• Behavior: Functional flows, state transitions, business logic
• Constraints: Technical requirements, limitations, dependencies
• Quality: Success criteria, testing requirements, edge cases

2. Detect Issues

Identify and report:

• Ambiguities: Vague or underspecified requirements
• Contradictions: Conflicting statements or incompatible requirements
• Gaps: Missing information critical for implementation
• Assumptions: Implicit assumptions that need validation

3. Generate Implementation Guidance

Provide:

• Architecture Recommendations: Suggested technical approaches
• Risk Assessment: Potential challenges and mitigation strategies
• Testing Strategy: Test scenarios based on requirements
• Open Questions: Remaining uncertainties to resolve

Input Format

PREFERRED: Dimension Data JSON (from /good-question)

If invoked after a /good-question interview, provide dimension data in JSON format:

{
  "purpose": {
    "answered": true,
    "content": "English summary of purpose answers with examples",
    "examples": 2,
    "contradictions": false
  },
  "data": {
    "answered": true,
    "content": "English summary of data answers with examples",
    "examples": 1,
    "contradictions": false
  },
  "behavior": {
    "answered": true,
    "content": "English summary of behavior answers with examples",
    "examples": 3,
    "contradictions": false
  },
  "constraints": {
    "answered": true,
    "content": "English summary of constraints answers with examples",
    "examples": 1,
    "contradictions": false
  },
  "quality": {
    "answered": true,
    "content": "English summary of quality answers with examples",
    "examples": 0,
    "contradictions": false
  }
}

CRITICAL: Content fields MUST be in English for uncertainty calculation to work correctly.

ALTERNATIVE: Raw Interview Data

For ad-hoc analysis without /good-question, provide raw interview data:

## Interview Transcript

User said: "I want to build a dashboard..."
Question 1: What problem does this solve?
Answer: "Users need to see their metrics..."

Question 2: What data is involved?
Answer: "User activity logs, API call counts..."

[etc.]

Or as structured notes:

## Collected Information

Purpose: Users need visibility into system metrics
Data: Time-series data from monitoring APIs
Behavior: Real-time updates every 30 seconds
Constraints: Must work in mobile browsers
Quality: No specific test requirements mentioned

Output Format

Structured Requirement Specification

# Requirement Specification: [Project Name]

## 1. Purpose & Context

### Problem Statement
[Clear description of the problem being solved]

### Stakeholders
[Who will use this and how they benefit]

### Success Criteria
[What defines a successful implementation]

---

## 2. Functional Requirements

### Data Requirements

#### Inputs
- **Source**: [Where data comes from]
- **Format**: [Data structure and types]
- **Volume**: [Expected scale]
- **Validation**: [Required validations]

#### Outputs
- **Destination**: [Where results go]
- **Format**: [Output structure]
- **Transformations**: [Processing applied]

### Behavioral Requirements

#### Primary Flow
1. [Step-by-step description]
2. [Decision points and conditions]
3. [State changes]

#### Alternative Flows
- **Scenario**: [Alternative path description]
- **Trigger**: [What causes this path]

#### Edge Cases
- [Edge case 1]
- [Edge case 2]

---

## 3. Non-Functional Requirements

### Performance
- [Latency requirements]
- [Throughput requirements]
- [Resource constraints]

### Security
- [Authentication requirements]
- [Authorization rules]
- [Data protection needs]

### Compatibility
- [Platform requirements]
- [Browser/version support]
- [Dependency constraints]

---

## 4. Quality Requirements

### Testing Strategy
- **Unit Tests**: [What to test at unit level]
- **Integration Tests**: [What to test at integration level]
- **User Acceptance**: [How users will validate]

### Acceptance Criteria
- [ ] [Specific measurable criterion 1]
- [ ] [Specific measurable criterion 2]

---

## 5. Implementation Considerations

### Recommended Architecture
[Suggested technical approach with rationale]

### Technology Stack
- **Required**: [Must-use technologies]
- **Recommended**: [Suggested technologies]
- **Avoid**: [Technologies to avoid and why]

### Key Design Decisions
1. **Decision**: [What needs to be decided]
   - **Options**: [Available choices]
   - **Recommendation**: [Suggested choice with reasoning]

---

## 6. Risks & Challenges

### Technical Risks
- **Risk**: [Description]
  - **Impact**: [Severity]
  - **Mitigation**: [How to address]

### Requirement Risks
- **Risk**: [Ambiguity or gap]
  - **Impact**: [Effect on implementation]
  - **Resolution**: [How to clarify]

---

## 7. Open Questions

Questions that require clarification before or during implementation:

1. [Question about unclear aspect]
   - **Why it matters**: [Impact on implementation]
   - **Suggested resolution**: [How to resolve]

2. [Next question]

---

## 8. Next Steps

Recommended actions:

1. **Immediate**: [What to do right away]
2. **Before Implementation**: [Prerequisites]
3. **During Implementation**: [Ongoing considerations]

Analysis Process

Step 1: Organize Information

Group collected data by the five dimensions:

• Purpose answers → Problem statement, stakeholders
• Data answers → Input/output specifications
• Behavior answers → Functional flows
• Constraint answers → Non-functional requirements
• Quality answers → Testing strategy

Step 2: Identify Issues

Scan for:

• Ambiguous statements: "fast enough", "user-friendly", "secure"
• Contradictions: Performance vs. feature richness conflicts
• Gaps: No mention of error handling, no data validation discussed
• Implicit assumptions: "Users will know how to...", "Data will always be..."

Step 3: Synthesize Recommendations

Based on the requirements:

• Match requirements to appropriate architectural patterns
• Identify suitable technologies and frameworks
• Propose testing approaches aligned with quality needs
• Highlight design decisions that need stakeholder input

Step 4: Assess Risks

Consider:

• Complexity risks: Requirements that suggest high complexity
• Uncertainty risks: Underspecified areas prone to rework
• Dependency risks: External systems or data sources
• Performance risks: Scale or speed requirements that may be challenging

Example Usage

Input:

User wants to build a file upload feature with progress tracking.
- Files up to 1GB
- Must show upload progress
- Support multiple simultaneous uploads
- Works on mobile
- Mentioned "secure" but didn't specify details

Analysis Output:

# Requirement Specification: File Upload Feature

## 1. Purpose & Context
### Problem Statement
Users need to upload large files (up to 1GB) with visibility into upload progress.

### Stakeholders
- End users uploading files from