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