126 lines
3.8 KiB
Markdown
126 lines
3.8 KiB
Markdown
# 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` 并绑定上述版本。
|