# Requirements Analysis

> 面向软件、AI、模型、算法、算子和平台项目生成或修订开发前视角的完整需求分析报告。用于识别客户真实需求、拆解需求组成、调研并选择技术方案、评估技术/数据/资源/交付/运营/合规可行性、估算工作量、判断是否值得做、定义需求与验收标准、确定优先级和建立需求基线；也适用于用户只提供穿刺需求、已有代码、测试或实验，但要求补齐正式需求分析思路和报告的场景。现有实现只能作为技术调研材料，不得把完成情况、测试结果或上线效果写入需求报告。

- Skill: `kirrito-k423/requirements-analysis` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add kirrito-k423/requirements-analysis`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kirrito-k423/requirements-analysis/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Kirrito-k423 (https://skillmd.com/u/kirrito-k423)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kirrito-k423/requirements-analysis

---


# 需求分析

## 目标

输出一份服务于立项、范围确认、技术选型、排期和验收的**开发前决策合同**。报告必须回答：

1. 客户和用户真正需要什么；
2. 需求由哪些业务、用户、功能、质量、接口和约束组成；
3. 现有技术为什么不满足，有哪些候选方案，为什么推荐某条路线；
4. 项目在技术、数据、资源、交付、运营和合规上是否可行；
5. 需要多少工作量，价值是否大于成本和风险；
6. 每条需求如何定义、如何验收、由谁批准。

## 固定叙事时点

无论输入发生在开发前还是开发后，最终需求报告都冻结在**正式开发决策发生前**。

| 可以写 | 不可以写 |
|---|---|
| 系统应、必须、拟采用、计划验证 | 已实现、已支持、已通过、已上线 |
| 候选方案、PoC 结论、预期收益和风险 | 完成率、提交清单、测试结果、线上效果 |
| 验收对象、环境、步骤、阈值和证据形式 | 验收通过/失败结论 |
| 工作量区间、依赖和置信度 | 根据实际耗时倒填的“原估算” |
| 推荐、拒绝、延后或继续调研 | 因为代码已经这样写，所以选择该方案 |

如果用户提供已完成代码、测试、基准或日志：

1. 把它们放入分析工作底稿，用于识别当前接口、约束、异常场景、技术成熟度和估算依据；
2. 不用代码结构定义用户需求，不用测试名证明客户价值；
3. 将实测数字视为候选基线或 PoC 证据，只有在环境、统计口径和阈值责任人确认后才能进入验收计划；
4. 正文不描述实现完成状态，不建立“需求—已完成代码—测试结果—上线结果”矩阵；
5. 若材料暴露出需求冲突，回到用户、场景和决策条件请求确认，不以当前实现自动覆盖需求。

## 强制规则

- **先识别需求，再研究方案。**新模型、新算法、新算子或新硬件只是机会信号，不自动构成需求。
- **区分需求与解决方案。**客户提出的按钮、模型、接口或框架是候选手段，必须追问其任务、影响和期望结果。
- **技术调研必须由需求驱动。**每个候选方案都用同一组需求、质量、成本和风险准则评价。
- **估算必须表达不确定性。**记录范围假设、证据、区间、依赖、风险缓冲和失效条件，不输出伪精确人天。
- **需求必须可验收。**“更快、稳定、易用、精度无损、成本低”等词必须转换为有环境边界的可观察阈值。
- **只用必要方法。**每种方法都要对应一个待消除的不确定性，禁止为了显得专业机械堆叠术语。
- **不得虚构。**不编造客户、访谈、业务损失、预算、阈值、候选方案、审批或历史决策。
- **保护无关工作。**遵循仓库中的 `AGENTS.md`，记录 Git 状态，不修改实现代码或无关文件，除非用户另行要求。

## 输入与就绪条件

先收集用户已提供的材料，再只定位完成报告所需的上下文。

### 最小输入

- 一个问题、机会、客户诉求或技术机会；
- 目标产品、系统或能力的大致边界；
- 预期报告路径或交付形式。

### 强支持输入

- 客户访谈、工单、事故、日志、业务数据、现行流程和绕行方式；
- 用户角色、决策者、运维者、维护者和受影响团队；
- 当前架构、接口、性能基线、代码、测试、实验和技术文档；
- 候选方案、预算、时间窗、人员能力、依赖、合规和资源约束；
- 指标责任人和最终验收人。

材料不足时不要停在“信息不完整”。先生成**待确认的问题清单、假设、所需证据和可继续推进的分析部分**；只有缺少的选择会实质改变目标、范围、方案或立项结论时，才向用户请求决策。

## 工作流程

### 阶段零：建立分析合同

1. 定义产品层级、分析对象、决策问题、报告读者、时间边界和明确非目标。
2. 记录当前已知事实、假设、未知项、资料来源和责任人。
3. 确认报告采用开发前语态；将代码、测试和运行材料标记为内部技术证据。
4. 从 `references/method-selection.md` 选择能消除当前不确定性的方法。

**输出：**分析范围、决策清单、材料清单、假设与待确认项、方法选择记录。

**评审门：**能够说明“这份报告要支持哪个决定”，而不是只知道“公司要求补一份文档”。

### 阶段一：识别客户真实需求

1. 建立干系人地图：客户、直接用户、决策者、运维、维护、测试、安全/合规和受影响团队。
2. 根据场景选择访谈、现场观察、需求工作坊、问卷、文档/现有系统分析。
3. 使用 JTBD 或运行场景描述触发、用户任务、期望进展、当前绕行和不可接受结果。
4. 使用 5 Whys、问题树或假设驱动分析区分症状、直接原因、系统性原因和竞争假设。
5. 量化问题覆盖面、频率、严重度、成本、时间和不做的后果；无法量化时记录测量计划。
6. 用目标树连接业务/工程结果、用户能力和系统能力。

**输出：**干系人表、场景/JTBD、现状流程、问题陈述、根因假设、目标树、成功结果。

**评审门：**目标用户、触发场景、当前差距、期望结果和不做的后果均已定义或显式待确认。

### 阶段二：拆解需求组成

1. 使用系统上下文图确定控制边界、外部参与者、依赖和接口。
2. 按问题选择业务流程/泳道、用例、状态机、时序图、DFD、领域模型或数据血缘。
3. 按用户能力进行功能分解，不按源码目录分解。
4. 建立稳定需求类型和 ID：
    - `BR-*`：业务或工程价值；
    - `UR-*`：用户需要完成的任务；
    - `FR-*`：系统功能行为；
    - `QR-*`：性能、可靠性、安全、兼容、可用、可维护、可观测、成本等质量要求；
    - `IR-*`：用户、系统、模块、硬件和数据接口；
    - `CON-*`：平台、资源、进度、合规和设计约束。
5. 主动覆盖正常、边界、无效输入、部分失败、超时、重试、恢复、回退、升级、维护和退役场景。
6. 记录范围内、范围外、依赖、冲突和隐含假设。

**输出：**Context、流程/场景模型、功能树、需求目录草案、接口与约束、非目标。

**评审门：**每个目标能下钻到用户任务和系统要求；正常、异常、质量、接口和约束没有无意遗漏。

### 阶段三：调研并选择技术方案

1. 建立现有技术基线：当前能力、瓶颈、测量环境、适用边界和不改变时的上限。
2. 扫描标准、论文、官方文档、竞品、开源代码、内部复用、采购、集成、自研和流程优化路径。
3. 至少保留“不做/维持现状”和“最小改造”作为比较基准。
4. 对每个候选记录：原理、需求覆盖、成熟度、依赖、性能/精度上限、兼容、维护、成本、风险和可逆性。
5. 只为会改变决策的关键未知设计 PoC；冻结模型、数据、硬件、软件、精度、并行、样本、预热、重复和统计口径。
6. 使用价值—成本—风险矩阵；架构质量冲突明显时使用 ATAM 风格效用树和质量场景。
7. 形成技术决策记录：推荐方案、拒绝方案、理由、假设、代价、技术债和重审触发器。

**输出：**技术基线、候选清单、PoC 计划/证据、权衡矩阵、技术决策记录。

**评审门：**推荐方案满足所有 Must 需求；关键未知已验证或有明确验证计划；选择理由不依赖“已经实现”。

### 阶段四：评估可行性、工作量和值不值得做

分别评估：

1. **技术可行性**：原理、能力、性能、精度、规模、兼容和成熟度；
2. **数据可行性**：数据存在性、质量、代表性、许可和隐私；
3. **资源可行性**：算力、存储、网络、环境、预算和供应；
4. **交付可行性**：团队能力、跨团队依赖、工期、关键路径和组织边界；
5. **运营可行性**：部署、观测、支持、回退、升级和维护；
6. **合规可行性**：安全、隐私、许可证、行业规则和供应链。

工作量评估：

- 按用户能力和交付物建立 WBS，包含设计、开发、数据、测试、集成、迁移、运维、文档与协作；
- 结合类比估算、自下而上估算和三点估算；
- 对高未知工作先执行 Spike/PoC；
- 记录 O/M/P、范围假设、依赖、风险缓冲、证据和置信度；
- 使用关键路径判断工期，不把总人天简单除以人数。

价值判断：

- 用户/业务结果、工程阻塞、复用价值和战略依赖；
- 不做或晚做的延迟成本；
- 研发、迁移、运行、运维、升级、学习和退出的全生命周期成本；
- 风险、收益置信度、最坏影响和可逆性；
- 使用 MoSCoW、RICE、WSJF 或价值—成本—风险时，说明选择理由和数据边界。

**输出：**六维可行性结论、WBS 与估算区间、价值—成本—风险表、Go / No-Go / 延后 / 继续调研建议。

**评审门：**建议有成立条件，工作量有区间和证据，价值有基线和责任人，阻塞性不可行项已有处置。

### 阶段五：定义需求与验收

每条需求必须包含：ID、类型、规范性陈述、场景/理由、范围、优先级、责任人、验收方法、条件、阈值和容差。

1. 一条需求只表达一个必要行为或约束，使用“系统应/必须”。
2. 功能要求覆盖主流程和异常行为，不提前限定无必要的内部实现。
3. 质量要求使用“刺激来源 → 刺激 → 环境 → 对象 → 响应 → 阈值”的质量属性场景。
4. AI/模型/算法/算子需求冻结任务与人群边界、模型/数据/代码版本、许可证、baseline/candidate、硬件软件精度、seed/采样、预热/重复、能力/系统/业务/护栏指标、回归预算、接管和 fallback。
5. 使用 Given-When-Then 表达用户或外部系统可观察的验收场景。
6. 规定验收证据形式和签字人，但不填写通过、失败或完成比例。

**输出：**批准需求目录、质量场景、AI 评测合同、验收场景和验收计划矩阵。

**评审门：**所有 Must 需求都可观察、可量化、可追踪，并有验收责任人；没有裸露的模糊形容词。

### 阶段六：确定优先级并建立基线

1. 结合价值、依赖、风险、工作量和延迟成本确定优先级，避免所有需求都为 Must。
2. 切分能够独立验证核心价值的最小版本，保留必要的测试、观测和回退。
3. 明确当前版本的非目标、外部依赖、风险、停止条件和重审触发器。
4. 建立开发前追踪链：

```text
问题/机会 -> 干系人与场景 -> 目标 -> BR/UR
          -> FR/QR/IR/CON -> 技术决策 -> 验收场景
