# L2 需求分析

## 目标和边界

将业务需求转换为研发可理解的功能范围和业务子任务，说明需要改变哪些能力、可能涉及哪些工程。本阶段描述“需要开发什么”，不展开完整实现设计。

## 执行流程

```text
归档原始需求版本
→ 通读全部材料
→ 识别矛盾和问题
→ 按业务能力拆分
→ 更新并阅读代码副本
→ 调查架构、文档、接口和代码
→ 识别涉及工程及复用
→ 编写技术侧需求解读
→ 编写各子任务 01 文档
→ 更新关联和 STATUS
→ 提交 G1
```

拆分前必须完整阅读需求及相关附件。

## 按业务模块拆分

使用可独立识别的业务能力，例如：

```text
品牌重构
├─ 品牌管理
├─ 品牌审核
└─ 品牌授权
```

子任务应具备可识别的业务目标、参与者/流程/状态边界、验收结果或独立交付能力。不得将前端、后端、数据库直接作为一级业务子任务；技术工作放入适用的业务子任务内部。

记录前后置依赖、共享能力、接口、数据、联调顺序和联合测试要求。只有跨模块公共能力可以独立设计、交付和验证时，才建立公共技术子任务。

## 技术侧需求解读

需求分析应说明：

- 业务背景和目标；
- 对业务需求的技术侧解读；
- 范围和非目标；
- 业务模块与子任务；
- 需要新增、修改、复用、废弃或迁移的功能；
- 涉及工程及原因；
- 现有能力和复用判断；
- 接口、数据及上下游影响；
- 非功能要求；
- 发布、迁移、灰度、兼容、回滚和上线后验证要求；
- 依赖、风险和待确认项。

本阶段不提供完整类与方法设计、完整字段级接口定义、详细表结构或逐文件实现步骤。

使用 `已确认`、`待确认`、`待代码核实`、`技术建议` 标注结论来源。不得将推导结果写成原始需求事实。

## 识别涉及工程

根据架构文档和已记录 Commit 的代码证据调查：

- 入口和调用链；
- 模块依赖；
- 现有接口及调用方；
- 领域与数据模型；
- 认证和授权；
- 消息、事件和定时任务；
- 下游与外部系统。

记录：

| 工程 | 当前职责 | 涉及模块 | 影响原因 | 预计变更类型 | 证据 |
|---|---|---|---|---|---|

不得只根据仓库名称推断。

## 复用分析

每个功能按以下类型分类：

```text
直接复用 / 扩展复用 / 适配复用 / 需要修改 / 需要新增 / 需要废弃或迁移 / 待确认
```

指出具体接口、模块或代码符号及其复用边界。用户指定原接口时，记录当前调用方、当前行为、问题、目标行为、兼容性、保留/废弃策略、影响和回归需求。

## `01.需求分析.md`

每个子任务至少包含：

```markdown
# ST-XXX 子任务需求分析

## 1. 文档信息与需求来源
## 2. 目标、范围与非范围
## 3. 业务规则、角色和权限
## 4. 正常流程、异常流程和状态流转
## 5. 功能点清单
## 6. 涉及工程及现有实现
## 7. 复用、新增、修改和迁移分析
## 8. 接口、数据及上下游影响
## 9. 非功能与上线要求
## 10. 子任务依赖
## 11. 验收标准
## 12. 需求矛盾、风险和待确认项
```

功能使用 `F-001` 等稳定编号，验收标准使用 `AC-001`。链接到大需求和原始需求版本。

## 提交 G1

提交以下完整确认包：

- 大需求级 `技术侧需求分析.md`；
- 业务子任务拆分；
- 全部子任务的 `01.需求分析.md`；
- 范围与非范围；
- 需求矛盾、待确认项和风险；
- 当前原始需求版本；
- PM 编号；尚未确定时由用户在本次评审中决定；
- 相关文档链接和版本。

用户确认 G1 后才能开始技术方案设计。确认结论必须写入 `STATUS.md` 并绑定上述版本。