requirements-stepwise-reviewlisted

# 需求分步评审 ## 任务目标 对需求文档进行系统化、结构化评审，通过三轮独立评审逐步深入，每轮聚焦单一维度，避免评审遗漏和维度混淆。 ## 评审原则 - 严格按轮次推进，禁止跨轮次分析 - 每轮评审必须穷尽该维度的检查要点 - 问题描述需具体，引用原文位置 - 模糊描述视为问题，不放过"大概""可能"类表述 --- ## 第一轮：完整性评审 ### 评审重点 检查需求文档是否覆盖所有必要内容，识别遗漏和缺失。 ### 检查清单 **场景���盖** - 用户故事/用例是否完整？是否遗漏了主流程以外的分支场景？ - 异常流程、错误处理是否有描述？ - 系统边界是否清晰定义？ **边界条件** - 最大/最小值、阈值是否明确？ - 空值、零值、边界值场景是否覆盖？ - 并发、压力、容量上限是否有说明？ **接口定义** - API 接口的请求/响应参数是否完整？ - 参数类型、必填/可选、格式要求是否清晰？ - 错误码定义是否覆盖所有异常情况？ **数据定义** - 核心数据实体是否都有描述？ - 字段含义、取值范围、默认值是否明确？ - 关联关系、依赖关系是否说明？ ### 输出格式 ``` 【完整性问题】 [场景遗漏] - 问题描述：<具体缺失的场景> - 涉及章节：<文档位置> - 建议补充：<具体补充建议> [边界模糊] - 问题描述：<未明确的边界条件> - 涉及章节：<文档位置> - 建议补充：<具体补充建议> [接口缺失] - 问题描述：<缺失的接口或参数> - 涉及章节：<文档位置> - 建议补充：<具体补充建议> [数据缺失] - 问题描述：<未定义的数据或字段> - 涉及章节：<文档位置> - 建议补充：<具体补充建议> ``` --- ## 第二轮：一致性评审 ### 评审重点 检查需求文档内部是否存在矛盾、冲突或不一致。 ### 检查清单 **描述一致性** - 同一功能在不同章节的描述是否一致？ - 功能名称、术语使用是否统一？ - 时序/流程描述与状态机定义是否匹配？ **数据一致性** - 同一字段在不同地方的定义是否相同？ - 数据来源和计算逻辑是否自洽？ - 枚举值、状态码定义是否唯一？ **约束一致性** - 不同章节对同一约束的描述是否矛盾？ - 性能要求、响应时间等指标是否一致？ - 安全要求、权限定义是否统一？ **引用一致性** - 图表、流程图与文字描述是否对应？ - 上下游接口依赖描述是否一致？ - 版本号、编号等标识是否正确？ ### 输出格式 ``` 【一致性问题】 [描述冲突] - 问题描述：<冲突的具体内容> - 冲突位置： - 位置A：<章节A的描述> - 位置B：<章节B的描述> - 判定依据：<判定为冲突的理由> - 建议统一：<统一的建议方案> [数据矛盾] - 问题描述：<矛盾的数据定义> - 矛盾位置： - 位置A：<章节A的定义> - 位置B：<章节B的定义> - 建议统一：<统一的建议方案> [约束冲突] - 问题描述：<冲突的约束条件> - 冲突位置：<两个冲突的位置> - 建议统一：<统一的建议方案> ``` --- ## 第三轮：可测试性评审 ### 评审重点 检查需求描述是否足够具体、量化、可验证。 ### 检查清单 **量化程度** - 性能指标是否有明确数值？（如：响应时间 < 200ms） - 成功率、错误率是否有可测量的标准？ - 数据量级、并发量是否具体？（如：支持 1000 Q