# 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?"