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