requirement-analysis

---
name: requirement-analysis
description: 需求分析与拆解技能，支持新建和变更两种模式，输出结构化任务列表和验收标准
---

# 需求分析技能

## 何时使用

- 新建项目时：分析用户需求、拆分任务、制定验收标准、评估风险
- 变更开发时：在代码理解基础上，分析变更需求、评估影响范围、拆分变更任务

## 输出格式

按 `process_templates/requirements.md` 模板格式输出。

## 输出规范

需求文档必须包含以下章节：

| 章节        | 必填 | 说明                           |
| ----------- | ---- | ------------------------------ |
| Summary     | 是   | 项目/变更标题、背景、目标      |
| Scope       | 是   | 范围内/范围外                  |
| Constraints | 是   | 技术、安全、时间约束           |
| 功能需求    | 是   | FR-{编号}: 需求描述            |
| 非功能需求  | 是   | NFR-{编号}: 性能/安全/可用性等 |
| 验收标准    | 是   | AC-{编号}: 可验证的标准描述    |
| 任务拆分    | 是   | 含 ID、描述、优先级、依赖      |
| 风险评估    | 是   | 至少评估技术风险和资源风险     |
| 影响分析    | 按需 | 变更模式时必选                 |

## 分析步骤

### 1. 需求梳理

- 从用户描述中提取功能需求和非功能需求
- 识别隐含需求和边界条件
- 标注不明确的部分，准备与用户确认
- 标注需求类型：`new`（新建）/ `change`（变更）/ `bugfix`（缺陷修复）

### 2. 任务拆分原则

- 每个任务应可独立完成和验证
- 任务粒度控制在 1-3 天工时
- 明确任务间的依赖关系
- 按优先级排序：P0（必须）> P1（重要）> P2（可选）

### 3. 验收标准编写

- 每个需求至少一条验收标准
- 验收标准可验证、可度量
- 格式：`AC-{编号}: {可验证的标准描述}`
- 每条验收标准标注应由哪层测试覆盖：

```
AC-01: 成功创建资源并返回 201 状态码
  测试层级: [单元测试, 接口测试]

AC-02: 并发 100 请求下响应时间 < 200ms
  测试层级: [系统测试]
```

### 4. 风险评估

- 技术风险：技术可行性、性能瓶颈
- 资源风险：依赖、工期
- 缓解措施：每个风险项至少一个缓解方案

### 5. 影响分析（变更模式必选）

当模式为 `change-project` 时，必须包含影响分析：

- **受影响模块**：列出需要修改的模块及修改原因
- **受影响接口**：列出需要变更的接口（新增/修改/废弃）
- **受影响测试**：列出需要新增或修改的测试用例
- **向后兼容性**：评估变更是否影响现有功能
- 影响分析基于 `code-understanding` 技能输出的逆向设计书

## 注意事项

- 有疑问必须与用户确认，不得假设需求
- 变更模式下，必须先阅读逆向设计书再进行需求分析
- 验收标准的测试层级标注将直接指导 Tester 的测试计划编写