软件开发设计规范书的撰写

软件开发设计规范书的撰写大家好！下午的课讲关于软件开发设计规范书的撰写，一些设计撰写的提纲、解释，在微软我开发了几个产品，具体规范书包括什么内容给大家看一下。

首先讲定义，作为我们开发管理人员，程序经理，开发管理企业的领导等等，到底是应该写什么样的内容，怎么样用它作为指导，帮助我们写软件。

写作计划，到底是在撰写开发计划书开发过程中间，到底要做什么样的工作。

撰写的提纲，大家也知道，做任何事情提纲就好象一份参照表似的，有这样的参照表写作的时候相对来说容易的多，让所有的员工写的时候都按照规范来写。

然后讲一下自己写的实例，最后做一些问答，做一个双向的讨论。

整个软件开发过程是一个相当复杂的流程，并不是简单的靠几个设计工程师自己在那边写软件就完，而是要有从头到尾，包括很多人，不同专家，不同的专业，不同的知识放在一起，最后才造成一个完善的软件产品。

从决定开始，到计划、设计，最后到写程序、执行，然后还有测试、纠错、保证稳定、发行、部署、调试，整个过程是一个相当长的过程，并不是一个简单的程序。

要为了保证软件的质量，能够达到客户满足和满足市场的要求，很要紧的工作，早期工作做的越是完善、仔细，避免后面的工作，由于前面不完善造成的返工，造成的浪费，起到关键性的作用。

大家可能在网上读到在美国软件项目管理的权威，写过很多关于软件管理方面的书，很有名一个理论就是说他做过很多研究和调查，发现早期的工作要是没有做好，而造成后面工作的返工，带来的浪费是巨大的。

有类似这样的图表，他做出的结论，如果在设计阶段出现了问题，在设计阶段如果你没有及时找到和纠正的话，到执行阶段才发现，你会看到三条不同的曲线，越是早期的错没有发现，最后由于要返工而造成的代价费用越来越高，如果前面没有问题，到最后只是发现半个纠错，花费的代价相当低，因为你是纠错，然后重新测试就完了。

可是如果执行的时候，程序编程编错了，后来重新编，重新测试，这个费用相对来说就要高。

如果是设计的时候出现错误，由于对需求管理没有管理好，客户和市场的要求都错了，开发出来的东西完全到后面重新执行、重新纠错的话，会看到这个曲线，几乎是几何形上升的，成倍的费用的增加。

能够保证控制产品开发过程中间的费用增加，早期工作完善，做设计的时候，越早做的越完善，对控制后面的消耗起的作用是非常大的。

从这个方面讲，我早上举的例子造房子一样，造房子的蓝图，对盖一个房子的重要性，对早期设计的完善作用也是一样的。

什么是设计规范书。

大家听过很多不同的名称，叫法也不一样，到底是什么东西。

首先它是总结一个软件功能和性能、使用方案的总结书，是描述一个产品，到底该为客户提供什么服务，起到什么样的作用，到底可以完成什么任务，从这个角度对软件产品做一个总结,是提供软件功能和性能以及使用方案的总结。

也就是说，他应该包括的内容是向开发人员很详细的描写清楚，这个软件到底应该怎么工作，他使用方案的总结，他的功能性的总结，而不应该包括产品具体的设计的构架，到底怎么执行，怎么设计，这方面内容其实是有不的文档或者文件去总结的。

早上也提到，作为开发团队人员，当设计经理、项目经理把软件功能定完以后，真正产品怎么开发，是应该由设计团队人员去做。

在微软有的比较大型的团队，我们有所谓的设计师，具体开发也开发团队的领队和开发人员，他们每个人根据功能的描写总结出来具体设计的执行方案，这个其实是不应该写在设计规范书里的，所以要理解清楚，设计规范书是描写产品对客户怎么用，而不是描写这个产品具体开发逻辑怎么执行，这个是和开发有关系的。

作为设计规范书是项目经理的工作，就是要把这个产品的功能描写清楚。

