软件开发过程中需要编写的文档

众所周知，做软件的目的就是要满足客户的需求，这个需求包括功能、观、操作、时间及性能等各方面。那么，在软件开发过程中那部分最重要呢，程序员说“毋庸置疑，我编写的程序实现了客户提出的功能以及业务流程，肯定我是最重要的”，美工说“你开发的功能如果没有我的页面美化，是无法呈现给客户的，要知道，很多客户并不很了解内部复杂的功能，首先映入眼帘的就是界面的效果，就像人一样，如果你不是美女，那么他看了你一眼之后，就没有想和你再继续沟通和发展的积极性了”，测试听了不高兴了，说“漏洞百出的产品，哪怕你外观再漂亮，实现的功能再多，也是不成熟的产品，客户是不会使用的。”众说纷纭，各执一词。

以上所说都很有道理，每个角色都是软件成功必不可少的，每个人都好比是一块积木，只有组合起来才能搭成既美观又稳固的造型。

另一方面，他们却又都不是最重要的。举个例子，现在我家在进行装修，木工、瓦工、油漆工都是南方的工人，有很好的手艺，干活也很细致，可是他们在施工的时候都要参考两份文件，一是房屋结构图，二是装修效果图。没有此文件，他们就无从下手，就是拥有再好的手艺，做出来的再漂亮，到时候也会与房屋的实际效果存在偏差。

孙悟空三大白骨精，相信谁都耳熟能详。里面有这样一个场景，孙悟空去化斋前，划了一个圈，将唐僧他们包在里面，只要他们在圈里面，就不会有事，如果出了圈就很危险。这个圈，就是一个范围、一个标准。在这个圈里，你随便折腾，怎么折腾都行，但千万不要越界，否则后果不堪设想。

而在软件开发中文档就是那个圈，它将项目开发所进行的一切活动都进行详细的定义，只要遵照这个文档去开发，那么最终的结果一定是八九不离十。

文档贯穿软件工程的始终，从前期的项目准备，中期的开发到后期的维护、培训，无不以文档作为工作的依据。那么在软件项目中，都包括哪些文档呢，它们的作用又是什么呢，下面我将我的经验分享给大家。

<small>《可行性研究报告》：这是客户在进行项目调研阶段所编写的，具有两重意义，其一，指明项目的必要性和紧迫性，并从业务角度阐述大概的功能需求，注意，只是大概，可能与最后的结果有很大出入；其二，最重要的一点就是为了要钱，向财政部要钱，将最终实现的功能写得天花乱坠，包括决策支持、全文检索、商业智能、远程报表等，但最后开发的可能仅仅是融合简单业务流程的信息输入和输出而已，但这已无关紧要，最重要的是我要到了钱。但是严格来说，这不是项目组所需的文档，于软件开发也意义不大。
《建设方案》：或者是《实施方案》，当客户从财政部申请到资金后，就要着手进行详细的调研和分析了，这里有两种情况，其一，客户自己从各个产品厂家进行相关的调研，进行汇总后，编写方案，这样，聪明、细心的软件公司就会从方案的技术环节，挖掘出客户所选择的产品，最后和这个产品公司合作来中标；其二，让和其关系很好的一家或两家软件公司（不会超过三家）编写，客户进行审核，客户最后选择了谁的方案那么最后这个项目就是这家公司的，这样很多情况并不是公开招标。
《招标书》：将《建设方案》或《实施方案》进行摘取，并附带上技术问题以及招标时的细节、注意事项，构成《招标书》，这个文件也是由客户写得，软件公司在投标前需要购买《招标书》。
《投标书》：与《招标书》所呼应，对技术问题进行相应的技术应答，包括技术标和商务标两部分。</small>
上面几份文档，是项目前期准备时需要的，是侧重于售前方面的；而下面的文档是软件开发过程中必不可少的，我们按开发工作的时间顺序一一介绍。

<small>《需求分析说明书》：对于软件开发来说，《需求分析说明书》就好像是盖楼时所用的图纸，是最重要的文档，由项目经理对客户相关部门进行业务调研后编写，语言侧重于从业务的角度描述功能需求。内容涉及三大部分，其一，编写目的、背景、目标任务等公共性语言；其二，功能性需求，将业务梳理成几大功能模块，一级功能下细分二级功能，依次类推，将最终细化的功能按描述、输入、处理和输出进行详细描述；其三，非功能性需求，包括性能、处理能力、进度、界面设计和运行环境的规定。

《数据库设计说明书》：我是做数据库出身，因此这部分的工作也是由我这个项目经理来做，根据《需求分析说明书》在Erwin建模工具中设计好逻辑模型和物理模型，然后将其整理到此文档中，文档还包含数据库所有的表结构和相关的字段说明。

