edge-cases
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseEdge Case Analysis
边缘情况分析
Systematically analyze a PRD to identify edge cases, failure modes, race conditions, and scenarios that might be overlooked during implementation.
系统性地分析PRD，识别在开发过程中可能被忽略的边缘情况、故障模式、竞态条件以及场景。
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.
- 仔细阅读提供的PRD
- 分析每个用户故事和功能需求
- 识别多个类别下的潜在边缘情况
- 提出PRD的更新建议（新的验收标准、新的用户故事，或对现有故事的更新）
输出： 带有PRD更新建议的边缘情况列表。
Edge Case Categories
边缘情况分类
1. Input Edge Cases
1. 输入边缘情况
- 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?
- 空/空值： 如果必填字段为空会怎样？
- 边界值： 最大长度、最小/最大数值、日期范围
- 无效格式： 错误的数据类型、格式错误的输入
- Unicode/特殊字符： 表情符号、从右到左文本、HTML注入尝试
- 大数据： 如果有10000条数据而非10条会怎样？
2. State Edge Cases
2. 状态边缘情况
- 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
3. 用户行为边缘情况
- 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
- 快速点击： 用户快速多次点击提交按钮
- 返回按钮： 用户在操作过程中点击返回
- 浏览器刷新： 用户在多步骤流程中刷新页面
- 中途放弃流程： 用户在操作过程中离开
- 意外导航： 用户直接访问无权访问的URL
4. Error Handling Edge Cases
4. 错误处理边缘情况
- 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
- 网络故障： API超时、服务器错误
- 验证错误： 错误如何显示以及如何恢复？
- 权限错误： 用户在操作过程中失去访问权限
- 资源耗尽： 速率限制、存储限制
5. Data Edge Cases
5. 数据边缘情况
- 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
6. 安全边缘情况
- 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
- 认证过期： 操作过程中会话超时
- 授权变更： 用户在活跃期间权限发生变化
- 输入清理： XSS、SQL注入、命令注入
- 数据泄露： 错误消息暴露敏感信息
7. Performance Edge Cases
7. 性能边缘情况
- 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
- 冷启动： 首次加载性能
- 大负载： 大量数据下的响应时间
- 内存泄漏： 长时间运行的会话
- N+1查询： 大规模场景下的数据库性能
Analysis Process
分析流程
For each user story in the PRD:
针对PRD中的每个用户故事：
Step 1: Read the Story
步骤1：阅读用户故事
Understand what the story is trying to accomplish.
理解该故事要实现的目标。
Step 2: Apply Category Checklist
步骤2：应用分类检查清单
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
步骤3：评估严重程度
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
步骤4：提出PRD更新建议
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
输出格式
markdown
undefinedmarkdown
undefinedEdge Case Analysis for [PRD Name]
Edge Case Analysis for [PRD Name]
Summary
Summary
- Total edge cases identified: X
- Critical: X | High: X | Medium: X | Low: X
- Total edge cases identified: X
- Critical: X | High: X | Medium: X | Low: X
Edge Cases by Story
Edge Cases by Story
US-001: [Story Title]
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" |
| 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]
US-002: [Story Title]
...
...
New Stories Recommended
New Stories Recommended
US-NEW-001: Handle concurrent edits
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.
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
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
- 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
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 operations
---- Implement optimistic locking for concurrent edit detection
- Add retry logic with exponential backoff for network failures
- Use database transactions for multi-step operations
---Checklist 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?
- 不要过度： 关注可能出现的场景，而非所有理论上的边缘情况
- 具体化： "用户在名称字段输入超过255个字符" 比 "输入验证" 更清晰
- 结合上下文： 个人项目所需的边缘情况处理少于银行应用
- 寻找规律： 如果发现一个竞态条件，很可能存在更多同类情况
- 站在攻击者角度思考： 有人会如何尝试破坏系统？