240 lines
7.2 KiB
Markdown
240 lines
7.2 KiB
Markdown
# Requirements Analysis Command
|
|
|
|
You are helping the user analyze, document, and manage project requirements following Sngular's project management best practices.
|
|
|
|
## Instructions
|
|
|
|
1. **Determine the scope**:
|
|
- Ask what feature or project needs requirements analysis
|
|
- Identify if this is for a new feature, enhancement, or bug fix
|
|
- Determine if there's an existing GitHub issue to update
|
|
- Check for existing documentation to review
|
|
|
|
2. **Gather context**:
|
|
- Review project documentation in `./docs`
|
|
- Analyze relevant codebase sections
|
|
- Check existing requirements or specifications
|
|
- Review similar features or patterns in the project
|
|
- Identify stakeholders and their needs
|
|
|
|
3. **Analyze requirements**:
|
|
- **Functional Requirements**: What the system must do
|
|
- **Non-Functional Requirements**: Performance, security, scalability, accessibility
|
|
- **User Stories**: As a [user], I want [goal], so that [benefit]
|
|
- **Acceptance Criteria**: Clear, testable conditions for completion
|
|
- **Dependencies**: Other features, services, or systems required
|
|
- **Constraints**: Technical, business, or time limitations
|
|
- **Assumptions**: Things we're assuming to be true
|
|
- **Risks**: Potential issues or challenges
|
|
|
|
4. **Structure the documentation**:
|
|
```markdown
|
|
## [Feature Name] - Requirements
|
|
|
|
### Overview
|
|
Brief description of the feature and its purpose.
|
|
|
|
### Business Context
|
|
- Why is this needed?
|
|
- What problem does it solve?
|
|
- What is the expected business impact?
|
|
|
|
### Functional Requirements
|
|
|
|
#### FR-1: [Requirement Title]
|
|
**Priority**: Must-have / Should-have / Could-have / Won't-have
|
|
**Description**: Detailed description of what needs to be implemented
|
|
**Acceptance Criteria**:
|
|
- [ ] Criterion 1
|
|
- [ ] Criterion 2
|
|
- [ ] Criterion 3
|
|
|
|
#### FR-2: [Next Requirement]
|
|
...
|
|
|
|
### Non-Functional Requirements
|
|
|
|
#### NFR-1: Performance
|
|
- Response time: < 200ms for API calls
|
|
- Page load time: < 2 seconds
|
|
- Support for 1000 concurrent users
|
|
|
|
#### NFR-2: Security
|
|
- Authentication required
|
|
- Role-based access control
|
|
- Data encryption at rest and in transit
|
|
|
|
#### NFR-3: Accessibility
|
|
- WCAG 2.1 AA compliance
|
|
- Screen reader support
|
|
- Keyboard navigation
|
|
|
|
### User Stories
|
|
|
|
**US-1**: As a [user type], I want to [action], so that [benefit]
|
|
- Acceptance Criteria:
|
|
- [ ] Criterion 1
|
|
- [ ] Criterion 2
|
|
|
|
### Technical Specifications
|
|
|
|
#### Data Models
|
|
```typescript
|
|
interface Model {
|
|
id: string
|
|
// ...
|
|
}
|
|
```
|
|
|
|
#### API Endpoints
|
|
- `POST /api/resource` - Create new resource
|
|
- `GET /api/resource/:id` - Retrieve resource
|
|
|
|
#### UI Components
|
|
- ComponentName: Description and purpose
|
|
|
|
### Dependencies
|
|
- External APIs or services required
|
|
- Third-party libraries needed
|
|
- Database schema changes
|
|
- Infrastructure requirements
|
|
|
|
### Assumptions
|
|
- List of assumptions made during analysis
|
|
|
|
### Risks & Mitigation
|
|
| Risk | Impact | Likelihood | Mitigation Strategy |
|
|
|------|--------|------------|---------------------|
|
|
| Risk 1 | High | Medium | Mitigation plan |
|
|
|
|
### Testing Strategy
|
|
- Unit tests for business logic
|
|
- Integration tests for API endpoints
|
|
- E2E tests for user workflows
|
|
- Performance testing approach
|
|
- Security testing considerations
|
|
|
|
### Implementation Phases
|
|
|
|
**Phase 1**: Core functionality (2 weeks)
|
|
- [ ] Task 1
|
|
- [ ] Task 2
|
|
|
|
**Phase 2**: Advanced features (1 week)
|
|
- [ ] Task 3
|
|
- [ ] Task 4
|
|
|
|
**Phase 3**: Polish & optimization (3 days)
|
|
- [ ] Task 5
|
|
- [ ] Task 6
|
|
|
|
### Success Metrics
|
|
- How will we measure success?
|
|
- KPIs to track
|
|
- User adoption goals
|
|
|
|
### Open Questions
|
|
- [ ] Question 1 that needs clarification
|
|
- [ ] Question 2 requiring stakeholder input
|
|
```
|
|
|
|
5. **GitHub Integration** (if applicable):
|
|
- Check if working in a GitHub repository
|
|
- Ask for issue number to update
|
|
- Create or update GitHub issue with requirements
|
|
- Add appropriate labels: `requirements`, `documentation`
|
|
- Link related issues if any
|
|
|
|
6. **Save documentation**:
|
|
- Save requirements to `./docs/requirements/[feature-name].md`
|
|
- Update main requirements index if it exists
|
|
- Create a summary for quick reference
|
|
|
|
## GitHub Commands
|
|
|
|
```bash
|
|
# View repository info
|
|
gh repo view
|
|
|
|
# List existing issues
|
|
gh issue list
|
|
|
|
# View specific issue
|
|
gh issue view <issue-number>
|
|
|
|
# Create new issue with requirements
|
|
gh issue create --title "Requirements: [Feature Name]" --body "$(cat requirements.md)" --label "requirements,documentation"
|
|
|
|
# Add requirements as comment to existing issue
|
|
gh issue comment <issue-number> --body "$(cat requirements.md)"
|
|
|
|
# Update issue labels
|
|
gh issue edit <issue-number> --add-label "requirements-defined"
|
|
|
|
# Link issues
|
|
gh issue comment <issue-number> --body "Related to #<other-issue-number>"
|
|
```
|
|
|
|
## Requirements Prioritization (MoSCoW Method)
|
|
|
|
- **Must-have**: Critical for launch, non-negotiable
|
|
- **Should-have**: Important but not critical, can be scheduled for later if needed
|
|
- **Could-have**: Nice to have, adds value but not essential
|
|
- **Won't-have**: Not planned for this release, explicitly excluded
|
|
|
|
## Best Practices
|
|
|
|
### Writing Good Requirements
|
|
|
|
✅ **Good**:
|
|
- "The system shall allow users to export data in CSV, JSON, and XML formats"
|
|
- "API response time must be under 200ms for 95% of requests"
|
|
- "The login form must be accessible via keyboard navigation"
|
|
|
|
❌ **Bad**:
|
|
- "The system should be fast" (not measurable)
|
|
- "It should be user-friendly" (too vague)
|
|
- "We might need export functionality" (not decisive)
|
|
|
|
### Acceptance Criteria Guidelines
|
|
|
|
Each acceptance criterion should be:
|
|
- **Specific**: Clearly defined without ambiguity
|
|
- **Measurable**: Can be verified through testing
|
|
- **Achievable**: Technically feasible within constraints
|
|
- **Relevant**: Directly related to the requirement
|
|
- **Testable**: Can write automated or manual tests
|
|
|
|
### INVEST Principles for User Stories
|
|
|
|
- **Independent**: Can be developed separately
|
|
- **Negotiable**: Open to discussion and refinement
|
|
- **Valuable**: Provides clear value to users
|
|
- **Estimable**: Team can estimate effort
|
|
- **Small**: Can be completed in one sprint
|
|
- **Testable**: Can verify it's done
|
|
|
|
## Questions to Ask
|
|
|
|
Before starting requirements analysis:
|
|
1. "What is the main goal or problem this feature addresses?"
|
|
2. "Who are the primary users and what are their needs?"
|
|
3. "Are there existing issues or documentation I should review?"
|
|
4. "What are the must-have features vs. nice-to-have?"
|
|
5. "Are there any technical constraints or dependencies?"
|
|
6. "What is the expected timeline or deadline?"
|
|
7. "How will success be measured?"
|
|
8. "Should I create a new GitHub issue or update an existing one?"
|
|
|
|
## Example Workflow
|
|
|
|
1. User: "Analyze requirements for user authentication feature"
|
|
2. Claude: Reviews codebase, checks for existing auth patterns
|
|
3. Claude: Asks clarifying questions about auth method (OAuth, JWT, etc.)
|
|
4. Claude: Creates comprehensive requirements document
|
|
5. Claude: Saves to `./docs/requirements/user-authentication.md`
|
|
6. Claude: Creates GitHub issue or updates existing one
|
|
7. Claude: Provides summary and next steps
|
|
|
|
Ask the user: "What feature or project would you like me to analyze requirements for?"
|