《概要设计说明书》：说实话，在我做过的项目中，没有编写过此文档，因为我觉得《需求分析说明书》和《详细设计说明书》就足矣了。甚至如果项目简单或时间紧急，《详细设计说明书》都会省略：）。

《详细设计说明书》：主要包含两部分内容，其一，体系结构的设计，也就是项目所采用的几层架构，以及层与层之间的通信机制，还有就是基础框架所采用的技术；其二，是本文档的核心部分，包括每个细分模块的详细设计说明，包括程序描述、功能、性能、输入项、输出项、算法、流程逻辑、接口、存储分配、注释设计、限制条件、测试计划和尚未解决的问题等内容。本说明书对项目所采用的技术和接口都做了详细的规定，是指导程序员开发的直接工具。但需要说明的是，很多项目由于时间原因，都忽略了此说明书的编写，包括本人目前在做的项目也是如此，因此本文档并不是必须的。但如果作为给客户的交付物，需要在项目完成后补全。

《计划进度》：这个不用多说，由项目经理编写，实现对项目进度的严格把控，是项目必须的文档，可用project编写。

《测试用例》：测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。它是将软件测试的行为活动做一个科学化的组织归纳．目的是能够将软件测试的行为转化成可管理的模式；同时测试用例也是将测试具体量化的方法之一。由此可见，《测试用例》非常重要，是对项目或产品质量的严格保证，但由于测试人员和项目组的规范性、时间进度等限制，本文档在本地区的实际项目中也很少应用，至少我认识的很多测试人员中，只有极少数的项目中会编写此文档。

《测试结果》：在项目开发阶段使用，也就是交付客户之前。文档为Excel格式，并提供关键字段的数据筛选，内容包括描述、缺陷类型（Bug、需求）、开发人员、状态、关闭时间、所属模块、提交人、解决人、备注等。其中状态包含提交、解决和确认解决，测试人员将问题提交（红色），当程序员解决后就置为解决（黄色），测试人员再次确认无误后，就修改状态为确认解决（绿色），并且添写关闭时间。

《需求变更文档》：产品交付客户之后使用。任何一个好软件，不是在第一个版本就把这些标准全部实现，而是有步骤有重点地实现，逐步成为一个好软件。因此《需求变更文档》是不必可少的，同样作个Excel表格，量化解决。包括下列几项：客户名称、需求提出人、提出日期、需求关闭时间，功能模块名，客户现在版本号，需求描述，需求分类（需求、Bug）等。每次发布新版本都把从上一版本发布之日关闭的需求列表都单独摘成一个文件，附带到这次新发布的版本之后。

此举有两个好处，其一，能够清楚的列出客户以往所提的需求，因为有一些客户提出的改动总是反反复复，一个问题一会要改成A,然后觉得不好要改成B，之后觉得还不如A好，便又要求改回去，这样给公司的进度和安排带来很大的不便，如果因为这个耽误了其他的工作，便可以有此根据和客户进行沟通，防止客户赖账；其二，可以评判技术支持和相关程序员的工作量。此文档为EXCEL格式，但最好还有一个word类型的文档，每次客户提出修改意见时，将此文档打印出来交由客户签字，作为凭证，此方法实际中并不是次次可行，一些强权客户或不敢承担责任的就不签字，那也没辙。

《测试结果》和《需求变更文档》要定期（可一周或一个月）给老板一份。这表明了你的工作量，让他看看你确实一直很辛苦地在工作，另外，也能看出你的认真负责态度。

《用户使用手册》：按标准说，应该由文案写，但在大多数的软件公司中都不设这个职位，因此要么由项目经理写要么由测试人员写，关键看是谁给客户做培训。在目前我做的这个项目中，并没有专职测试，所以这个工作还是项目经理来做。《用户使用手册》可根据实际情况写成三种版本，其一，chm类型文件，适用于C/S的项目，就像微软的产品中，都会有此帮助手册；其二，做成网页形式的帮助文件，适用于B/S项目；其三，就是做成word文档，虽然可保存至本地，但使用起来没有前二者方便。</small>

余者还有《开发任务书》、《项目总结报告》、《软件验收评审》等，并不是必须的，可根据客户需要和实际的项目来选择使用，再次并不一一赘述。

并且，以上所有文档，虽然有些是必须的，比如《需求分析说明书》、《测试结果》、《用户使用手册》等，但根据不同的行业、不同的地区以及不同的项目和团队规模，文档的具体内容都会有所不同，不必较真。只要能抓到老鼠，白猫黑猫都是好猫，况且，没必要的多余的文档会浪费时间和成本等资源。