接上文，我们分享了标准模板的动机与价值，总结就是标准模板是信息输出者与信息输入者的标准接口。既减轻信息输入者的工作量，不用每次都苦恼信息如何表达，也降低的信息的理解门槛，并且通过对信息的归纳分类，让阅读者可以快速地理解。那么，在代码开发的过程中，有哪些内容是可以做成标准模板的呢？根据实践经验，以下内容可实现标准模板：

1. 需求文档

2. 设计文档

3. 单元测试案例

4. 单元测试报告

5. 检查列表

6. 投产报告

7. 验收报告

以下将对上述模板逐一说明。

需求文档

虽说需求文档是由业务人员编写的，但是日常情况下业务人员是不知道怎样表达 TA 的需求，所以为了不让业务人员“乱来”，还是得让开发人员整理出模板，把想要收集的信息通过模板收集过来。

需求文档包含以下共性内容：

1）需求背景：用于描述需求的提出动机，从而了解需求是因何而提。未来进行需求盘点，需求背景有助于追溯缘由，从而判断需求的状态是继续还是停止了。

2）需求价值：用于描述完成需求能带来的价值，价值描述最好能量化说明，写工作总结的时候就可以发挥巨大的作用了。同时还可以避免业务人员一些随意提出的需求，通过价值描述可以判断需求的重要性，为开发人员反驳需求提供证据。

3）需求描述：对需求内容的简要描述。这里要注明的是，是描述需求而非具体要求。比如业务人员想要在系统添加时间提示功能，可能 TA 的需求描述是在系统的左上角添加时钟提示。虽然需求很明确，但是这不是一个合格的需求，因为业务人员不了解系统，所以这样实现是否适合系统是一个未知数。开发人员要引导业务人员提出 TA 想要的需求：我希望在系统上添加时间提示功能，这样就有空间来落地好需求了。

上述是针对功能性需求的，如果是数据类需求，则需要描述清楚数据的获取口径，以及数据的表达方式，比如报表、数据文本、excel 等。未来会针对数据类的需求分析单独展开篇幅说明。

4）需求方信息：在需求文档的开头或结尾至少附带需求人员的名称、联系方式及时间要求，不然收到需求也不知道业务方是谁，后续的需求分析就无从谈起了。

设计文档

设计文档分为功能类设计文档与数据类设计文档。

1） 功能类设计文档都是增量产生并附加到全局设计的文档中。假如系统的每块功能设计都形成单独文档，以后想要了解系统的全局面貌就很困难了，因为需要把每块拼图都拼接在一起才能了解系统的来龙去脉。哪怕是做个全局索引，也不能让文档东一块西一块的。

功能类设计文档的重点是关联性说明（包括对象的关联、方法的关联、接口的关联）及重要代码说明。关联性说明主要描述本次新增功能与整体系统的关联性，方便未来进行影响分析或者故障排查时追溯。重要代码说明就是把功能的核心逻辑说明清楚来龙去脉，方便其他人了解其设计思想及逻辑关系。

2）数据类设计文档可以作为独立文档单独存储，这是因为数据模型的加工不像系统功能开发般的强耦合性。（所以微服务架构的开发概念才会如此的火，把系统功能间的强耦合性解除，当然凡事都有两面性，微服务一样存在自身的缺点）

数据类设计文档的重点是数据模型的物理描述及映射关系。比如贷款明细表，需要描述贷款账户、贷款合同、贷款客户号、币种及贷款余额信息。首先是设计贷款明细表的物理模型，即时物理表的名称、表空间、主键、索引、外键以及各个字段的名称及类型。接着是设计数据模型与源数据的映射关系，比如贷款账户是直接映射信贷系统借据表的借据号、贷款合同是根据借据号关联信贷系统的合同表获取合同编号。这样开发人员拿到设计文档后就可以直接开发了。