qa-req-deconstruction

面向需求分析与测试准备：把模糊需求按显性/隐性/衍生三层和输入、操作、状态、输出、规则五维做系统拆解，为每条需求与业务规则分配可追溯 ID，列出风险点与待澄清疑问，输出需求解构表、业务规则表和五维拆解结果，不生成测试用例。

kokxi

热度 59.95

最近更新 2026-09-29 12:29:38

分类：开发依赖：读写文件 / 内部调用大模型应用场景：研究 / 报告撰写

安装技能

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

执行命令安装此 skill： npx secure-skills-cli add qa-req-deconstruction

Metadata

displayName: 需求解构
name: qa-req-deconstruction
description: 将模糊的需求描述系统化拆分为输入、操作、状态、输出、规则五个可测试维度，同时挖掘显性需求之外的那些"没写出来但必须满足"的隐性需求和衍生需求。当用户的需求描述只有一两句话、或者看起来功能很简单但你可能遗漏了什么的时候，一定要用此技能做深度解构。适用于任何测试任务的第二步骤——无论需求文档有多详细，解构之后总能发现盲区。每条需求带唯一 ID（REQ-{模块缩写}-{序号}）。触发场景：分析这个需求、需求解构、挖掘隐含需求、需求挖掘、需求分析、拆解需求、业务规则提取、需求模糊需要深挖时。 Use when the user asks about: deconstructing a vague requirement into testable dimensions — inputs, operations, states, outputs, and rules — plus mining implied and derived requirements.
license: MIT
allowed-tools: Read Grep Glob WebFetch
metadata: {"slug":"qa-req-deconstruction","display-name":"需求解构","version":"1.8.0","when-to-use":"用户说\"分析这个需求\"、\"需求解构\"、\"挖掘隐含需求\"、\"需求挖掘\"、\"需求分析\"、\"拆解需求\"、\"业务规则提取\"、上传PRD/需求文档、需求模糊需要深挖时","related-skills":"{\"upstream\":[\"qa-requirement-review\"],\"downstream\":[\"qa-scenario-tree\",\"qa-risk-intuition\",\"qa-ai-context-engineering\",\"qa-api-testing\",\"qa-shift-left\",\"qa-test-case-design\",\"qa-test-data-engineering\",\"qa-test-estimation\",\"qa-test-strategy-design\"]}","references":"[\"assets/requirement-table.md\",\"references/five-dimensions.md\",\"references/three-layers.md\"]","input-format":"{\"required\":[{\"name\":\"需求文档\",\"type\":\"string\",\"description\":\"需求描述，可为纯文本、URL或文件路径\"}],\"optional\":[{\"name\":\"业务背景\",\"type\":\"string\",\"description\":\"业务目标和用户角色\"},{\"name\":\"历史缺陷\",\"type\":\"array\",\"description\":\"同类功能历史缺陷模式\"}]}","output-format":"{\"traceability\":[\"每个需求带唯一ID：REQ-{需求模块缩写}-{序号}（如 REQ-AUTH-001）\",\"每个风险点带唯一ID：RISK-{模块缩写}-{风险类型}-{序号}（风险类型：STOCK/CALC/CONC/TIME/DATA/SEC/PERF/VAL/PAY）\",\"每条业务规则带唯一ID：RULE-{CAL|VAL|PERM|FLOW}-{序号}\"],\"structure\":[{\"requirement_table\":\"需求解构表：需求ID|层次|显性描述|隐性假设|衍生需求|风险点|疑问\"},{\"business_rule_table\":\"业务规则表：规则ID|触发条件|必须满足|验证方法|风险等级\"},\"业务规则统一写成「若X则Y必须满足Z」\",\"层次标注：显性（文档写出）/隐性（追问得到，标[推断][假设]）/衍生（推导得到，无依据必须标[待确认]）\",\"本技能不产出 9 列用例表 —— 用例由 qa-test-case-design 分配 TC_ 编号后生成\",\"覆盖率：标注口径（基于现有需求文档），禁止\\\"全覆盖/100%\\\"绝对化表述；缺失模块标注\\\"未覆盖+原因\\\"\"],\"explicit_requirements\":\"显性需求列表\",\"implicit_requirements\":\"隐性需求列表\",\"derived_requirements\":\"衍生需求列表\",\"business_rules\":\"业务规则结构化\",\"five_dimensions\":\"五维拆解\",\"risk_points\":\"风险点列表\",\"open_questions\":\"待澄清疑问清单\"}","error-recovery-guidance":"{\"on_failure\":\"需求解构遗漏隐性需求时回退到需求评审补充上下文\",\"retry_behavior\":\"补充上下文后重新解构\"}","categories":"[\"Development\",\"Requirements\"]","depth-requirement":"{\"reference_value\":\"见正文「需求数量要求」表：以显性需求数为基准，简单=×2 / 中等=×3 / 复杂=×4（总需求=显性+隐性+衍生）\",\"minimum\":\"隐性需求至少 3 条（占总量约 30-35%）；五维拆解必须完整，不得只做输入/操作\"}"}

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

