edge-cases

边界情况分析

系统地分析 PRD，找出边界情况、故障模式、竞态条件，以及实现过程中可能被忽略的场景。

---

工作内容

1. 彻底阅读提供的 PRD
2. 分析每个用户故事和功能需求
3. 从多个类别中识别潜在的边界情况
4. 提出 PRD 更新建议（新增验收标准、新故事，或更新现有故事）

输出： 边界情况列表及建议的 PRD 更新。

---

边界情况类别

1. 输入边界情况

• 空值/null 值： 必填字段为空时会怎样？
• 边界值： 最大长度、最小值/最大值、日期范围
• 无效格式： 数据类型错误、输入格式错误
• Unicode/特殊字符： 表情符号、从右向左的文本、HTML 注入尝试
• 大量数据： 如果有 10,000 个条目而不是 10 个，会怎样？

2. 状态边界情况

• 竞态条件： 两名用户同时编辑同一内容
• 过期数据： 读取后、写入前数据被其他进程更改
• 部分完成： 操作中途失败时会怎样？
• 并发操作： 多个标签页、多个会话
• 离线/重新连接： 连接中断时会发生什么？

3. 用户行为边界情况

• 快速点击： 用户快速多次点击提交
• 返回按钮： 用户在操作过程中返回
• 浏览器刷新： 用户在多步骤流程中刷新页面
• 中途放弃流程： 用户在流程中途离开
• 意外导航： 用户直接访问无权访问的 URL

4. 错误处理边界情况

• 网络故障： API 超时、服务器错误
• 验证错误： 如何显示错误并从错误中恢复？
• 权限错误： 用户在操作过程中失去访问权限
• 资源耗尽： 速率限制、存储限制

5. 数据边界情况

• 首次使用： 尚无数据（空状态）
• 旧版数据： 不符合新架构的数据
• 数据迁移： 架构更改时，现有数据会怎样处理？
• 级联影响： 删除其他内容所依赖的内容

6. 安全边界情况

• 身份验证过期： 操作过程中会话超时
• 授权更改： 用户处于活动状态时权限发生变化
• 输入清理： XSS、SQL 注入、命令注入
• 数据泄露： 错误消息暴露敏感信息

7. 性能边界情况

• 冷启动： 首次加载性能
• 大型负载： 大量数据下的响应时间
• 内存泄漏： 长时间运行的会话
• N+1 查询： 数据库在规模扩展时的性能

---

分析流程

针对 PRD 中的每个用户故事：

步骤 1：阅读故事

了解该故事要实现的目标。

步骤 2：应用类别检查清单

逐一检查上述每个边界情况类别，并询问：

• 该类别是否适用于此故事？
• 可能出现哪些具体的边界情况？

步骤 3：评估严重程度

为每个已识别的边界情况评定严重程度：

• 严重： 可能导致数据丢失、安全漏洞或系统崩溃
• 高： 面向用户的错误或功能故障
• 中： 用户体验差或轻微功能问题
• 低： 轻微不便或外观问题

步骤 4：提出 PRD 更新

针对每个边界情况，提出以下其中一项：

• 为现有故事新增验收标准
• 如果范围较大，则新增用户故事
• 更新功能需求
• 在技术注意事项中注明

---

输出格式

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

---

完成前检查清单

• 已对照所有边界情况类别分析每个用户故事
• 已评定每个边界情况的严重程度
• 已提供具体、可执行的建议
• 已将相关边界情况归组，避免重复创建故事
• 建议重点明确（避免过度设计）
• 已优先处理严重和高优先级事项

---

提示

• 不要过度纠结： 关注可能出现的场景，而非每一种理论上可能的边缘情况
• 具体一些： “用户在名称字段中输入超过 255 个字符”比“输入验证”更好
• 结合上下文考虑： 个人项目需要处理的边缘情况比银行应用少
• 留意规律： 如果发现一个竞态条件，可能还有更多
• 像攻击者一样思考： 有人会尝试用什么方式破坏系统？