Step 1: Fetch Issue Content
```bash
gh issue view --json title,body,labels,comments --repo matteocervelli/llms
```
Step 2: Parse Issue Structure
Look for these patterns in issue body:
Functional Requirements Indicators:
- "The system must..."
- "The feature should..."
- "Users can..."
- "When X happens, then Y..."
Non-Functional Requirements Indicators:
- "Response time..."
- "Must handle N concurrent users..."
- "Should be accessible to..."
- "Must comply with..."
- "Performance target..."
Acceptance Criteria Indicators:
- "Acceptance Criteria:"
- "Definition of Done:"
- Checklist items:
- [ ] - "Given... When... Then..." (BDD format)
User Stories Indicators:
- "As a..."
- "User persona..."
- "Use case..."
Step 3: Extract Functional Requirements
Parse statements that describe what the system does:
```markdown
Functional Requirements
- [FR-001] User Authentication: System must authenticate users via email/password
- [FR-002] Data Export: Users can export data to CSV, JSON, or PDF formats
- [FR-003] Real-time Updates: System must push updates to clients within 5 seconds
```
Naming Convention: FR-XXX for functional requirements
Step 4: Extract Non-Functional Requirements
Parse quality attributes:
```markdown
Non-Functional Requirements
#### Performance
- [NFR-P-001] API response time must be < 200ms for 95th percentile
- [NFR-P-002] System must handle 1000 concurrent users
#### Security
- [NFR-S-001] All data transmission must use TLS 1.3+
- [NFR-S-002] Passwords must be hashed with bcrypt (cost factor β₯12)
#### Usability
- [NFR-U-001] UI must be WCAG 2.1 Level AA compliant
- [NFR-U-002] All actions must be reversible within 30 seconds
#### Scalability
- [NFR-SC-001] Architecture must support horizontal scaling
- [NFR-SC-002] Database must handle 10M+ records without degradation
```
Naming Convention: NFR-[Category]-XXX
Step 5: Extract Acceptance Criteria
Convert issue acceptance criteria to structured format:
```markdown
Acceptance Criteria
- [ ] AC-001: User can log in with valid credentials
- Given valid email and password
- When user submits login form
- Then user is redirected to dashboard
- And session token is created
- [ ] AC-002: Invalid login shows error message
- Given invalid credentials
- When user submits login form
- Then error message displays: "Invalid email or password"
- And user remains on login page
- And login attempt is logged
- [ ] AC-003: Forgot password link is visible
- Given user is on login page
- When user views page
- Then "Forgot Password?" link is visible
- And link navigates to password reset flow
```
Naming Convention: AC-XXX for acceptance criteria
Step 6: Parse User Stories
Extract user stories in standard format:
```markdown
User Stories
Story 1: User Login
- As a registered user
- I want to log in with my email and password
- So that I can access my personalized dashboard
- Priority: Must Have (P0)
- Acceptance Criteria: AC-001, AC-002, AC-003
Story 2: Guest Browsing
- As a guest visitor
- I want to browse public content without logging in
- So that I can evaluate the platform before registering
- Priority: Should Have (P1)
- Acceptance Criteria: AC-004, AC-005
```
Step 7: Categorize by Priority
Use MoSCoW method:
```markdown
Requirement Priorities
#### Must Have (P0) - Critical for MVP
- FR-001: User Authentication
- FR-003: Real-time Updates
- NFR-S-001: TLS encryption
#### Should Have (P1) - Important
- FR-002: Data Export
- NFR-U-001: WCAG compliance
#### Could Have (P2) - Desirable
- FR-005: Dark mode support
- NFR-P-003: CDN integration
#### Won't Have (P3) - Out of scope
- FR-010: AI-powered recommendations (future release)
```
Step 8: Validate Using Checklist
Use requirements-checklist.md to validate each requirement:
```bash
# Check against requirements checklist
# Manually verify each criterion from requirements-checklist.md
```
Validation Criteria:
- β
Clear and unambiguous
- β
Testable
- β
Complete
- β
Consistent (no conflicts)
- β
Traceable to business goals
- β
Feasible with available resources
Step 9: Flag Issues
Identify and document:
```markdown
Requirement Issues
Ambiguous Requirements:
- FR-007: "System should be fast" β Needs quantification (What is "fast"?)
- FR-012: "Easy to use" β Needs specific usability criteria
Missing Requirements:
- No error handling requirements specified for API failures
- Logging and monitoring requirements not defined
- Backup and recovery procedures not mentioned
Conflicting Requirements:
- FR-015 requires real-time sync, but NFR-P-005 sets 5-minute update interval
```