它该包含的内容和不该包含的内容不要搞混乱。

影响设计规范书的因素很多，首先最重要的是功能需求，客户对使用软件有它一定的要求，这个软件应该提供什么样的服务，该完成什么样的任务，这方面就叫做功能需求。

其实是有不同的好几个因素来影响整个功能需求的，对市场竞争的分析，我们竞争的对手他的产品有什么样的功能，从而得出我们产品应该也有什么样的功能，甚至功能比他更好，这是对功能需求的起影响因素的。

还有客户之间的回馈，他说我这个产品为我的行业做工作，这个和明显是客户具体的要求。

还有就是用户解决问题的要求，比如说他说我不在乎你这个产品怎么开发，不管你以前的产品，或者你开发的产品以前有什么功能，由于要解决新的问题，必须加进这样的功能。

还有用户所谓的使用方案，他真正解决问题，使用的方案流程是怎样的，由于他商业之间运行有直接关系，如果客户商业流程决定是这样的运作的顺序，你软件设备也应该要配合客户使用方案设计。

所有这些是最关键的因素影响功能需求，功能需求也是第一个最要紧的影响到设计规范书该描述清楚的，解决的什么样的问题。

除此之外是性能需求，光描写说我这个软件按一个键可以写一个数字还不够，如果是客户要求我按一个数字，在0.3秒之内写出来，或者是我按键以后印出五百万字来，他显示数据的速度怎么样，他的要求也是影响到设计规范书的。

他包括整个系统的要求，如果大型的软件，运行的系统，什么样的硬件，什么样的内存存什么样的网络，所有这些对性能的需求都起到影响。

他的运行的环境，到底是有没有兼容不同的操作平台，不同的操作平台之间不同。

对软件的功能也是起到影响的，还有安装部署，特别是大型的系统，因为我在搞工业控制很多年也知道，安装部署的要求，软件在实验室完成跑到真正大型的工厂里，完全是另外一回事。

环境的安装部署要求，在很脏的环境里，边上有各种干扰的因素，在这样的运行这样的软件，性能是不是有保证，保证不会死机，数据不会出现什么错误，或者出现错误有什么样的反应，这些都会影响到开发软件的要求。

还有是质量要求，有一部分是能解决的，还有一部分是不能解决的，中间的质量要求是碰到什么情况能够对付，碰到什么情况怎么应付，这些不同的用户都会有详细的要求，这些都是规范设计书应该总结的内容。

除了这些以外，还有非功能的要求，但是在设计的时候非得考虑到，包括地区、行业，甚至国家在某一个行业里的标准。

象在欧美市场上，每个行业都有自己的标准。

如果你是设计软件，为某一个行业设计，里面软件设计接口标准，可能使用数据规范，对于很多标准，如果你是对那些不熟悉，或者是不了解，甚至是用错的话，开发出来不符合那些客户要求就要改。

这些和真正产品的功能毫无关系，可是要为了保证在以后产品开发出去避免这样的错误，由于这样的错误重新返归，就要把这些要求了解清楚。

技术还有技术开发的局限，你想这样开发，你想提供这样的功能，但是首先得了解，目前客户所用的设备的硬件，或者他的运作的操作系统环境，有没有某些局限，你想开发性能的时候他没有办法达到，把这些事情弄很清楚的话，避免和客户讲不清楚的争论。

在描写功能的时候，这个功能有什么样的能力，没有什么样的能力，描写的很清楚。

还有对时间的依赖，对外在因素的依赖，这里面是需要时间的。

项目管理上所谓三角形的定理，有这么多时间，你有这么多资源只能开发出这么多功能。

如果把你的时间砍掉一半，其他因素不变的情况下，绝对不能按时间、质量研发出来。

这些都会影响到你设计规范书的撰写，你要写得很清楚，软件开发哪些能力我是可以完成的，哪些是不可以完成的。