```

5. 检查两个方向：每条需求能回到真实问题，每个 Must 都能前向到验收。
6. 建立变更规则：需求、阈值、范围或约束变化时，重新评估方案、工作量、价值和验收。

**输出：**优先级、首版范围、非目标、开发前追踪矩阵、未决问题和审批条件。

**评审门：**首版能够形成价值闭环；所有 Must 需求双向可追踪；未决问题和假设没有被隐藏。

## 生成报告

读取并填写 `references/report-template.md`。使用 `references/method-selection.md` 选择方法，不机械执行所有方法。

如果仓库没有指定位置，默认写入：

```text
docs/requirements/<feature-slug>-requirements-analysis.md
```

最终报告至少包含：

- 开发前视角的执行摘要和立项建议；
- 客户、用户、场景、问题、影响、根因和目标；
- 系统边界、需求拆解、质量、接口、约束和非目标；
- 技术基线、候选方案、PoC、权衡和技术决策；
- 可行性、WBS、工作量区间、价值—成本—风险；
- 需求目录、质量/AI 评测合同和验收计划；
- 优先级、版本范围、依赖、风险、追踪、未决问题和审批条件。

## 质量检查

出现任一情况时拒绝交付：

- 正文从已完成实现开始叙述，或包含完成率、测试结果和上线效果；
- 新技术或客户提出的功能被直接当成真实需求；
- 用户、场景、问题影响、不做后果或成功结果缺失；
- 按代码模块拆需求，或用测试名证明用户价值；
- 候选方案没有统一评价准则，或缺少维持现状/最小改造基线；
- 可行性只评估技术，不评估数据、资源、交付、运营和合规；
- 工作量没有范围假设、区间、依赖、风险缓冲和证据；
- 价值判断没有基线、延迟成本、生命周期成本和风险边界；
- 质量需求使用模糊形容词而没有环境与阈值；
- PoC 结果被直接当作正式验收结果；
- Must 需求没有验收条件、责任人或开发前追踪链；
- 报告包含“实现对应、已完成代码、测试通过状态、线上业务结果”等复盘章节。

交付前运行相关 Markdown 校验，并报告：

1. 报告路径和分析边界；
2. 真实需求、需求条目、候选方案和验收场景数量；
3. 可行性结论、工作量区间和立项建议；
4. 未确认假设、阻塞项和最小责任人问题；
5. 已执行的验证。