qa-req-deconstruction
Skill31 starsChanged 48 days agoMITView on GitHub
将模糊的需求描述系统化拆分为输入、操作、状态、输出、规则五个可测试维度，同时挖掘显性需求之外的那些"没写出来但必须满足"的隐性需求和衍生需求。当用户的需求描述只有一两句话、或者看起来功能很简单但你可能遗漏了什么的时候，一定要用此技能做深度解构。适用于任何测试任务的第二步骤——无论需求文档有多详细，解构之后总能发现盲区。每条需求带唯一 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.
In this repository50 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- qa-agent-testingSkill
- qa-ai-blindspot-compensationSkill
- qa-ai-context-engineeringSkill
- qa-ai-output-critiqueSkill
- qa-ai-prompt-strategySkill
- qa-api-testingSkill
- qa-boundary-deep-diveSkill
- qa-bug-lifecycleSkill
- qa-bug-reportingSkill
- qa-bug-root-cause-analysisSkill
- qa-ci-cd-testingSkill
- qa-code-review-for-testSkill
- qa-combination-strategySkill
- qa-critical-thinkingSkill
- qa-domain-modelingSkill
- qa-execution-observationSkill
- qa-expert-reviewSkill
- qa-exploratory-testingSkill
- qa-heuristic-checklistSkill
- qa-input-validationSkill
- qa-mobile-testingSkill
- qa-output-validationSkill
- qa-quality-metricsSkill
- qa-question-frameworkSkill
- qa-regression-testingSkill
- qa-release-risk-governanceSkill
- qa-requirement-reviewSkill
- qa-retrospectiveSkill
- qa-risk-intuitionSkill
- qa-scenario-treeSkill
- qa-shift-leftSkill
- qa-shift-rightSkill
- qa-specialized-testingSkill
- qa-stakeholder-communicationSkill
- qa-state-transitionSkill
- qa-team-coachingSkill
- qa-tech-debt-managementSkill
- qa-tech-selectionSkill
- qa-testability-advocacySkill
- qa-test-automation-archSkill
- qa-test-case-designSkill
- qa-test-data-engineeringSkill
- qa-test-env-dataSkill
- qa-test-estimationSkill
- qa-test-leadershipSkill
- qa-test-reportingSkill
- qa-test-skillsSkill
- qa-test-strategy-designSkill
The file
Files
⚠️ 本技能单独使用效果有限，建议配合完整技能集（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. 常见反模式
- 顺手牵羊：解构时就开始写测试用例 → 解构只做需求分析，用例是下游的事
- 隐藏不标：隐性需求挖出来不标 → 每条隐性/衍生必须带
[推断]/[假设]/[待确认] - 规则遗漏：只拆需求不拆规则 → 每条需求必须连带提取对应业务规则
- 过度衍生：衍生到不切实际 → 必须有场景支撑，否则标
[待确认] - 五维偏科：只做输入/操作 → 五维必须完整
8. 交付前自检
- 显性需求完整提取（含约束条件与非功能需求）
- 隐性需求按五问法逐条追问，且每条标了
[推断]/[假设] - 衍生需求均有场景支撑或已标
[待确认] - 五维全部拆过——状态/输出/规则三维未被跳过
- 每条需求都连带了业务规则，规则已结构化
- 规则冲突已问清优先级（未问清记入疑问）
- 疑问点已列出并交
qa-question-framework，未自行假设填充 - 需求 ID 格式为
REQ-，无TC_混用 - 未提前跳入测试用例设计
- 覆盖率已标注口径，无"全覆盖/100%"绝对化表述
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.