L2 需求分析

目标和边界

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

执行流程

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

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

按业务模块拆分

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

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

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

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

技术侧需求解读

需求分析应说明：

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

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

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

识别涉及工程

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

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

记录：

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

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

复用分析

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

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

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

`01.需求分析.md`

每个子任务至少包含：

# 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 并绑定上述版本。

3.8 KiB Raw Blame History Unescape Escape