需求分析技能
何时使用
- •新建项目时：分析用户需求、拆分任务、制定验收标准、评估风险
- •变更开发时：在代码理解基础上，分析变更需求、评估影响范围、拆分变更任务
输出格式
按 process_templates/requirements.md 模板格式输出。
输出规范
需求文档必须包含以下章节：
| 章节 | 必填 | 说明 |
|---|---|---|
| Summary | 是 | 项目/变更标题、背景、目标 |
| Scope | 是 | 范围内/范围外 |
| Constraints | 是 | 技术、安全、时间约束 |
| 功能需求 | 是 | FR-{编号}: 需求描述 |
| 非功能需求 | 是 | NFR-{编号}: 性能/安全/可用性等 |
| 验收标准 | 是 | AC-{编号}: 可验证的标准描述 |
| 任务拆分 | 是 | 含 ID、描述、优先级、依赖 |
| 风险评估 | 是 | 至少评估技术风险和资源风险 |
| 影响分析 | 按需 | 变更模式时必选 |
分析步骤
1. 需求梳理
- •从用户描述中提取功能需求和非功能需求
- •识别隐含需求和边界条件
- •标注不明确的部分，准备与用户确认
- •标注需求类型：
new（新建）/change（变更）/bugfix（缺陷修复）
2. 任务拆分原则
- •每个任务应可独立完成和验证
- •任务粒度控制在 1-3 天工时
- •明确任务间的依赖关系
- •按优先级排序：P0（必须）> P1（重要）> P2（可选）
3. 验收标准编写
- •每个需求至少一条验收标准
- •验收标准可验证、可度量
- •格式：
AC-{编号}: {可验证的标准描述} - •每条验收标准标注应由哪层测试覆盖：
code
AC-01: 成功创建资源并返回 201 状态码 测试层级: [单元测试, 接口测试] AC-02: 并发 100 请求下响应时间 < 200ms 测试层级: [系统测试]
4. 风险评估
- •技术风险：技术可行性、性能瓶颈
- •资源风险：依赖、工期
- •缓解措施：每个风险项至少一个缓解方案
5. 影响分析（变更模式必选）
当模式为 change-project 时，必须包含影响分析：
- •受影响模块：列出需要修改的模块及修改原因
- •受影响接口：列出需要变更的接口（新增/修改/废弃）
- •受影响测试：列出需要新增或修改的测试用例
- •向后兼容性：评估变更是否影响现有功能
- •影响分析基于
code-understanding技能输出的逆向设计书
注意事项
- •有疑问必须与用户确认，不得假设需求
- •变更模式下，必须先阅读逆向设计书再进行需求分析
- •验收标准的测试层级标注将直接指导 Tester 的测试计划编写