⚠️ 安全警告：本技能的示例可能涉及订单号、支付金额、截图、身份证、手机号等敏感数据。实际使用时请勿粘贴真实生产数据、客户信息或财务凭证；测试前应脱敏/掩码处理。本技能仅在 workspace/ 输出评估文件，不持久化、不外传、不跨会话复用。

需求解构

核心原则

专家看需求文档，看到的不只是文字，而是背后的测试模型。

层的区别是"来源"：显性来自文档，隐性来自追问，衍生来自推导。无论文档写得多详细，解构之后总能发现盲区——层不清楚，就分不清哪些是"要求的"、哪些是"我猜的"，下游全部会带错。

1. 三层次速查

层次	定义	挖掘方法	数量占比	必做动作
显性	文档明确写出的	逐条编号提取	40-50%	每条判"可测试吗"
隐性	文档没写但隐含的	五问法追问	30-35%	每条标 `[推断]`/`[假设]`
衍生	关联推导出的	角色/场景/边界/关联/数据流	15-25%	无依据标 `[待确认]`

五问法（挖隐性的核心）：

对每个「应该」问"如果不呢？" · 对每个「正常」问"异常呢？" · 对每个「确定」问"假设呢？" · 对每个「存在」问"不存在呢？" · 对每个「并发」问"同时操作呢？"

2. 五维速查

维度	问什么	最容易漏的子项
输入	用户输入什么？	精度（0.001 元这类合法但出错的值）
操作	用户能做什么？	禁止操作（"已支付不能取消"文档通常不写）
状态	系统有哪些状态？	非法状态转换怎么处理
输出	系统返回什么？	错误信息可执行性、多个输出间的一致性
规则	业务规则是什么？	规则冲突时的优先级（文档通常不写）

五维必须完整使用，不可选择性跳过。最常见的失效是"只做输入/操作，忽略状态/输出/规则"—— 因为前三者想得到，后三者想不起来。

3. 需求数量要求

关键指标：以显性需求数为基准，总需求 = 显性 + 隐性 + 衍生。

复杂度	倍数	示例（显性 5 条）	隐性与显性比例	复杂度判断
简单项目	×2	总需求 10 条	1:1	单模块、低风险、无并发
中等项目	×3	总需求 15 条	2:1	多模块、中风险、少量并发
复杂项目	×4	总需求 20 条	3:1	跨模块、高风险、高并发

4. 编号规则

对象	格式	示例
需求 ID	`REQ-{需求模块缩写}-{序号}`	`REQ-AUTH-001`
风险点 ID	`RISK-{模块缩写}-{风险类型}-{序号}`	`RISK-CART-STOCK-001`
业务规则 ID	`RULE-{CAL\|VAL\|PERM\|FLOW}-{序号}`	`RULE-CAL-001`

~~TC_{模块}_{功能}_{序号}~~ 是用例前缀，由 qa-test-case-design 分配，本技能不用。历史版本本技能的 traceability 把需求 ID 写成了 TC_，已修正为 REQ-。 RULE- 已补入 docs/standards.md（原规范缺失此 ID 族）。

5. 加载时机

需要时才读，不要一上来全读：

什么时候读	读哪个
不知道隐性需求怎么挖，或要展开八类隐性清单	`references/three-layers.md`（三层详解 + 五问法 + 反模式）
逐维拆解，要子项清单	`references/five-dimensions.md`（五维框架 + 每维易漏子项）
写需求解构表或业务规则表	`assets/requirement-table.md`（两张表模板 + 填写要求 + 自检）

6. 产出

需求解构表：

需求 ID	层次	显性描述	隐性假设	衍生需求	风险点	疑问
REQ-AUTH-001	显性	密码至少 8 位	允许特殊字符？历史密码可复用？	密码强度提示	弱密码可注册	强度规则由谁定？
REQ-AUTH-002	显性	错误 5 次锁定账号	锁定时长？自动解锁还是人工？	登录日志审计	锁定可被暴力破解绕过	锁定时长是多少？
REQ-AUTH-003	隐性	—	验证码有效期、发送频率、错误次数上限	换绑手机号后旧码失效	验证码可被枚举	有效期与上限各是多少？

业务规则表（统一写成"若 X 则 Y 必须满足 Z"）：

规则 ID	触发条件	必须满足	验证方法	风险等级
RULE-CAL-001	若商品数量 × 单价	则总金额必须等于数量×单价（精度 2 位）	构造小数位金额比对返回值	高
RULE-PERM-001	若用户未登录	则不能访问订单详情，返回 401	未登录直接访问他人订单 URL	高
RULE-FLOW-001	若订单已支付	则不能取消，返回明确错误码	已支付订单点取消	高

本技能不产出 9 列用例表——场景与用例由 qa-scenario-tree / qa-test-case-design 完成。

7. 常见反模式

顺手牵羊：解构时就开始写测试用例 → 解构只做需求分析，用例是下游的事
隐藏不标：隐性需求挖出来不标 → 每条隐性/衍生必须带 [推断]/[假设]/[待确认]
规则遗漏：只拆需求不拆规则 → 每条需求必须连带提取对应业务规则
过度衍生：衍生到不切实际 → 必须有场景支撑，否则标 [待确认]
五维偏科：只做输入/操作 → 五维必须完整