需求架构文档范本

创建人员：<创建人员>
文件职责：提供复杂需求第一版交付时可参考的架构文档写法，说明整体结构、模块关系、公共能力、唯一归属和工程化范围。
管理规范/模板：../../common/pro-doc/需求规范.md；../../common/pro-doc/需求架构文档范本.md。
引用文件：需求总纲.md；需求设计.md；需求模块说明文档范本.md；需求核心流程文档范本.md；需求审计报告.md。
记录方式：参考范本；不是逐项填空模板。具体项目可按需求复杂度裁剪，但不得漏掉会影响架构理解的关键内容。

1. 使用口径

本文件是“架构文档参考范本”，不是强制模板。

适用场景：

1. 第一版需求模块较多。
2. 需求有多个上下游。
3. 需求包含公共能力、业务模块、归档或审核链路。
4. 不先讲清架构，后续需求文档容易拆乱。

不适用场景：

1. 单一小工具。
2. 单一规则说明。
3. 只改一份需求文档的小改动。

写作要求：

1. 用大白话说明系统由哪些部分组成。
2. 说明每个模块主责。
3. 说明哪些公共能力必须集中实现。
4. 说明哪些业务不能拆散到多个模块里。
5. 不写字段级需求，不写代码实现细节。

2. 推荐结构

2.1 文档定位

回答：

本文档回答什么，不回答什么。

推荐写法：

本文档回答：<需求名> 由哪几个模块组成，各模块主责是什么，哪些公共能力必须集中实现，哪些业务不能拆散到多个模块里。

本文档不是字段级需求，也不是代码设计。字段、CLI、表结构和验收细节以需求文档为准。

2.2 配套文档

列出：

1. 模块说明文档。
2. 核心流程文档。
3. 需求文档。
4. 方法论 / 需求方案 / 总纲。
5. 审计报告。

2.3 一句话架构

用一句话冻结系统边界。

推荐写法：

<需求名> 当前只做一件事：
<一句话说明主目标>

当前不做：
<不做事项列表>

2.4 模块总览

用表说明模块主责。

模块编号不是强制的。简单需求可以不用 P0/P1/P2 命名，但必须让模块主责清楚。

2.5 总体架构图

推荐用 mermaid 或 ASCII 图说明：

flowchart TD
    A[输入 / 来源] --> P0[公共能力]
    P0 --> P1[业务模块 A]
    P1 --> P2[业务模块 B]
    P2 --> P3[解释 / 验收 / 归档]
    P3 --> O[输出 / 下游]

2.6 公共模块定位

如果存在公共能力，必须说明：

公共模块负责：
- 数据读取
- 公共指标 / 公共函数
- 公共字典 / 枚举
- 画图 / 导出 / 归档
- summary / manifest / 基础校验

公共模块不负责：
- 业务裁决
- 生命周期裁决
- 类型裁决
- 人工审核结论
- 买卖动作或其他下游业务判断

如果没有公共模块，写“不适用，原因是……”

2.7 业务唯一归属原则

用表冻结“谁负责什么”，避免后续实现散修。

2.8 当前工程化范围

可以工程化：

<本轮要工程化的能力>

暂不工程化：

<未来能力、研究能力、预测能力、人工流程等>

2.9 核心对象

对需求里最容易混淆的对象做定义。

对象 A：<定义>
对象 B：<定义>
对象 C：<定义>

3. 好架构文档的判断标准

通过标准：

1. 人能看懂需求由哪些模块组成。
2. 人能看懂模块主责和边界。
3. 人能看懂公共能力在哪里集中。
4. 人能看懂哪些能力本轮不做。
5. 后续需求文档能挂到对应模块上。

不通过标准：

1. 只写愿景，没有模块。
2. 模块职责交叉。
3. 公共能力散在多个模块。
4. 把字段级需求和代码细节塞进架构文档。
5. 没写不做事项，导致范围失控。