mcpField
R
requirement-review

requirement-review

github.com/dauquangthanh测试与质量17126 次安装40 周前更新
代码仓库

关于 requirement-review

用于在设计和开发前系统审查需求的技能，按六项质量属性评估并识别问题，同时提供评分、报告和审批建议。

主要功能

  1. 01六项质量属性评估
  2. 02按严重程度分类问题
  3. 03质量评分与就绪门槛
  4. 04针对文档类型的审查标准
  5. 05结构化报告与建议

适用场景

  1. 01审查 BRD、SRS 和用户故事
  2. 02发现含糊或不可测试的需求
  3. 03评估需求是否适合进入设计阶段

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/dauquangthanh/hanoi-rainbow --skill requirement-review

安装后在 Claude Code 中输入/requirement-review确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
examples.md
quality-checklists.md
report-templates.md

详细介绍

需求评审

系统地评审需求，在设计和开发开始前验证质量并发现问题。确保需求完整、清晰、一致、可测试且可追溯。

评审工作流

1. 准备

收集所有相关文档：

  • 需求文档（BRD、SRS、用户故事）
  • 非功能需求和约束
  • 需求追溯矩阵（如有）
  • 项目背景（章程、目标）
  • 现有验收标准
2. 质量评估

使用六项质量属性评估每项需求：

  1. 完整性：已涵盖所有需求，无遗漏细节或待定事项，并已识别依赖关系
  2. 清晰性：含义明确、具体，不含模糊用语（如“用户友好”“快速”“简单”）
  3. 一致性：无冲突，术语和优先级保持一致
  4. 可测试性：可通过可衡量的验收标准进行验证，并有明确的通过／失败判定
  5. 可追溯性：与业务目标、设计和测试相关联
  6. 可行性：在约束条件（预算、时间线、能力）内技术上可实现

参见 quality-checklists.md，了解详细的评估标准和针对特定文档的检查清单

3. 问题识别

识别常见的需求问题：

含糊不清：“系统应当快速” → 指定可衡量的标准：“95% 的请求响应时间 < 2s”

无法测试：“系统应当安全” → 定义具体的控制措施：密码复杂度、加密标准、审计日志

不完整：“系统应发送通知” → 指定渠道、时间、内容和接收人

相互冲突：REQ-012“必须提供电话号码”与 REQ-089“电话号码可选” → 标记并交由利益相关方解决

参见 examples.md，查看大量修改前后的示例

4. 质量评分

为每项质量属性计算分数（0-100%）：

  • 90-100%：优秀——问题极少
  • 75-89%：良好——需要少量改进
  • 60-74%：一般——存在明显缺口
  • 低于 60%：较差——需要大幅返工

总体质量 = 六项属性的平均分
目标：达到 ≥ 90%，以满足生产就绪要求

5. 生成报告

创建结构化评审报告，包含：

执行摘要：质量评级、建议、主要优势（2-3 项）、关键问题（2-3 项）、首要行动

详细发现：质量评分、按严重程度（严重／主要／次要）划分的问题，以及带需求 ID 的具体示例

行动项：按优先级排序的列表，包含负责人、到期日、工作量估算和审批条件

参见 report-templates.md，了解完整的报告结构和模板

6. 建议

给出明确的决策：

  • 批准：需求质量达到 ≥ 90% 的阈值
  • 有条件批准：必须在设计开始前解决关键问题
  • 重大修订：质量为 60-74%——需要大幅返工
  • 拒绝：质量 < 60% 或存在根本性问题——需要全面重新设计

特定文档的关注重点

业务需求文档（BRD）

关注业务目标、利益相关方需求、范围定义、业务论证和约束

软件需求规格说明书（SRS）

关注功能需求、非功能需求（性能、安全性、可扩展性）、系统行为、集成点以及 IEEE 830 合规性

用户故事待办列表

关注 INVEST 标准（独立、可协商、有价值、可估算、小型、可测试）、验收标准格式（Given-When-Then）、故事格式和优先级

参见 quality-checklists.md，了解针对特定文档的评估标准

严重性定义

  • Critical：阻碍进展，必须立即修复（安全漏洞、根本性冲突、范围缺失）
  • Major：对质量有重大影响，应在批准前修复（标准含糊、缺少验收标准）
  • Minor：质量改进项，有则更好（格式、示例、增强功能）

需要指出的常见反模式

  • 过度设计（Gold Plating）：添加未要求的功能
  • 聚焦解决方案：规定“如何做”而不是“做什么”（需求应与技术无关）
  • 范围蔓延：未经过变更控制就接受变更
  • 分析瘫痪：无限期地过度完善需求
  • 验收标准薄弱：测试条件含糊或缺失
  • 缺乏可追溯性：需求与业务目标脱节

需要替换的含糊用语

始终将其替换为可衡量的标准：

  • “用户友好”“直观”“简单” → 定义可用性指标
  • “快速”“迅速”“响应灵敏” → 指定响应时间目标
  • “安全” → 定义具体的安全控制措施
  • “可扩展” → 定义容量和负载目标
  • “可靠” → 定义正常运行时间百分比和恢复时间

标准合规性

  • IEEE 830：SRS 结构和内容标准
  • INVEST：用户故事质量标准（独立、可协商、有价值、可估算、小型、可测试）
  • ISO/IEC 25010：系统和软件质量模型
  • 行业特定标准：HIPAA（医疗保健）、PCI-DSS（支付）、SOC 2（SaaS）、FDA（医疗器械）

参见 quality-checklists.md，了解标准合规性的详细信息

报告格式

按以下结构生成审查报告：

  1. 执行摘要（1 页）：总体评估、关键发现、建议
  2. 质量指标（0.5 页）：按属性列出评分和目标
  3. 详细发现（2-5 页）：按属性对问题分组，并提供示例和建议
  4. 行动项（1 页）：按优先级排列的清单，包含负责人和截止日期
  5. 批准决定（0.5 页）：建议、理由和后续步骤

报告应保持客观、具体且可执行。指出问题时，务必引用具体的需求 ID。

参见 report-templates.md，获取完整的报告模板

评论

支持 Markdown