qa-req-deconstruction

将模糊的需求描述系统化拆分为输入、操作、状态、输出、规则五个可测试维度，同时挖掘显性需求之外的那些"没写出来但必须满足"的隐性需求和衍生需求。当用户的需求描述只有一两句话、或者看起来功能很简单但你可能遗漏了什么的时候，一定要用此技能做深度解构。适用于任何测试任务的第二步骤——无论需求文档有多详细，解构之后总能发现盲区。每条需求带唯一 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.

kokxi@kokxi

Install

openclaw skills install @kokxi/qa-req-deconstruction

⚠️ 本技能单独使用效果有限，建议配合完整技能集（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. 常见反模式

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