软件设计文档

文档在开发人员，软件管理人员、维护人员、用户以及计算机之间的起桥梁的作用



 
执行流程



简要介绍

用户手册：本手册详细描述软件的功能、性能和用户界面，使用户了解如何使用该软件。
	
操作手册：本手册作为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节
	
维护修改建议：软件产品投入运行后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响估计做详细的描述，写成维护修改建议，提交审批。
	
软件需求说明书：也成为软件规格说明书，其中对所开发的软件的功能、性能、用户界面以及运行环境等作出详细的说明。它是用户与开发人员双方对软件需求去的共同理解基础上达成的协议，也是实施开发工作的基础。
	
数据要求说明书：该说明书应给出数据逻辑描述和数据采集的各项要求，为生成和维护系统数据文卷坐好准备。
	
概要设计说明书：该说明书是概要设计阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计奠定基础。
	
详细设计说明书：着重描述每一模块设怎样实现的，包括实现算法、逻辑流程等。
	
可行性研究报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施的方案，说明并论证所选定实施方案的理由。
	
项目开发计划：为软件项目实施方案制定出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件以及软件资源等。软件开发计划应提供给管理部门，并未开发阶段评审的参考。
	
测试计划：为做好组装测试和确认测试，需要如何组织测试制定实施计划。计划应包括测试的内容、进度条件、人员、测试用例和选取规则、测试结果允许的偏差范围等。
	
测试报告：测试工作完成以后，应提交测试计划执行情况的说明。对测试结果加以分析，并提出测试的结论意见。
	
开发进度月报：该月报系软件人员按月向管理部门提交项目进展情况报告。报告应包括进度计划和实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。
	
项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力。此外还需对开发工作作出评价，总结出经验和教训。

最近在写软件设计文档，常常很疑惑：设计文档应该详细到何种程度呢？
参考了过往一些项目的设计文档，有的写的比较简略，有的写的比较详细。其中有一个设计文档是事后补的，写的很详细，连模块内部用的数据结构也详细地列了出来。我也很疑惑，难道真的要这样写设计文档吗？
女儿Susan问我小时候玩什么传统的游戏？我想了想说：抓石子。 抓石子是女孩喜欢玩的游戏，但我小时候也喜欢玩。女儿问：那应该如何描述呢？老师让写下来。
“呃，将石子撒在地上，从中捡起一个，抛向空中，与此同时，抓地上的石子，再…… 当然，石子大小要合适，直径大约在1.5~2cm，要圆一些，你喜欢方的也可以，也不能撒太开，否则……也不能抛太高和太低…...”
抓石子本身不难，但想要描述清楚，也不是一句话两句话说清楚的。我意识到，软件设计中有些东西本身不难，但要想把它描述好，既费力，也枯燥。这也是大家不愿写文档的原因之一。
听说一个其他的项目的设计文档也很详细，连窗口上菜单的也详细地列出来了，还为此讨论了多次，项目组成员苦不堪言。
最近读了一本关于软件架构的书：《恰如其分的软件架构》，其中提出了“风险驱动的设计方法”。
在架构设计方面，也存在这样的争论：做多少架构设计才是合适的？有的主张不做预先设计，开发者一上来就开始写代码，架构在构建时浮现。有的主张将10%的时间用于架构与设计，90%用于构建和测试。而有的主张开发者应采用一整套设计及文档技术，以产生完整的书面设计文档。
而风险驱动的设计方法遵循的指导原则是：为架构付出的努力应与失败的风险相称。为此要问：我的风险是什么？用于降低这些风险的最佳技术是什么？通过选择技术和架构设计，风险是否已经缓解？可以开始编码了吗？
我想，就我遇到的设计文档要详细到何种程度的问题，也可以采用这一方法。即，对于要开发的软件，哪些应详细论述，哪些可以一带而过。详细论述的部分，应是软件的难点，即如果这一点不说清楚，软件就没法实现，或实现起来心里没有底。
比如，对于多传感器数据融合软件，如果你不把数据融合方法说清楚，这个软件就难以开发出来。但如果之前已经开发了一版多传感器数据融合软件，现在要改进。那么，重点就不是数据融合方法，而是要改进的那部分。
又如，在现有软件中增加日志模块，虽然是新增的模块，但日志模块本身没有什么风险，因此也不算重难点，也没有必要详细描述。
又如，有一个模拟器软件，软件本身并没有多大的难度和风险，但此软件的开发者是个新手，所以开发者本身成为一个风险。这时，要做的可能就不是详细地设计软件，而是麻溜的赶紧写出一个Hello World来增强信心。
所以，根据软件系统的风险，适当地进行设计，做到Just Enough，才是合适的。

国家标准软件设计文档模板（国标软件设计文档）
 

软件设计文档主要包括：业务需求规格说明书、软件需求规格说明书、详细设计规格说明书三部分，三个文档结构类似，内容相互关联解释，业需详细的介绍业务流程，软需采用信息化方式描述业务需求所需的功能信息，详细设计对软需的功能进行详细介绍说明。

一、业务需求规格说明书文档结构

1、概述：主要涉及业务背景和总体目标；

2、主要依据：相关国家政策和制度规范；

3、现状分析：当前业务现状分析和所建设的信息系统整体介绍

4、业务描述：4.1：业务目标；4.2：组织单元（岗位职能）；4.3：业务流程（流程图及流程说明）；4.4：业务活动（相当于系统功能及功能页面信息介绍）；

5、共享融合需求分析（系统之间的集成）；

6、附录（业务信息表即字段信息）。

二、软件需求规格说明书：

1、概述：编写目的、术语及参考资料；

2、标准和规范：引用的相关标准和规范；

3、相关假设、限制、依赖条件；

4、功能规格：4.1：岗位角色（功能权限即角色及用户功能）；4.2：界面设计（用例中详细介绍）；4.3：功能视图（功能模块整体视图）；4.4：功能清单（业务所需功能即增删查改等）；4.5：用例：系统功能（增删查改）详细说明；

5、非功能规格：系统性能、可靠性、可用性、扩展性、安全性等；

6、附录：业务信息清单（功能模块涉及的对象属性信息）。

三、详细设计：

1、角色权限：角色定义及权限设计

2、总体设计：设计说明及功能结构

3、功能设计：每个模块功能的详细设计说明；

4、数据库设计：数据库实体关系及实体表信息。