四、产品开发设计文档（需要包括硬件和软件两个方面）
4.1 硬件文档撰写思路
1）首先是需求定义或产品规格：
如果这些是产品最终目标的话，那么产品对硬件和软件的要求就是技术方案的最终目标；对硬件和软件的要求是从定义用户界面和系统功能开始的。
2）其次，根据需求，系统整体定义文档中给出硬件接口的具体定义：
定义硬件最有效的方法是从需求开始描述，由于硬件必须支持系统定义的所有功能，因此硬件定义是与系统说明不可分割的；
例如,我们设计一个定时器（事先需求说明定时器不能与个人电脑连接，故无法使用CRT显示时间），我们只有两种选择：一种是使用发光二极管（LED），另 一种是使用液晶显示器件（LCD）；尽管LCD的显示效果比较好，但考虑到定时器要常年位于户外，并且早期LCD显示器不能在低温下工作，最终还是选择 LED设备（这整个过程描述了我们硬件选型时的一个思路，这个是密切跟需求挂钩的）
3）一旦完成了系统整体说明文档，就开始进行系统设计：
首先要对硬件说明的内容进行细化，包括添加能让工程师理解的设计意图，以及软件工程师围绕硬件进行程序设计时需要使用的硬件信息等。
完成硬件电路板说明文档后，我们还要在该文档中增加一个用来描述系统的原始要求的前言部分，包括说明方案的设计思路和方法，除此之外，还要附上软件工程师用来对硬件进行控制所需的各类信息，这类信息主要包括如下内容（软件工程所需信息）：
-----内存和I/O端口地址（如果需要，还可以提供内存映射图）
-----可用内存容量
-----状态寄存器每一位的定义
-----每个端口管脚的用途
-----外部设备的驱动方法（例如，说明输入定时器电路的时钟频率等）
-----其他有管软件人员设计程序需要了解的信息
对于比较复杂的系统来说，硬件文档中经常使用两个独立的部分来进行说明；其第一部分用来描述硬件指标和工作原理，第二部分则主要为软件人员提供程序设计需要的信息。
4.2 软件文档撰写思路
1) 软件文档与硬件文档的组织方法类似，软件要求文档的主要内容则是定义软件要实现的功能；一种是在简单项目设计过程中，软件定义也可以只对一种电路板使用的 软件给予描述；对较复杂的项目来说，由于参与这种项目的软件人员分别负责设计驱动不同硬件部分的代码（同一电路板），因此每个软件人员可能会为自己的设计 代码指定不同的定义,这类软件说明需要提供下列的内容：
-----论述包括需求定义、工程指标、硬件参数等实施项目需要的内容
-----说明软件之间、处理器之间或处理器与其内部器件之间使用的通信协议：其内容应包括对缓冲区接口机制、命令/应答协议、信号控制等协议的具体说明。
-----借助流程图、伪代码或者其他可能的方法来描述软件的实现方法和过程
2) 软件与硬件所考虑的不同之处（此经验方便技术总监或其他相关管理者参考，因为无论是多高深的技术管理者，要么是硬件出身，要么是软件出身，要么就是非技术出身）
a. 软件的灵活性远远大于硬件，要让软件人员搞清楚某个软件的内部格式是非常困难的任务，解决的办法：详细定义其他程序员需要了解的编程接口具体内容，以及其他工程人员在实施开发项目过程中需要使用的技术细节信息。
b. 软件工程师只有在收到硬件说明文档后，才有可能知道如何对系统硬件进行操作；而硬件人员一般不需要了解软件程序的技术细节。
c. 由于软件易于更改，因此程序内容经常会按销售人员提供的要求发生变更，在某些情况下，软件文档的内容无法及时反映程序的最新变化。
d. 软件经常是工程项目最后完成的部分，因此其文档也经常因时间不够而欠缺完整。实际上，软件文档是否详细、完整，在某种程度上是与公司或客户的要求有关的。例如，军事或国家工程一般要求开发商就其所有软件实现的功能提供全面详细的文档
e. 有个潜规则，对软件的要求越复杂，则需求的正确可能性就越小，这个是经验之谈了，我们需要把准需求这个准绳来做文章，而不是陷入个人主义以及对软件要求而凭空发挥自己不切实际的想象。
f. 我们可以先硬件设计，接着围绕该硬件编制软件。虽然实际系统的实现过程可能是软硬件并行开发，但软件人员基本上也是围绕着已经实现的硬件来进行程序设计的；对于更为复杂的系统来说，开发过程可能会出现重复。
例如，某个项目的硬件工程师和软件工程师可能会坐下来开会，共同决定使用哪种硬件来实现某种功能；软件人员可能提出需要为数据缓冲区口冲内存容量，也可能要求提供某种外部设备接口，以便充分利用现成接口程序提供的各种驱动代码。
总的来说，必须在提高软件开发效率与硬件系统的复杂性与成本之间进行权衡.