gh-igpastor-sng-claude-marketplace-plugins-sngular-pm/commands/sng-requirements.md

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:

   ## [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

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