| 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 的测试计划编写
