software-requirement-quality-gate

name	software-requirement-quality-gate
description	用于检查软件需求文档质量门禁。适用于需求评审、需求质量检查、需求表完整性校验、验证准则检查、待确认项和工程化补足合规检查、输出放行判定。
argument-hint	输入待检查的软件需求文档内容或路径，执行需求质量门禁
user-invocable	true

软件需求质量门禁 Skill

何时使用

• 需求文档生成完成后，做发布前质量检查
• 需要判断需求文档能否作为下一个环节的正式输入物时
• 需要输出 通过/不通过 结论以及整改清单时

门禁目标

确保需求文档满足“可开发、可联调、可测试、可验收”的最低质量标准，并且符合轻量 ASPICE SWE.1 文档习惯。

门禁规则

A. 结构完整性

文档应包含以下章节：

• 文档属性
• 范围与目的
• 系统背景与边界
• 参考文档
• 术语与缩略语
• 场景摘要
• 功能需求
• 数据与配置需求
• 非功能需求
• 设计约束
• 验收与追踪

说明：不适用章节允许删除，但不得保留空壳章节。

B. 功能需求质量

每条功能需求应满足：

• 编号唯一
• 一条需求只表达一个要求
• 需求描述清晰、单一、可验证
• 包含验证准则和验证方式
• 不混入实现方案、类设计、线程模型等设计细节
• 来源/备注栏能标识需求来源、[工程化补足] 或 [待确认]

C. 工程化标记合规

• 工程化补足内容必须显式标记为 [工程化补足]
• 无法稳定推断的内容必须标记为 [待确认]
• 不得出现未经标记的主观假设或虚构参数

D. 数据与配置定义

• 核心数据项应定义来源、用途和生命周期
• 配置需求在适用时应单列需求项
• 持久化需求在适用时应明确
• 数据名称应与正文术语保持一致

E. 场景、异常与约束

• 典型正常场景应在场景摘要或需求表中覆盖
• 典型异常、恢复或降级场景应在场景摘要、功能需求或安全/诊断章节中体现
• 若存在共享资源、重复触发、异步回调、多任务/多线程/多用户并发，应体现并发冲突处理需求
• 硬约束必须单独列出，不应散落在描述性文字中
• 系统边界必须明确，避免职责漂移

F. ASPICE 追踪与验证

• 关键需求必须可追踪到来源
• 关键需求必须声明验证准则和验证方式
• 文档应提供轻量追踪矩阵或等效追踪关系
• 需求应可直接映射到设计和测试活动

门禁判定

通过

同时满足：

• 无 P0 问题
• 无结构缺失
• 无明显不可验证的需求表述
• 无明显需求粒度过粗问题
• 无未标记的主观补充

不通过

出现任一情况即不通过：

• 缺失核心章节
• 存在无法独立实现或独立验收的需求
• 需求不可验证或缺失验证准则/验证方式
• 大量待确认项直接阻断开发
• 缺失需求来源或追踪关系，导致 ASPICE 评审无法闭环

输出格式

门禁输出必须包含：

1. 总体结论：通过 / 不通过
2. 风险等级：P0 / P1 / P2
3. 发现项清单：按严重度排序
4. 整改建议
5. 放行结论：允许流转 / 禁止流转

建议检查清单

可参考 门禁检查清单 执行逐项审查。