name: 需求质量评估 description: 需求质量评估和改进。用于根据INVEST标准评估需求、提高清晰度、检测歧义或确保完整性。提供质量检查清单、改进模式和MoSCoW优先级指导。 allowed-tools: 读取, Glob, 搜索, 写入, 编辑, 任务
需求质量
需求质量评估、INVEST标准验证和改进模式。
何时使用此技能
关键词： INVEST、需求质量、清晰度、歧义、完整性、可测试性、可估计性、改进、MoSCoW、优先级、验收标准、需求验证、质量评估
使用此技能当：
- 根据INVEST标准评估需求
- 提高需求清晰度和精确度
- 检测和解决歧义
- 确保需求完整性
- 应用MoSCoW优先级
- 迭代改进需求
- 验证验收标准质量
INVEST标准概述
INVEST缩写定义了六个质量良好的需求标准：
| 标准 | 问题 | 红旗 |
|---|---|---|
| 独立性 | 能否单独实现？ | “需要X先完成” |
| 可协商性 | 有讨论空间吗？ | 过度指定实现 |
| 有价值性 | 是否提供用户价值？ | 仅技术益处 |
| 可估计性 | 能否估计工作量？ | 模糊或无界范围 |
| 小规模 | 能否在一个迭代中完成？ | 多冲刺范围 |
| 可测试性 | 能否验证完成？ | 缺少验收标准 |
快速质量评估
快速INVEST检查
对于每个需求，在每个标准上评分0-2：
| 分数 | 含义 |
|---|---|
| 0 | 不符合标准 |
| 1 | 部分符合标准 |
| 2 | 完全符合标准 |
解释：
- 10-12：高质量，准备实施
- 7-9：可接受，需要小改进
- 4-6：需要工作，需要显著改进
- 0-3：未准备好，需要重写
常见质量问题
| 问题 | 症状 | 修复 |
|---|---|---|
| 太模糊 | “使其用户友好” | 添加可测量标准 |
| 太大 | 多周估计 | 拆分为小需求 |
| 不可测试 | 无明确成功条件 | 添加验收标准 |
| 依赖 | “X完成后” | 解耦或组合 |
| 技术性 | “重构数据库” | 重新构架为用户价值 |
| 过度指定 | 实现细节 | 关注什么，而非如何 |
MoSCoW优先级
优先级级别
| 优先级 | 含义 | 指导 |
|---|---|---|
| 必须 | 发布关键 | 没有这个，发布失败 |
| 应该 | 重要但不关键 | 高价值，时间允许 |
| 可以 | 有则更好 | 如果时间允许 |
| 不会 | 范围外（此次） | 明确推迟 |
优先级问题
- 如果不包括这个会发生什么？
- 没有这个有变通方法吗？
- 影响多少用户？
- 业务影响是什么？
- 有这个的依赖吗？
清晰度增强模式
歧义检测
避免的歧义词语：
| 词语 | 问题 | 更好替代 |
|---|---|---|
| “应该” | 不清义务 | “SHALL”（强制）或"MAY"（可选） |
| “快速” | 主观时间 | “200毫秒内” |
| “用户友好” | 主观质量 | 具体可用性标准 |
| “等” | 不完整列表 | 详尽枚举 |
| “适当” | 模糊标准 | 具体标准 |
| “一些” | 未定义数量 | 明确计数或范围 |
| “容易” | 主观难度 | 可测量步骤 |
清晰度检查清单
- [ ] 使用具体、可测量术语
- [ ] 避免歧义词语
- [ ] 首次使用定义所有缩写
- [ ] 包括所有数量的单位
- [ ] 明确指定参与者
- [ ] 定义成功条件
验收标准质量
好的验收标准
每个验收标准应该是：
- 原子性： 测试一件事
- 精确性： 清晰通过/失败
- 完整性： 覆盖需求
- 独立性： 测试可以以任何顺序运行
Given/When/Then格式
Given [前置条件]
When [动作]
Then [预期结果]
质量检查：
- [ ] Given建立清晰上下文
- [ ] When描述具体触发
- [ ] Then定义可观察结果
- [ ] 覆盖正常路径和错误案例
- [ ] 每个AC独立可测试
改进工作流
标准改进过程
1. 草拟需求
↓
2. INVEST评估（评分每个标准）
↓
3. 识别问题（低分标准）
↓
4. 应用修复（使用以下模式）
↓
5. 重新评估（验证改进）
↓
6. 添加验收标准
↓
7. 最终验证
迭代模式
当独立性失败时：
- 提取依赖为单独需求
- 或组合紧密耦合需求
当可协商性失败时：
- 移除实现细节
- 关注结果，而非方法
当有价值性失败时：
- 重新构架为用户术语
- 连接到业务目标
当可估计性失败时：
- 添加约束和边界
- 定义范围限制
当小规模失败时：
- 按用户类型拆分
- 按场景拆分
- 按CRUD操作拆分
当可测试性失败时：
- 添加验收标准
- 定义成功指标
完整性验证
需求完整性
一个完整需求包括：
| 元素 | 描述 | 必需？ |
|---|---|---|
| ID | 唯一标识符 | 是 |
| 标题 | 简短描述性标题 | 是 |
| 描述 | 完整需求文本 | 是 |
| 优先级 | MoSCoW级别 | 是 |
| 验收标准 | 可测试条件 | 是 |
| 依赖 | 相关需求 | 如果有 |
| 假设 | 基础假设 | 如果有 |
| 约束 | 限制 | 如果有 |
规范完整性
一个完整规范包括：
- [ ] 所有功能需求标识
- [ ] 包括非功能需求
- [ ] 考虑边缘案例
- [ ] 指定错误处理
- [ ] 处理安全需求
- [ ] 定义性能标准
- [ ] 包括可访问性需求
- [ ] 所有需求优先级化
- [ ] 映射依赖
- [ ] 记录假设
快速命令
| 动作 | 命令 |
|---|---|
| 评估需求质量 | /spec:validate <路径> |
| 改进需求 | /spec:refine <路径> |
| 审计规范 | /spec:audit <路径> |
相关技能
ears-authoring- EARS模式编写gherkin-authoring- Given/When/Then标准canonical-spec-format- 规范规范结构spec-management- 规范工作流中心
参考
详细文档：
最后更新： 2025-12-24
版本历史
- v1.0.0 (2025-12-26): 初始发布