还有可用性的需求，软件为了要赢得客户的心，赢得市场的心，很要紧的一点，不光是把软件开发出来大家可以用，客户用了不会觉得很混乱，还是很闹心，还是用起来很顺手，这里面的可用性，这些东西也是很重要。

什么因素决定可用性，用户的特点，不同的用户，不同的使用者，也会决定软件开发应该按照适合他们的要求。

开发出来的软件是给一些专门的设计人员用的，那些人受过高等教育，都是很熟悉的，和你开发出来给爷爷奶奶用，这里边不同的客户，都有专门的特性，所以在微软把不同的使用者，分成不同类型的组群，这里的要求怎么回事。

所有这些都是影响到可用性需求。

整个设计规范书在描写完善的软件过程，这些都要考虑到。

你不考虑的，不在乎的就去写软件，等你开发出来这些搞错的话，一定影响软件最后的质量。

软件规范书的读者，规范书是干什么的，为谁而写？作为开发管理人员项目经理到底做什么工作。

第一个是给开发团队用的，构架设计、开发执行的计划。

开发团队是第一位读者，需要拿这个来盖房子。

除此以外，测试团队，在定测试计划的时候，也是根据你对功能的描述。

所以如果一个软件里调出一千多个功能，就要定一千多，甚至三千、五千相对应的测试方案。

测试团队也是设计规范书的读者。

文档团队，要让客户能够很方便的了解、熟悉你这个软件的产品，很要紧一点你要有所谓的专门使用手册，如果软件是推向市场的，给爷爷奶奶用，从来没有用过这个软件的，看一个说明书怎么样可以帮助这些没有技术水平的人在很短的时间内用这些软件。

文档协作很重要，编辑的人也不懂计算机，只能描述这个产品，他们所需要的内容也是从这里来的。

可用性团队，他们要用产品找一些客户到内部进行调查，他们怎么设计测试，可用性的案例？他们也是要根据设计规范书的内容决定。

最后就是市场营销团队，当你有一个完整的设计规范书，营销产品的时候，当产品完了以后向市场进行推销的时候，营销人员会比较清楚的了解，这个产品到底有什么样的功能，可以完成什么样的任务，然后向广大市场描写这个产品有什么好处。

所以你看到设计规范书一般是为这么多团队，这么多人服务的。

还有给客户领导，在你产品还没有开发之前，在你和客户交流的时候，我们在某一个产品，为他们专门设计的软件，在开发之前，并不是签一个协议，告诉我写一个东西，然后就开发了。

开发之前如果有一个很完整的规范书，让客户从头到尾把我整个开发的计划了解清楚，开发的内容，我要提供的功能，能够提供的，不能提供的写的很清楚的话，他看了以后就会知道符不符合他的要求。

帮助客户了解整个开发的计划，他给你进行回馈，帮你做调整，领导可以根据这个对整个项目进行跟踪。

如果你都写清楚了，作为企业的领导，可以从高层次领导整个开发的计划，跟你原来的计划，定的时间表可以知道什么时候可以完成。

所以起一个很好的交流作用，帮助团队和领导之间保持一致。

在写规范书通常要经过什么样的步骤，做什么事情可以达到最后的结果？在你正在写之前，首先需要确定你要解决的问题，最要紧的是从市场需求来了解，我这个软件到底该做什么，这个软件是为什么样人服务的，做什么样的事情。

定出你所要的功能之前，首先先要了解使用方案，三步法，知道客户的使用方案，从那个得出你的需求到底是怎样的。

然后根据体的需求总结，定出你要设计的功能到底是哪些。

由这些需求、总结定出这些功能，最后根据三步法设计功能。

这样你设计的功能都是为了解决客户具体的使用方案，而不是设计的功能是毫无作用的。

你不按照这样的方法做，常常让开发工程师自己随意开发出一些功能，功能开发出来看起来很不错，我们叫做很酷，可是不在客户的使用方案里起到具体的作用，可以在某一个软件的菜单上按一下可以做一些什么事情，可是客户根本用不着这个，这种开发出来是一个很大的浪费。