rd-requirement git:20260807.e82ae86A

Immutable. This exact content never changes and is served at /api/v1/blob/0fc9101727341640.

---
name: rd-requirement
description: >-
  把原始诉求、会议纪要、干系人反馈或业务场景转化为 PRD、SRS、结构化需求
  或追踪材料。当产品、系统、基础设施或 AI 工具需求的范围、角色、规则、约束、
  优先级和验收需要显式化、可验证时使用。可行性判断、设计、评审和实现分别路由到其责任工作流。
---

# rd-requirement

将用户原始诉求转化为**结构化、可追溯、可验证的需求文档**。

## 交付物

- 结构化需求文档（PRD / SRS / 用户故事集）
- 用户角色与场景模型
- 干系人分析矩阵（复杂项目）
- 需求追踪矩阵（可选）

## 执行步骤

### 1. 需求采集与澄清

- 区分用户原始表述和结构化需求，保留原始表述不篡改意图
- 识别隐含假设，显式列出
- 先从用户提供材料和项目中核实可查事实，再向用户提问
- 只询问需要用户决定或会阻塞决策的模糊点；高影响决策每次处理一个分支，低风险假设可显式标注后继续
- 识别含义过载或相互冲突的领域术语，提出规范术语，但不得编造业务含义
- 使用 5W1H 框架（Who / What / Why / When / Where / How）覆盖需求维度

**完成标准：** 每个影响决策的歧义均已解决，或明确归入假设、未决决策或验证动作；可从材料中查明的事实不再作为用户问题遗留。

### 2. 需求分类与结构化

按以下维度分类整理：

| 类别 | 内容 |
|------|------|
| 功能需求（FR） | 系统必须做什么 |
| 非功能需求（NFR） | 性能、可用性、可扩展性、安全性、兼容性 |
| 约束条件 | 技术栈、平台、法规、预算、时间 |
| 假设 | 未确认但影响设计的前提 |
| 排除项 | 明确不做的事项 |
| 运行环境 | 环境、拓扑、用户能力、支持、迁移和生命周期约束 |

面向文档型项目时，额外分类：

| 类别 | 内容 |
|------|------|
| 干系人 | 用户、业务负责人、评审方、维护方、外部主管机构 |
| 业务规则 | 政策、流程、审批、合规或运行规则 |
| 数据与接口 | 所需数据对象、外部系统、交换边界 |
| 证据来源 | 会议纪要、标准、既有文档、法规、产品决策 |

**完成标准：** 每个范围内场景均映射到已识别的角色、规则、数据或接口边界，并至少对应一项已分类需求或明确排除项。

### 3. 优先级标注

每项需求标注优先级：

- **P0（Must Have）**：不实现则项目失败
- **P1（Should Have）**：重要，但可在下一迭代
- **P2（Nice to Have）**：有则更好
- **P3（Won't Have）**：已识别但明确排除

**完成标准：** 每项需求均按选定的分级规则具有明确优先级；优先级冲突或决策权缺失已记录，而不是由代理静默裁定。

### 4. 验收标准定义

每项功能需求附可验证的验收标准：

- 适合时使用 Given / When / Then 格式
- 覆盖正常路径、异常路径、边界条件和评审/审批证据
- 非功能需求必须给出可度量阈值或明确评估方法
- 政策或文档类需求必须给出评审标准和验收证据
- 安装、配置、迁移或集成需求应定义可观察终态、核验方法、失败行为和回退期望，但不得预设未经批准的实现方式

**完成标准：** 每项需求均有可检查的验收或评价方法，覆盖重要的正常、异常和边界行为；否则明确标为未决并附验证动作。

### 5. 可行性与证据标记

标记需要证据或后续可行性决策的需求，但不在本 Skill 中判断是否可行：

- 证据状态：已核实、假设、有争议、未知或由责任人决策
- 风险路由：识别需要 `rd-feasibility`、干系人确认或标准/法规核验的需求
- 依赖标注：识别上游决策、外部系统、审批和标准引用

**完成标准：** 每项可能实质失败或阻塞交付的需求均有证据状态、明确依赖或后续动作；需要可行性结论时具有清晰的下游路由，且本交付物没有越权作出该结论。

### 6. 需求收敛检查

交付前，对结构化需求执行一次无损重写，形成权威基线：

- 把重复事实、规则和场景合并到唯一归属章节
- 在保留对应决策后，删除已解决问题和临时需求获取笔记
- 保留每个需求 ID、来源锚点、决策、约束、优先级和验收映射
- 从头到尾重读文档，重新打开任何矛盾、缺失的验收方法或未解决的阻塞性决策

**完成标准：** 仅保留一份权威且内部一致的需求基线；标识和映射没有丢失，临时笔记中也没有隐藏未解决阻塞项。

## 上下文与基线检查

执行前检查：
- 适用的项目说明、需求模板和规则
- 是否有已固化的产品标准或质量属性基线
- 已有需求文档的格式和命名约定
- 是否有术语表、干系人清单、评审 checklist 或标准术语约束

## 工具选择

- 外部检索前先检查用户提供材料和本地项目来源
- 法律、标准、政策、外部接口或其他证据会实质影响需求时，使用 `rd-research`
- 只使用已配置工具，优先一手来源；仅在核实当前库或 API 接口事实时使用文档检索能力
- 无法检索时标记证据缺口，不得据此编造需求

## 质量门禁

交付前核查：

- [ ] 所有已识别且纳入范围的核心场景均已覆盖，并可追踪到来源或决策
- [ ] 每项功能需求有验收标准
- [ ] 优先级采用明确标准，每项已识别 P0 需要均映射到需求或显式排除项
- [ ] 假设和排除项已明确列出
- [ ] 每项需求都有验收方法，或已明确标记为未决并给出核验动作
- [ ] 除非已批准为约束，否则候选产品、模型、厂商、工具或配置已与底层需求分离
- [ ] 术语、干系人角色、业务规则一致
- [ ] 影响决策的模糊点已解决或单独列出
- [ ] 需求可追溯到用户原始表述或被引用资料
- [ ] 最终收敛检查已消除重复，且未丢失 ID、来源锚点、决策或验收映射

## 不做

- 不跳过需求澄清直接进入设计
- 不在需求分析阶段做技术选型
- 不给不可验证的需求放行
- 不编造业务规则、标准条款、指标或干系人决策