第二章 项目文档管理
文档管理的重要性
略过前期的需求调研以及立项不提，从某些角度来说，文档编写，是一个项目真正开始的点。文档的可以说是整个设计、验证的依据。比如，对于设计而言，它的所有设计都来源于设计说明书，如果设计说明书有错误，那么设计出来的代码，也当然会出错，由此可看出文档的重要性。但是有一些公司可能在文档管理上比较放松，可能不做或者只做部分文档，也有可能在项目做完之后才反过来写文档。其实在某些时候，这样做也没有大问题，比如在项目紧急或者某些功能不确定时，都可以后续再补或者某些不重要的文档可以不写。但是，如果在标准化的大公司，讲究流程完全标准化，这一步骤是完全不能打折的。因为在文档上的一个小疏忽，可能会造成巨大的损失。那么，既然文档这么重要，那么接下来我们就对到底有哪些文档以及这些文档要怎么写来大致做一个介绍。
文档分类与介绍
在一个项目的整个周期中，全部加起来，少则十几个，多则几十个上百个，根据项目的需求、规模而变化。比如对于一个超大型项目，在写具体的RTL架构设计文档时，可能每个模块或者IP都需要一个单独的文档。
项目需求文档
项目需求文档，是一个项目设计的方向。关于项目怎么设计，设计的规则，验收的准则等等，都可以包含在其中。需求文档需要包含一些基本的要素，诸如需求的描述，需求的优先级以及必要性等等。需求文档可以写的很详细，也可以写的比较简略，但是关于整个项目的主要设计方向，需求文档中都应该提到。 需求文档可以由市场人员或者项目负责人调研、编写，需求来源主要是客户或者实际应用需求。
项目设计说明书
项目设计说明书是一个项目文档以及后续设计的核心。它的设计功能点等参考需求文档，于此同时，关于后续整个项目的设计起指导作用。项目设计说明书需要尽量详细，将设计的所有功能，包括硬件定义、软件功能等都需要描述清楚。硬件工程师会以项目设计说明书为大体指导进行硬件设计，于此同时，软件设计人员也会以其中的功能描述，来设计代码、编写设计架构，验证计划等等。因此，项目设计说明书中一定不能有模糊或者错误的地方，否则会引起整个项目的错误。 项目设计说明书在真正开始之前完成，但是可以根据需求或者设计中发现的问题进行修改。
数据手册
数据手册是给用户使用的。当设计说明书完成后，项目管理人员需要根据设计说明书或者其他资料，编写一个数据手册，数据手册的主要作用是对设计的功能进行描述，对设计应用进行指导，不涉及一些具体或者底层的设计细节。
设计架构说明书
设计架构说明书是对代码的架构进行说明的文档，由RTL设计人员在编写代码之前完成。其内容主要包括：结构、输入输出热、时钟复位网络、模块、连接关系等。设计架构说明书的作用是当编写好后，设计人员在设计代码时，就可以参考本文档进行代码的设计，而不用再去考虑模块怎么定义，模块间信号怎么连接等。 设计架构可以在设计中根据实际情况进行修改。
验证计划
验证人员需要在编写测试平台之前，完成验证计划。验证计划需要对验证的工具、环境、架构进行说明，于此同时，需要编写测试用例、特性列表等，对要验证的点进行描述。最后，验证的验收规则以及方法等，是验证最终是否完成的衡量标准。
其他文档
- 会议纪要meeting minute 项目在每隔一段时间都需要进行项目会议，对项目的进度进行归纳总结，对项目中遇到的问题等进行讨论。这个时候就有一个会议纪要，对会议中的主要问题进行记录。与此同时，可能还有一些诸如action list或者todo list，记录某个人接下来需要完成的事情。
- review文档 在每一个节点，完整一个进程的关键点或者整个进程的完成，比如文档或者RTL，都需要组织review会议，这个时候就需要提前准备对应的review文档，模块负责人需要对需要review的模块进行一个概要的文档编写，在会议中对其中的要点进行介绍，然后参与人员可以提出疑问或者建议。
- bug曲线以及提交记录 在验证过程中，会不断发现bug，bug的数量会随着项目的推进逐渐减少，而发现的频率也会逐渐降低。在这个过程中，验证人员需要对bug发现的时间、数量进行统计，绘出bug曲线，看是否符合预期。于此同时，每发现一个bug，都要对bug的提交、确认、是否修复等情况进行记录。 Bug记录以及管理都有专门的软件来处理，也可以自己使用一般的诸如excel等进行。
- 调试记录 在整个软件、硬件调试过程中，设计人员可以对一些关键点进行记录。这样可以在后续中很方便的追溯问题，也可以给后续的项目一些参考。调试记录要尽量详细，包括调试的时间，地点，人员，情况描述，解决方法等。