版权声明
- 本文原创作者：谷哥的小弟
- 作者博客地址：http://blog.csdn.net/lfdfhl
- 本文参考资料：电子工业出版社《软件文档写作教程》 马平，黄冬梅编著
开发文档分类概述
软件项目实施过程中依据功能和作用的不同可以把文档分为以下几类：
- 可行性研究报告
- 项目建议书
- 招投标文件
- 需求分析书
- 概要设计书
- 详细设计书
- 项目验收总结报告
可行性研究报告
可行性研究报告的编写目的是说明该软件开发项目的实现在技术、经济和社会条件 方面的可行性，评述为了合理地达到开发目标而可能选择的各种方案，说明并论证所选定的方案。可行性研究报告的内容包括可行性研究的前提，对现有系统的分析，所建议的系统，可选择的其他系统方案，投资及效益分析，社会因素方面的可行性和结论。
项目建议书
项目建议书为软件项目实施方案制订出具体计划，包括市场分析，项目的概要介绍， 项目的赢利模式，项目的整体框架，各部分工作的负责人员、开发进度、开发经费的开发 预算、所需的硬件及软件资源等。项目建议书一般由项目经理根据客户的开发计划来编写， 作为整个项目的整体规划，未来的开发工作都基于这个计划来执行。
进行可行性分析是一个自我否定的过程，而写项目建议书是一个向别人阐述自己观 点的过程。而且项目建议书一般情况下是要去说服你的上司或者投资人来做这个项目，所以一定要非常完善，把所有可能的利弊都分析到。
招投标文件
国内的软件项目招标文件的写作规则并不存在行业标准。一般的招标文件内容包括 项目招标简介，企业信息化项目需求，咨询与实施需求，售后服务要求和信息系统要求等。 投标文件内容包括投标人商务文件构成，投标文件要求和项目建议书的写作要求等。
需求分析书
需求分析书由软件开发人员与客户共同编写，客户用自然语言描述对系统的功能和 性能方面的预期效果，开发人员将客户需求转化为文字记录下来，尽可能充分地诱导出 客户的需求，使未来开发出来的系统能够真正满足客户的需要，与客户预期的系统相差 无几。需求分析书是面向客户的软件文档，包括产品概述、主要概念、操作流程、功能 列表和解说、注意事项、系统环境等。对系统进行详细的功能分析（包括客户提出的要 求和根据开发经验建议的功能），描述本产品是什么，有什么特殊的概念，包括哪些功 能分类，需要具备什么功能，该功能的操作如何，实现的时候必须注意什么细节，系统运行环境的要求等。
构建一个软件系统，如同建造一所房屋。需求分析书要刻画房屋主人的意图，他想 建造一个什么样的屋子，是建一个独门独院的小别墅还是建一个有很多房间的公寓。屋子有几个客厅，几个卧室和几个卫生间，这些房间如何布局等，这些问题都是在需求分析书 中必须回答的问题。另一方面，由于房屋主人一般都是建筑方面的外行，就需要房屋设计人员从建筑的角度帮助他们尽可能多的发掘自己的要求。
概要设计书
概要设计书以需求分析书为基础，包括功能实现、模块组成、功能流程图、函数接 口、数据字典、软件开发需要考虑的各种问题等。这些问题都是从概要设计书编写开始， 就正式进入计算机领域的软件文档了。由于需求分析书随时都有变更的可能性，所以概要 设计书制定出来之后也不是一成不变的，它要随着需求分析书的变更而变化，从需求设计 书出发，抽象出系统的功能模块，数据库要求，体系结构等大方向的问题。
在建造房屋的这一过程中，概要设计书就相当于房屋主体结构图，此时需要决定的 是房屋的格局，用料，管道布局等关键问题，这些问题一旦决定下来，房屋的轮廓就已经 出来了。软件的概要设计书也是如此，概要设计书完成之后，软件系统的骨架即可决定， 未来的工作就可以在此基础上展开。
详细设计书
概要设计书从高层着手对系统进行描述，但是，拿着这样一份概要设计书，是无法 进行实际编码工作的。详细设计书以概要设计书为基础，对已拆分出来的子系统和功能模 块逐个进行设计，这里的设计要详细到每个模块实现的具体步骤，按钮按下完成什么操作， 点击某个连接迁移到什么画面，还要绘制出页面原形，提供与数据库的交互方法，数据的 表现形式，这些都是要在详细设计书中具体描述的。当然，由于项目复杂度和规模不同， 详细设计书的复杂度也会不同，功能简单的系统如果配上复杂的软件文档，只会让软件开 发变得更复杂，违背了软件文档建立的目的。相反，如果软件系统复杂度高，参与人员众 多，就必须配备详细的软件文档，给不同的角色的人员提供尽可能详细而全面的信息。
回到建造房屋这个例子来说，房屋的骨架搭建起来之后，就该丰富它的身体了，装 修设计如同软件的详细设计，决定屋子的整体风格，屋子四面墙如何安排，是贴墙纸呢还 是刷油漆，窗户以及门上的玻璃采用什么花样，灯光如何布置等。装修设计完成之后，未来屋子的全貌就八九不离十了。同样，成功的详细设计书一旦做成，未来软件系统的实现 方法也就确定了，编码人员按照详细设计书就可以开始具体的编码工作了。并且由于很多实现细节的问题都在详细设计中考虑分析过，一些技术难题也已经在前期进行攻关试验并 最终得出结论，尽量让问题早发现早解决，不至于延迟到项目后期才发现。通过充分的详细设计过程，可以使编码过程变得简单易行，达到事半功倍的效果。
项目验收总结报告
项目验收总结报告的内容包括对所完成系统的测试，验收和总结。测试的目的是为了将软件产品交付给用户之前尽可能多的发现问题并及时修正问题，不至于等到用户在使用过程中才发现问题。测试计划就是规划整个测试的实施过程，计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。由于测试会细分为单元测试、集成测试、系统测试等几个环节，测试计划书也应该按照阶段制定。
其它文档
在软件系统的实际开发过程中，不仅只有以上所述的7种软件文档，还有维护手册，用户手册等。
软件系统开发完毕交付给客户之后，软件的开发周期就结束了。但是从软件的生命周期来看，开发周期只是生命周期的一部分，更多的时间在于软件的服役期。软件与有形产品不同，不会随着时间的推移发生物质损耗与折旧，但是，软件在运行过程中会发现这样那样的问题，有可能和客户预想的功能稍有出入，也有可能没有正确实现客户的要求，这就是通常所说的缺陷。几乎没有人敢断言自己开发出来的软件投入使用之后一点问题也没有，区别只是缺陷的多少问题。所以，软件在投入使用之后，与有形产品一样存在着维护的问题。
维护工作有可能是由软件系统的开发方来实施，也有可能是客户方自己有相关的技术人员。无论是由开发方还是客户的技术人员来进行维护，都需要借助维护手册来实施，因为即使是对于开发方，由于他们在完成一个软件的开发之后，很快就会进入下一个新系统的开发中，并且随着时间的推移，对原来系统的记忆开始模糊，逐渐就不能清楚地回忆起当时开发的细节了。对于客户的维护人员就更难知道如何去维护这个软件系统了。所以，维护手册起到了技术支持的作用，通过查看维护手册能够诊断软件的问题，采取相应的措施给予解决。
为了提供技术支持，维护手册应当包括产品简介、系统须知、初始环境设置、系统配置、数据管理和备份、技术问题解答和联系方式等。由于维护手册面对的是有一定计算机相关知识的人，所以它的内容应该比较专业，力求用严谨的方式刻画问题的解决方法。
用户手册的读者是软件的最终用户，用户需要从手册中获得关于软件系统的各种各样的信息，所以，用户手册必须详细地描述软件的功能、性能和用户界面，使用户了解如何使用该软件。用户手册的读者通常都是没有计算机相关知识的人员，这就决定了用户手册书写的语言必须是非专业性质的，与之前提到的概要设计书详细设计书完全不同，它不必关心这个软件系统是如何实现，采用了什么优秀的体系结构、先进的开发技术等，它只须关心这个软件能为最终用户提供什么功能，如何操作这个软件才能获得这个功能以及在使用软件的过程中应该注意的地方等。
对于建造完毕的房子，不会有人特意撰写一份使用说明书，因为房子对每个人来说都不陌生，其功能和使用方法不言而喻。由于房子是一个有形的实体，房子与房子之间的区别，只需要亲身去参观一次便可以一目了然。软件系统则不一样，随着应用领域的不同，各软件之间的差异也相当大，正如俗话说的“隔行如隔山”。由于软件具有这样的特点，使得用户手册在软件产品中具有不可忽视的作用，用户手册成为推广软件的有力武器。
软件文档的格式也不是固定不变的，各公司可能有自己的一套标准，并且还可能和用户讨论形成新的软件文档结构。虽然如此，但是这些软件文档的基本内容是一致的。