[模块名] · 需求分析文档

面向客户、产品、设计、实现和验收。用户要求记录新模块讨论成果或进入已授权的新模块实施时建立本文档，此后持续维护；仅要求讨论或审阅时只交付结论。讨论稿记录已知范围、来源和未决问题；文档版本按文档版本规则递增。具体表名、接口参数、类名和组件实现放入设计文档。

文档控制

项目	内容
模块名称
文档版本	0.01
编写日期
最近核对日期
业务确认人
原型或资料来源

讨论阶段只填写已有依据的内容；尚缺的关键事实标为“待确认”并写明影响，尚未核实的资料标为“待核对”，合理假设注明依据，不把空白模板当作已确认需求。业务确认人未确定时填“待确认”。原型只用于理解业务，不作为 UI 还原稿；来源须按原型与证据分级，原型示例、占位、重复和界面缺陷不得写成业务规则。数据库设计按其实际阶段记录设计字段与已核实的物理字段，正式交付时按数据库设计规范补全适用范围。

1. 背景与目标

1.1 业务背景

• 当前问题：
• 产生原因：
• 影响对象：

1.2 建设目标

• 目标一：
• 目标二：
• 完成后的可观察结果：

2. 建设范围

2.1 本期包含

• 待填写

2.2 明确不做

• 待填写

2.3 已确认的技术约束

只记录已确认且会影响方案的约束，例如复用现有认证、权限、工作流、文件存储或数据库兼容要求。

• 待填写

3. 用户角色与使用场景

角色	使用目的	前置条件	主要结果

4. 核心业务场景

场景一：[名称]

1. [角色] 在 [条件] 下发起 [动作]；
2. 系统校验 [业务条件]；
3. 系统进入 [状态]，并通知/交接给 [角色]；
4. 以 [业务结果] 作为完成标准。

场景二：[名称]

按同样格式描述。只写用户可理解的业务行为，不写类和方法调用。

5. 业务规则与状态

5.1 业务规则

编号	规则	来源	状态
R-001		用户业务决定 / 原型业务要求 / 既有契约 / 原型示例或界面缺陷 / 实施者假设 / 待确认

5.2 状态流转

[初始状态] -> [处理中] -> [完成状态]
                 └-> [异常/退回]

说明每个状态的进入条件、可执行角色和离开条件。

6. 权限、异常与非功能要求

6.1 权限与数据范围

• 角色权限：
• 数据范围：
• 越权时的处理：

6.2 异常场景

场景	系统行为	用户提示或补救

6.3 非功能要求

只记录已经确认的要求：安全、审计、性能、兼容性、可用性、文件大小等。

• 待填写

7. 验收标准

编号	角色	前置条件	操作	预期结果	证据
AC-001					页面 / 接口 / 数据 / 日志

已能明确的验收例子覆盖适用的角色、操作与预期结果；讨论阶段尚未确定的旅程标为“待确认”，实现和验收前再补齐受影响的正常、权限、异常及回滚路径。

8. 待确认事项与来源

8.1 待确认事项

编号	问题	影响	负责人	状态
Q-001				待确认

8.2 关键结论来源

编号	结论	来源	最近核对日期
S-001

本文件在用户要求记录模块业务基线或已授权实施时建立；概要设计、详细设计、数据库设计、测试与验收、操作手册按实际阶段且确有内容时建立。独立讨论、需求对焦、前期方案和专项测试/评估稿件放项目根 reports/；未实施或未验证的内容只记录计划与待核对项，不写成完成结论。交付规则见软件交付文档。