---
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:
  display-name: "Req Deconstruction"
  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/three-layers.md)（三层详解 + 五问法 + 反模式） |
| 逐维拆解，要子项清单 | [`references/five-dimensions.md`](references/five-dimensions.md)（五维框架 + 每维易漏子项） |
| 写需求解构表或业务规则表 | [`assets/requirement-table.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. 常见反模式

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

## 8. 交付前自检

- [ ] 显性需求完整提取（含约束条件与非功能需求）
- [ ] 隐性需求按五问法逐条追问，且每条标了 `[推断]` / `[假设]`
- [ ] 衍生需求均有场景支撑或已标 `[待确认]`
- [ ] **五维全部拆过**——状态/输出/规则三维未被跳过
- [ ] 每条需求都连带了业务规则，规则已结构化
- [ ] 规则冲突已问清优先级（未问清记入疑问）
- [ ] 疑问点已列出并交 `qa-question-framework`，未自行假设填充
- [ ] 需求 ID 格式为 `REQ-`，无 `TC_` 混用
- [ ] 未提前跳入测试用例设计
- [ ] 覆盖率已标注口径，无"全覆盖/100%"绝对化表述