需求设计文档模板

需求设计文档

1. 需求分析

1.1 背景

说明清楚需求产生的背景，通过背景来明确上下文，统一语境。包含但不限于我们是因为什么原因衍生出的需求，问题是谁提出的，需求是怎么产生的，即来自于各方的一句话需求。

比如我们要做混合云，是因为我们不想只做纯私有化项目，这对我们积累用户没有好处，市场天花板太低，而为了满足客户私有化的述求，我们衍生出混合云的方案。

相关名词解释：

1.2 角色与价值分析

分析清楚这个需求会服务于哪些角色，对于这些角色能带来什么价值。这部分内容的核心目的在于搞明白我们要帮助哪些用户解决什么问题，用于帮助我们评估这个需求是否合理，能够产生多大的价值，以决策我们是否需要开发这个需求。

注意，价值不是拍脑袋的，而是经过专家、用户等经过调研、统计等科学的方法分析得出的。

1.3 用例设计

1.3.1 用例图

输出UML用例图，确定功能边界。

1.3.2 测试用例设计

列出在本次需求范围内的用例骨架，目的是为了辅助我们开发，理清业务关系，确定需求的异常边界

1.3.3 非功能性需求分析

1.3.4 SaaS、私有化特殊需求

有些需求是仅存在于SaaS，或仅存在于私有化的，需要特别标明出来，以便在后续的设计过程中，需要明确处理措施

1.4 业务流程设计

输出UML活动图，确定核心场景的业务流程。核心场景，即指一个业务的主线流程，其他用例都是围绕这个流程展开的。

1.5 上下游组件关联需求分析

列出与当前需求相关的上下游系统需求，分析是否需要上下游需求联动变更。可以这么自检：每一个用例，确认只需要当前的系统就能完成的吗？是否需要其他组件的配合

2.系统设计

推荐使用领域驱动设计辅助分析，适用于业务系统，围绕业务进行分析。

领域设计模板说明：

P.S. xmind 只适用于前期的设计讨论，不能作为设计结论。最终必须输入下边的领域模型、数据模型。评审时，也只以领域模型和数据模型、部署图、代码架构进行讨论

2.1 业务模型

业务建模过程，建议根据 DDD 领域驱动设计，分析出相关的领域及其关系。可以使用包图+类图来表达。属于对系统的纵向描述

2.2 主要时序图

通过时序的角度描述系统之间、业务模型之间的关系，时序图应该覆盖核心的需求场景

1. 根据部署图，画出上下游系统的交互顺序
2. 根据业务模型，画出各业务之间的交互顺序

2.3 数据库设计

2.3.1 数据模型

基于上述的业务模型，分析出适合业务场景的数据模型，使用 E-R 图来表达。注意：数据模型和业务模型并不一定是一一对应关系，数据模型的设计应参考数据库的设计范式

2.3.1.1 数据库索引设计

注意：以下为举例，复制模板时需删除

2.3.2 DBMS 设计

描述所使用的数据管理系统基本信息，可使用如下表格描述：

2.3.3 数据容量评估

根据当前采用的 DBMS，预计可满足什么时间范围内的业务场景。当规模达到什么程度，需要进行设计演进，演进的方向是什么。

3.兼容设计

3.1 依赖兼容表

根据系统上下文进行分析，不同的版本是否能兼容

3.2 不兼容策略

说明清楚对不兼容版本/接口的处理策略，比如采用强制升级，服务降级等

4.API 设计

附上 API 文档地址，API 文档需要包含使用说明

附上 消息协议 文档地址（如有），API 文档需要包含使用说明

4.1 API 使用方法

根据用例场景，描述每个场景中api的用法，如果有消息协议，也表达出消息是什么时候发出的

4.2 API 安全自查

参考 安全自查手册，确认是否在设计中已经完整覆盖安全检查项

5. 详细设计

画出领域模型里，相对复杂，不能用几句话描述清楚的部分，拆分出不同的功能模块，注意引入设计模式来解决问题。

每个领域核心的类，需要列出对应的接口设计。按照历史经验，接口设计很容易出错，抽象、依赖关系设计不合理

6.上线策略

这里的策略指的是上线的方法和步骤。

例如（灰发）：

1.修改生产环境配置 ，这里需格外注意配置的兼容性

2.发布灰发版本，灰发的规则是什么，比如：灰发至特定地区

3.灰发过程中需要关注的应用状态

如果直接上线，请说明原因，以及直接上线的步骤，一般情况不推荐直接上线。

灰发

7. 已知问题

枚举出目前遗留的、目前的设计未解决的问题，未明确的需求等

8. 引用

用于输出上述图片的的原始文件，或者一些辅助说明，在文档中不好表达的文件，方便后续编辑维护

包括设计过程中的调研的相关资料等