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 mentionedOutput 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 detailsAnalysis 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