| name | software-requirement-quality-gate |
| description | 用于检查软件需求文档质量门禁。适用于需求评审、需求质量检查、需求表完整性校验、验证准则检查、待确认项和工程化补足合规检查、输出放行判定。 |
| argument-hint | 输入待检查的软件需求文档内容或路径，执行需求质量门禁 |
| user-invocable | true |
软件需求质量门禁 Skill
何时使用
- 需求文档生成完成后，做发布前质量检查
- 需要判断需求文档能否作为下一个环节的正式输入物时
- 需要输出 通过/不通过 结论以及整改清单时
门禁目标
确保需求文档满足“可开发、可联调、可测试、可验收”的最低质量标准，并且符合轻量 ASPICE SWE.1 文档习惯。
门禁规则
A. 结构完整性
文档应包含以下章节：
- 文档属性
- 范围与目的
- 系统背景与边界
- 参考文档
- 术语与缩略语
- 场景摘要
- 功能需求
- 数据与配置需求
- 非功能需求
- 设计约束
- 验收与追踪
说明：不适用章节允许删除，但不得保留空壳章节。
B. 功能需求质量
每条功能需求应满足：
- 编号唯一
- 一条需求只表达一个要求
- 需求描述清晰、单一、可验证
- 包含验证准则和验证方式
- 不混入实现方案、类设计、线程模型等设计细节
- 来源/备注栏能标识需求来源、[工程化补足] 或 [待确认]
C. 工程化标记合规
- 工程化补足内容必须显式标记为 [工程化补足]
- 无法稳定推断的内容必须标记为 [待确认]
- 不得出现未经标记的主观假设或虚构参数
D. 数据与配置定义
- 核心数据项应定义来源、用途和生命周期
- 配置需求在适用时应单列需求项
- 持久化需求在适用时应明确
- 数据名称应与正文术语保持一致
E. 场景、异常与约束
- 典型正常场景应在场景摘要或需求表中覆盖
- 典型异常、恢复或降级场景应在场景摘要、功能需求或安全/诊断章节中体现
- 若存在共享资源、重复触发、异步回调、多任务/多线程/多用户并发，应体现并发冲突处理需求
- 硬约束必须单独列出，不应散落在描述性文字中
- 系统边界必须明确，避免职责漂移
F. ASPICE 追踪与验证
- 关键需求必须可追踪到来源
- 关键需求必须声明验证准则和验证方式
- 文档应提供轻量追踪矩阵或等效追踪关系
- 需求应可直接映射到设计和测试活动
门禁判定
通过
同时满足：
- 无 P0 问题
- 无结构缺失
- 无明显不可验证的需求表述
- 无明显需求粒度过粗问题
- 无未标记的主观补充
不通过
出现任一情况即不通过：
- 缺失核心章节
- 存在无法独立实现或独立验收的需求
- 需求不可验证或缺失验证准则/验证方式
- 大量待确认项直接阻断开发
- 缺失需求来源或追踪关系，导致 ASPICE 评审无法闭环
输出格式
门禁输出必须包含：
- 总体结论：通过 / 不通过
- 风险等级：P0 / P1 / P2
- 发现项清单：按严重度排序
- 整改建议
- 放行结论：允许流转 / 禁止流转
建议检查清单
可参考 门禁检查清单 执行逐项审查。
