状态稳定
类型原子 Skill
领域需求质量
生命周期需求
适合角色QA / BA / PM / DEV
语言中文 / 英文
评测有评测 ✓
同步日期2026-09-15
解决什么问题
输入需求文档或用户故事，输出信息缺口、业务规则、风险和测试范围。
它把测试设计前的需求理解，变成一份可以评审、跟进和继续执行的质量输入。
- 业务规则描述不完整，正常流程明确但异常流程缺失。
- 状态变化、边界条件和外部依赖没有定义清楚。
- 验收标准无法直接验证，需求缺口被带入测试设计。
- API、UI 与业务规则之间存在不一致，质量风险没有优先级。
适用场景
推荐使用
- 新需求进入需求细化阶段。
- 用户故事初步完成，需要确认是否可测试。
- 进行 PRD 评审或测试分析开始前。
- 需求发生重大变化，需要重新梳理范围和风险。
不建议直接使用
- 已经明确只需要生成测试用例。
- 单纯分析 PR 变更。
- 单纯排查生产事故。
- 单纯做 API 自动化或执行回归测试。
输入
最低输入
- 需求 / 用户故事
- 当前变更目标
推荐输入
- PRD
- 验收标准
- UI / 原型
- API 规范
- 业务规则
- 架构
- 已有测试用例
- 历史缺陷
可选上下文
- 源代码
- PR 变更
- 生产日志
- 指标
- 历史需求
输出
输出不是一段泛化总结，而是一份可以直接进入评审、测试设计和后续跟进的结构化分析报告。
不安装也能判断输出价值
- 01范围总结
- 02业务目标
- 03参与者
- 04业务规则
查看完整输出结构
- 05主流程
- 06替代流程
- 07异常流程
- 08状态变化
- 09依赖关系
- 10边界条件
- 11信息缺口
- 12歧义
- 13质量风险
- 14待确认问题
- 15建议下一步
输出预览
优先级发现证据影响行动
P0升级失败后的会员状态未定义AC-03状态可能不一致PM 明确失败规则
P1外部权益接口超时行为未知API 规范无法设计恢复场景开发补充超时策略
P110,000 元边界定义不明确PRD边界测试无法确定明确 >= / >
真实示例
输入
新增会员等级自动升级功能。金卡用户累计消费达到 10,000 元后，自动升级为白金卡，并立即获得白金卡权益。
调用
@skill requirements-analysis
分析这个会员升级需求，识别业务规则、边界、依赖、缺口和质量风险。结果
- 业务规则金卡 → 白金卡；累计消费达到 10,000
- 信息缺口退款后累计消费是否回退？升级失败是否重试？
- 边界条件9,999.99 / 10,000.00 / 10,000.01
- 依赖会员服务 / 订单服务 / 权益服务
- 质量风险P0：会员已升级，但权益未发放。
工作原理
- 01理解上下文
- 02提取业务规则
- 03识别流程与状态
- 04识别边界与依赖
- 05发现信息缺口
- 06识别质量风险
- 07输出结构化分析
安装与快速开始
安装命令 / SHELL
npx skills add \
https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/requirements-analysis
-grequirements-analysis.prompt
@skill requirements-analysis
分析这个需求，识别业务规则、边界、依赖、信息缺口和质量风险。
需求：
[粘贴需求内容]---
name: requirements-analysis
description: Use this skill when you need to analyze requirements, identify test points, boundaries, dependencies, and risks before test design; triggers include 需求分析 and requirements analysis.
---
# 需求分析（中文版）
**英文版：** 见对应英文技能。
## 何时使用
- 需要在真实项目里处理 requirements analysis 相关任务。
- 需要一份可以直接用于执行、评审或跟进的结果。
## 执行流程
1. 阅读并遵循「按需加载」中的主提示词（覆盖清单、输出结构、质量要求）。
2. 只补充真正影响结果的项目上下文：范围、环境、限制、风险、依赖、期望产出。
3. 信息不全时先给可用初版，并显式标出假设与信息缺口。
4. 默认 Markdown；用户指定其他格式时再切换。
## 核心约束
- 按风险/业务影响排优先级，不要平均摊铺。
- 把「已确认事实」和「当前假设」分开写。
- 不要编造用户未提供的接口、字段、环境或根因细节。
- 结果必须可执行：场景具体、有优先级、能指导下一步。
## 按需加载
- 产出前必须阅读并遵循 `prompts/requirements-analysis.md`（最低覆盖清单、输出结构、质量要求）。
- 需要 Excel/CSV/JSON/Word 等格式时：读 `output-formats.md`，并按用户格式要求输出。
- 需要套用现成模板时：读 `output-templates/` 中匹配的模板，不要自创冲突结构。
- 用户要示例或对标现有资产时：读 `examples/` 中相关样例。
- 需要框架规范、排障、报告 schema 等深资料时：只读 `references/` 里与当前问题相关的文件，不要整目录通读。
- 需要格式转换或辅助校验时：优先使用 `scripts/` 中已有脚本，而不是重写一遍。
- 需要评测/回归本 skill 时：使用 `evals/`，并用 skill-up 校验与运行。
- 用户只要最短上手路径时：读 `quick-start.md`。
## 交付前自检
- [ ] 已遵循主提示词的输出结构
- [ ] 最低覆盖关注：范围总结、业务目标、明确和不明确的需求、缺失规则、边界和异常条件、可测性缺口、依赖和影响、风险优先级…（细节以主提示词为准）
- [ ] 已覆盖最低清单，或标明为何省略
- [ ] 高风险项有明确优先级
- [ ] 未编造用户未提供的细节
- [ ] 假设与信息缺口已标明
## 常见误区
- 范围和上下文都不清楚时，不要假装已经完整可用。
- 不要把所有项写成同等重要。
- 不要跳过假设与信息缺口。
- 不要输出大段与当前工具链无关的空泛理论。