Edge Case Analysis
Systematically analyze a PRD to identify edge cases, failure modes, race conditions, and scenarios that might be overlooked during implementation.
The Job
- Read the provided PRD thoroughly
- Analyze each user story and functional requirement
- Identify potential edge cases across multiple categories
- Propose updates to the PRD (new acceptance criteria, new stories, or updates to existing stories)
Output: A list of edge cases with recommended PRD updates.
Edge Case Categories
1. Input Edge Cases
- Empty/null values: What if required fields are empty?
- Boundary values: Max lengths, min/max numbers, date ranges
- Invalid formats: Wrong data types, malformed input
- Unicode/special characters: Emojis, RTL text, HTML injection attempts
- Large data: What if there are 10,000 items instead of 10?
2. State Edge Cases
- Race conditions: Two users editing the same thing simultaneously
- Stale data: Data changed by another process between read and write
- Partial completion: What if the operation fails halfway?
- Concurrent operations: Multiple tabs, multiple sessions
- Offline/reconnection: What happens when connection drops?
3. User Behavior Edge Cases
- Rapid clicks: User clicks submit multiple times quickly
- Back button: User navigates back during an operation
- Browser refresh: User refreshes during a multi-step flow
- Abandoned flows: User leaves in the middle of a process
- Unexpected navigation: User directly accesses URLs they shouldn't
4. Error Handling Edge Cases
- Network failures: API timeouts, server errors
- Validation errors: How are errors displayed and recovered from?
- Permission errors: User loses access mid-operation
- Resource exhaustion: Rate limits, storage limits
5. Data Edge Cases
- First-time use: No data exists yet (empty states)
- Legacy data: Old data that doesn't match new schema
- Data migration: What happens to existing data when schema changes?
- Cascade effects: Deleting something that other things depend on
6. Security Edge Cases
- Authentication expiry: Session times out during operation
- Authorization changes: Permissions change while user is active
- Input sanitization: XSS, SQL injection, command injection
- Data leakage: Error messages exposing sensitive info
7. Performance Edge Cases
- Cold start: First load performance
- Large payloads: Response times with lots of data
- Memory leaks: Long-running sessions
- N+1 queries: Database performance at scale
Analysis Process
For each user story in the PRD:
Step 1: Read the Story
Understand what the story is trying to accomplish.
Step 2: Apply Category Checklist
Go through each edge case category above and ask:
- Does this category apply to this story?
- What specific edge cases might occur?
Step 3: Rate Severity
For each identified edge case:
- Critical: Could cause data loss, security breach, or system crash
- High: User-facing error or broken functionality
- Medium: Poor UX or minor functionality issue
- Low: Minor annoyance or cosmetic issue
Step 4: Propose PRD Update
For each edge case, propose one of:
- New acceptance criteria for existing story
- New user story if scope is significant
- Update to functional requirements
- Note in Technical Considerations
Output Format
# Edge Case Analysis for [PRD Name]
## Summary
- Total edge cases identified: X
- Critical: X | High: X | Medium: X | Low: X
## Edge Cases by Story
### US-001: [Story Title]
| Edge Case | Category | Severity | Recommended Action |
|-----------|----------|----------|-------------------|
| User submits empty form | Input | High | Add acceptance criteria: "Empty form shows validation errors" |
| User double-clicks submit | User Behavior | Medium | Add acceptance criteria: "Submit button disabled after first click" |
### US-002: [Story Title]
...
## New Stories Recommended
### US-NEW-001: Handle concurrent edits
**Description:** As a user, I want to see a warning if someone else has edited the item since I started editing.
**Acceptance Criteria:**
- [ ] System checks for updates before saving
- [ ] Warning shown if data has changed
- [ ] User can choose to overwrite or refresh
**Rationale:** Addresses race condition edge case in US-003 and US-004.
## Updated Functional Requirements
- FR-NEW-1: The system must validate all user input on both client and server side
- FR-NEW-2: All destructive operations must be idempotent
## Technical Considerations to Add
- Implement optimistic locking for concurrent edit detection
- Add retry logic with exponential backoff for network failures
- Use database transactions for multi-step operationsChecklist Before Completing
- Analyzed each user story against all edge case categories
- Rated severity for each edge case
- Provided concrete, actionable recommendations
- Grouped related edge cases to avoid duplicate stories
- Kept recommendations focused (don't over-engineer)
- Prioritized critical and high severity items
Tips
- Don't go overboard: Focus on likely scenarios, not every theoretically possible edge case
- Be specific: "User enters > 255 characters in name field" is better than "Input validation"
- Consider the context: A personal project needs less edge case handling than a banking app
- Look for patterns: If you find one race condition, there are probably more
- Think like an attacker: What would someone try to break the system?