360 Secure SkillHub
360 安全技能中心

qa-requirement-review

该技能在测试设计前对需求文档(PRD)做质量评审,从完整性、清晰性、一致性、可测试性、可实现性五个维度逐项检查(每维10分,总分≥40为有条件通过、≥45为通过),输出评审结论、五维评分、P0-P2 问题清单与改进建议;配套报告模板与逐条评审标准放在 references 目录按需加载,并提醒问题需标注处理状态,不生成测试用例。

kokxi
kokxi
热度 60.66
最近更新 2026-09-29 12:42:13
分类:开发依赖:读写文件应用场景:报告撰写

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add qa-requirement-review
Metadata
displayName
需求评审
name
qa-requirement-review
description
从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求"评审这份需求"、"看看这个PRD写得怎么样"、或者测试用例设计前需要先评估需求质量时,应当使用此技能。如果需求本身有问题(模糊/矛盾/不可测试),后续的测试设计都是徒劳。不要只在用户明确说"需求评审"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 触发场景:需求评审、评审需求、需求质量、PRD评审、需求检查、需求写得好不好、评审这份需求、需求提交测试前预审时。 Use when the user asks about: reviewing a PRD or requirement document for completeness, clarity, consistency, testability, and feasibility before test design starts.
license
MIT
allowed-tools
Read Grep Glob WebFetch
metadata
{"slug":"qa-requirement-review","display-name":"需求评审","version":"1.8.0","when-to-use":"用户说\"需求评审\"、\"评审需求\"、\"需求质量\"、\"PRD评审\"、\"需求检查\"、\"需求写得好不好\"、\"评审这份需求\"、需要评审需求文档、需求提交测试前预审时","related-skills":"{\"upstream\":[\"qa-input-validation\",\"qa-critical-thinking\",\"qa-question-framework\"],\"downstream\":[\"qa-req-deconstruction\",\"qa-test-strategy-design\"]}","references":"[\"references/report-template.md\",\"references/review-standards.md\"]","input-format":"{\"required\":[{\"name\":\"需求描述\",\"type\":\"string\",\"description\":\"功能需求的详细描述文本\"}],\"optional\":[{\"name\":\"业务背景\",\"type\":\"string\",\"description\":\"业务目标和用户角色\"},{\"name\":\"历史缺陷\",\"type\":\"array\",\"description\":\"同类功能的历史缺陷记录\"}]}","output-format":"{\"traceability\":[\"每份需求评审报告带唯一ID(REV-REQ-XXXX)\",\"关联需求ID:REQ-{需求模块缩写}-{序号}\"],\"structure\":[\"覆盖率:标注口径(基于现有需求/输入文档),禁止\\\"全覆盖/100%\\\"绝对化表述;缺失模块标注\\\"未覆盖+原因\\\"\",{\"review_report\":\"需求评审报告\"},{\"completeness_score\":\"完整性评分\"},{\"clarity_score\":\"清晰性评分\"},{\"consistency_issues\":\"一致性问题清单\"},{\"testability_assessment\":\"可测试性评估\"}]}","error-recovery-guidance":"{\"on_failure\":\"识别到需求不完整时返回缺失清单,要求用户补充信息\",\"retry_behavior\":\"用户补充信息后重新执行需求评审\"}","categories":"[\"Development\",\"Requirements\"]","depth-requirement":"{\"reference_value\":\"根据需求复杂度调整评审深度:简单×1/中等×2/复杂×3\",\"minimum\":\"至少评审完整性、清晰性、一致性、可测试性、可实现性5个维度\"}"}

⚠️ 本技能单独使用效果有限,建议配合完整技能集(12 步工作流)使用。安装:npx skills add Kokxi/qa-test-skills

需求评审专项

核心原则

需求评审不是挑刺,而是确保需求可理解、可测试、可实现。

五维评审速查

各维度的详细检查清单、评审问题速查和严重度矩阵参见 references/review-standards.md。

评分规则:每个维度10分,总分≥40分为"有条件通过",≥45分为"通过"。

维度 评分核心 典型问题
完整性 功能/非功能/约束/验收是否完整 主流程缺失、异常未定义、验收标准缺失
清晰性 术语/描述/示例是否清晰无歧义 术语歧义、描述模糊、缺少示例
一致性 内部/外部/版本是否一致 前后矛盾、与现有系统冲突
可测试性 验证/度量/自动化是否可行 "体验好"不可验证、性能未量化
可实现性 技术/资源/业务是否可行 架构不支持、时间不合理

每维度的完整检查清单和评分标准详见 references/review-standards.md。

评审报告模板

完整模板(含五维评分表格、P0-P2问题清单)参见 references/report-template.md。

简要结构:

# 需求评审报告
## 评审结论:[通过/有条件通过/不通过]
## 五维评分:完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10
## 问题清单
### P0(必须修改)
### P1(建议修改)
### P2(可选修改)
## 改进建议

加载时机

需要时才读,不要一上来全读:

什么时候读 读哪个
拿评审报告模板填 references/report-template.md(报告结构与填写要求)
判断某个需求问题算不算缺陷 references/review-standards.md(五维评审标准)

五维评分口径在本文;模板与逐条标准在 references,按需加载。


输出示例

评审一个PRD:用户登录功能需求 → 完整性检查:功能描述完整✅,但缺少非功能需求❌ → 清晰性检查:"登录超时"未定义具体时间❌ → 一致性检查:前后描述一致✅ → 可测试性检查:"响应要快"不可量化❌,应改为"登录响应<2秒" → 可实现性检查:技术方案可行✅ → 评审报告:P0问题(缺少非功能需求)+ P1问题(模糊表述)

五维评审判定示范(pass/fail 对照):

维度 PASS 示例 FAIL 示例 判定要点
完整性 "支持用户名+密码登录、验证码、密码找回,含异常场景" "用户能登录系统"(无边界/异常/非功能) 主流程+分支+异常+非功能是否齐
清晰性 "密码错误3次锁定15分钟" "密码错误多次后锁定"(多次=?锁定多久=?) 数量/时间/条件是否有具体值
一致性 全文用"验证码"表述,前后一致 前文"短信验证码"后文"图形验证码" 术语/规则/数据定义前后是否矛盾
可测试性 "登录响应时间<2秒(P95)" "响应要快" 指标是否可量化、可观测
可实现性 "基于现有统一认证服务实现" "接入自研AI人脸识别(当前无此能力)" 技术方案在当前栈是否可行

检查清单

需求评审完成后检查:

  • 评审维度是否覆盖?
  • 检查清单是否执行?
  • 问题是否识别?
  • 问题是否分类?
  • 建议是否可行?
  • 报告是否规范?

常见评审陷阱

  1. 只挑刺不建树:发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议
  2. 凭感觉不打分:说"这块不够好"但不指哪个维度 → 评审结论必须基于五维评分
  3. 过度纠错细节:纠结错别字忽略结构性缺失 → 区分"格式问题"和"内容问题",优先评审内容
  4. 遗漏非功能:只看功能完整不看性能/安全 → 五维评审缺一不可
  5. 评审完不追踪:报告给了就完了 → 必须标注每条问题的处理状态(已修/待修/已确认)