review-requirements

技能：审查需求

目的

依据需求建模和需求质量评估现有需求。输出发现列表；不要编写或改写需求。

核心目标

判断该需求是否可作为安全、可测试且可追溯的设计输入，包括在触发条件适用时，是否包含可度量的质量属性场景。

范围边界

此技能审查一份需求制品。不负责获取需求、设计解决方案、审查代码、批准未决决策或修正文档。

使用场景

• 需求草稿完成后，功能或技术设计开始前
• 需求变更后，需要重新评估下游影响时
• 将外部编写的需求纳入仓库前

行为

1. 完整加载建模规范和质量规则。
2. 根据规范核验制品类型、frontmatter 契约以及必需或有条件要求的章节。对照规范 §5.2.1 检查保留的正文部分是否按相对顺序排列；仅可根据章节适用性省略章节。将状态相关元数据视为结构合规性要求，而不是内容质量豁免。
3. 对文档及其被引用的本地父级应用所有质量标准（可追溯性要求时）。
4. 对全文应用规则中的未决决策标准，包括占位符、假设和延期确定的验收目标。核实每个未决事项的实际影响，不要只相信其阻塞/非阻塞标签。区分缺失的需求决策与仍处于既定约束范围内的设计选择。
5. 每项违规输出一条发现，类别为 requirement-quality，注明精确的章节/标准位置，并给出可执行的建议。
6. 如果没有遗留发现，说明该制品已可进入下一设计层；不要创建该设计。

输入和输出

输入为一条现有需求路径或其完整内容。输出为发现列表。零条发现表示通过门槛，而非评分。

正式需求模板 是编写辅助工具。审查时应依据当前有效的规范和规则，而非机械匹配模板；占位符和匹配的标题并不能证明合规。 capture-work-items 需求模板生成的是待办事项，而非此处审查的正式需求制品。

限制

• 不要编造需求、指标、风险或验收标准。
• 如果当前有效规范定义了项目需求 ID 和文档章节，不要使用已弃用的通用 R-NN 模型。
• 不要在需求发现中混入解决方案架构。

自检

• 已加载当前有效的规范和规则。
• 已评估必需和有条件要求的章节，且保留的章节遵循规范规定的相对顺序。
• 在触发条件适用时，已检查质量场景。
• 无论生命周期状态如何，均应用了相同的内容标准。
• 已检查文档全文中的未决决策；已根据实际影响核实非阻塞标签和延期处理的设计选择。
• 每项发现均以文档内容为依据、定位精准且类别合规。
• 未改写需求。

示例

示例 1：非功能目标含糊不清

输入：“API 应该很快。”预期：在验收章节给出一条 major 级发现，要求提供可度量的目标和有代表性的条件；不要替其选择具体数值。

示例 2：小型功能变更

输入：一项范围明确的 UI 文案变更，不涉及对架构有重大影响的质量属性。预期：不要凭空添加“质量属性场景”章节；按常规需求契约进行审查。

示例 3：不同状态下尚未解决的业务规则

输入：资格条件“待定”，标记为非阻塞，无论是在草稿还是已批准的需求中。预期：由于资格条件及其验收结果尚未确定，均给出相同的 major 发现。负责人和解决日期无法解决该规则；不要代替用户选择规则。

示例 4：推迟决定的实现选项

输入：需求明确规定了保留期限、删除行为和可验证的验收条件，而存储引擎留待技术设计决定。预期：不要将实现选项本身报告为尚未解决的需求决策。检查已确立的约束是否仍然充分。

示例 5：章节顺序

输入：范围（Scope）出现在验收标准（Acceptance Criteria）之后。预期：给出一条 minor 发现，指出该章节位置不当，并说明其应根据规范 §5.2.1 放置的位置。如果范围不适用而被省略，则不要因其缺失而给出顺序方面的发现。分别评估缺少的适用章节和内容缺陷。