详细设计文档怎么写，如何写详细设计文档

大家好，欢迎点击我们的文章。今天，我想和大家深入交流一下详细设计文档怎么写的相关知识，也会谈及如何写详细设计文档的相关内容。如果你对这些还不太明白，那么这篇文章就是为你准备的。我希望能够帮你解决问题，那就让我们现在就开始吧！

如何写详细设计文档

在大多数软件项目中，要末不作详细设计，要么开发完成后再补详细设计文档，质量也不容乐观，文档与系统往往不能同步，使详细设计文档完全流于形式，对工作没有起到实际的帮助。

·

详细设计是相对概要设计而言的，是瀑布开发流程的一个重要环节，在概要设计的高层设计的基础上，从逻辑上实现了每一模块的功能，是编码阶段的主要参考资料，是从高层到低层、逐步精化思想的具体实现。

详细设计文档的内容包括各个模块的算法设计，

接口设计，

数据结构设计，交互设计等。必须写清楚各个模块/接口/公共对象的定义，列明各个模块程序的

各种执行条件与期望的运行效果，还要正确处理各种可能的异常。

·

在开发过程中，由需求及设计不正确、不完整所导致的问题是项目进度拖延、失败的一个主要因素，而软件系统的一个重要特性就是需求和设计的不断构建和改进，在写详细设计文档过程中，

详细设计实际上是对系统的一次逻辑构建，可以有效验证需求的完整性及正确性。

如果不写详细设计文档，一般就从概设直接进入编码阶段，这时开发人员所能参考的资料就是需求规格说明书及页面原型、数据库设计等，不能直接进行开发，需要进行信息的沟通，把页面原型不能体现的设计讲清楚，这样既容易遗忘，也容易发生问题，详细设计文档可以作为需求人员、总体设计人员与开发人员的沟通工具，把静态页面无法体现的设计体现出来，包含整体设计对模块设计的规范，体现对设计上的一些决策，例如选用的算法，对一些关键问题的设计考虑等等，使开发人员能快速进入开发，提高沟通效率，减少沟通问题。

对于系统功能的调整，后期的维护，详设文档提供了模块设计上的考虑、决策，包括模块与整体设计的关系、模块所引用的数据库设计、重要操作的处理流程、重要的业务规则实现设计等等信息，提供了对模块设计的概述性信息，阐明了模块设计上的决策，配合代码注释，可以相对轻松读懂原有设计。

·存在的问题要由专门的人写，是比较麻烦的，也是很需要时间的，会对进度造成压力，也容易形成工作瓶颈，使设计人员负担过重，而开发人员无事可作。对于现在一般的以数据库为中心的管理系统而言，这个工作始终是要作的，区别只不过是不是形成专门文档，形成文档可能会多花一两周时间，但相对于规避的风险和问题来说，也是值得的，另外由于现在高级语言的流行，所以更详细的设计应该直接体现在代码的设计上，而文档则只体现设计上的一些决策，协调整体设计与模块设计的关系，把页面原型所不能体现的设计情况文档化，所以所花费的时间是有限的。

设计内容容易过细，但设计阶段是不能考虑特别清楚地，时间也不允许。

对于这个问题，一个对策是上边所提到的，文档只体现设计上的决策，页面原型所不能反映的信息，详细设计只体现总体设计对模块设计的一些考虑，例如对功能的数据库设计等等，而具体的实现实现，则到代码中再去实现，相关的设计也仅体现在代码中。

需求、设计需要不断的被更新、构建，则设计文档需要不断的重新调整，文档的维护需要跟上，否则文档和系统的同步就很难得到保障了，且造成多余的工作量。文档的内容易流于形势，质量糟糕，不能成为开发人员的参考手册，一是要建立起相关制度，如有修改，先改文档，后作开发，从工作流程上切实保障文档与系统的同步，二是要规范文档质量，对文档该写什么，不该写什么，标准是什么，粒度是什么，语法应该如何组织，有明确的标准和考虑，同时，建立审计文档评审、审核制度，充分保障系统的使用。·

首先是文档的内容，根据项目和团队的不同，详细设计文档的内容也有所不同，一般说来，粒度不宜过细，不能代替开发人员的设计和思考，但要把有关设计的决策考虑进去，包括与其他模块、整体设计的关系、操作的处理流程，对业务规则的设计考虑等，有一个标准为，凡是页面原型、需求规格说明书所不能反映的设计决策，而开发人员又需要了解的，都要写入文档。

其次是文档所面向的读者，主要为模块开发人员、后期维护人员，模块开发人员通过详细设计文档和页面原型来了解所开发的功能，后期维护人员通过实际系统、模块代码、详细设计文档来了解一个功能。

再有就是谁来写文档，因为文档主要考虑的是设计上的决策，所以写文档的人应该为负责、参加设计的技术经理、资深程序员，根据团队情况和项目规模、复杂度的不同，也有所不同。

还需要保证文档的可读性、准确性、一致性，要建立严格的文档模板及标准，保证文档的可读性及准确性，同时建立审核及设计评审制度，来保障设计及文档的质量，另外在工作流程中要强调，要先设计、先写文档，再进行开发。

详细设计说明书详细设计说明书编写目的

1、软件详细设计说明书2、详细设计说明书到底怎么写？3、详细设计说明书的参考资料软件详细设计说明书

面向对象软件设计说明书模板

1概述

1.1系统简述

对系统要完成什么，所面向的用户以及系统运行的环境的简短描述，这部分主要来源于需求说明书的开始部分。

1.2软件设计目标

这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。

这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分，将解释设计是怎么来实现这些的。

1.3参考资料

列出本文档中所引用的参考资料。（至少要引用需求规格说明书）

1.4修订版本记录

列出本文档修改的历史纪录。必须指明修改的内容、日期以及修改人。

2术语表

对本文档中所使用的各种术语进行说明。如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。

3用例

此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。

4设计概述

4.1简述

这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）

4.2系统结构设计

这部分要求提供高层系统结构的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。

4.2.1顶层系统结构

4.2.2子系统1结构

4.2.3子系统2结构

4.3系统界面

各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。

4.4约束和假定

描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。

另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型（比如某某某数据库软件，某某某EMail软件）以及这样导致的约束（比如只允许纯文本的Email）。

实现的语言和平台也会对系统有约束，同样在此予以说明。

对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。

5对象模型

5.1系统对象模型

提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。

对象图应该包含什么呢？

在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。

所有对象之间的关联必须被确定并且必须指明联系的基数（一对一、一对多还是多对多，0..1，*，1..*）。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。

可能经过多次反复之后才能得到系统的正确的对象模型。

6对象描述

在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。

为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。

对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。

对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。

6.1子系统1中的对象

6.1.1对象：对象1

用途：

约束：

持久性：

6.1.1.1属性描述：

1.属性：属性1

类型：

描述：

约束：

2.属性：属性2

6.1.1.2方法描述：

1.方法：方法1

返回类型：

参数：

返回值：

Pre-Condition：

Post-Condition：

读取/修改的属性：

调用的方法：

处理逻辑：

测试例：用什么参数调用该方法，期望的输出是什么

7动态模型

这部分的作用是描述系统如何响应各种事件。例如，可以建立系统的行为模型。一般使用顺序图和状态图。

确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。

7.1场景（Scenarios）

对每个场景做一则条目，包括以下内容：

场景名：给它一个可以望文生义的名字

场景描述：简要叙述场景是干什么的以及发生的动作的顺序。

顺序图：描述各种事件及事件发生的相对时间顺序。

7.1.1场景：场景1

描述：

动作1

动作2

7.2状态图

这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。

7.2.1状态图1：

8非功能性需求

在这个部分，必须说明如何处理需求文档中指定的非功能性需求。尽可能客观地评估系统应付每一个非功能性的需求的能力程度。如果某些非功能性需求没有完全在设计的系统中实现，请务必在此说明。另外，你也需要对系统将来的进化作一个估计并描述本设计如何使系统能够适应这些可预见的变化。

9辅助文档

提供能帮助理解设计的相应文档。

10词汇索引

文章录入

详细设计说明书到底怎么写？

详细设计，这是考验技术专家设计思维的重要关卡，详细设计说明书应当把具体的模块以最’干净’的方式(黑箱结构）提供给编码者，使得系统整体模块化达到最大；一份好的详细设计说明书，可以使编码的复杂性减低到最低，实际上，严格的讲详细设计说明书应当把每个函数的每个参数的定义都精精细细的提供出来，从需求分析到概要设计到完成详细设计说明书，一个软件项目就应当说完成了一半了。换言之，一个大型软

件系统在完成了一半的时候，其实还没有开始一行代码工作。

那些把作软件的程序员简单理解为写代码的，就从根子上犯了错误了。

详细设计说明书的参考资料

列出有关详细设计说明书的参考资料，如：

a．本项目的经核准的计划任务书或合同、上级机关的批文详细设计说明书；

b．属于本项目的其他已发表的文件；

c.本文件中各处引用到的文件资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。

F.2程序系统的结构

用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间的层次结构关系。

F.3程序1（标识符）设计说明

从本章开始，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。

F.3.1程序描述

给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点（如是常驻内存还是非常驻？是否子程序？是可重入的还是不可重入的？有无覆盖要求？是顺序处理还是并发处理卜..等）。

F.3.2功能

说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式。

F.3.3性能

说明对该程序的全部性能要求，包括对精度、灵活性和时间特性的要求。

F.3.4输入项

给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。数量和频度、输入媒体、输入数据的来源和安全保密条件等等。

F. 3. 5输出项

给出对每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式、数量和频度，输出媒体、对输出图形及符号的说明、安全保密条件等等。

F．3．6算法

详细说明本程序所选用的算法，具体的计算公式和计算步骤。

F．3．7流程逻辑

用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程。

F．3.8接口

用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式，说明与本程序相直接关联的数据结构（数据库、数据文卷）。

F．3.9存储分配

根据需要，说明本程序的存储分配。

F．3．10注释设计

做软件项目设计文档怎么写啊

按照以下格式填就好了，不过是我自己写的，有不好的地方大家互相学习修改一下~

详细设计文档规范

1.0概述

这部分提供对整个设计文档的概述。描述了所有数据，结构，接口和软件构件级别的设计。

1.1目标和对象

描述软件对象的所有目标。

1.2陈述范围

软件描述。主要输入，过程功能，输出的描述，不考虑详细细节。

1.3软件内容

软件被置于商业或者产品线中，讨论相关的战略问题。目的是让读者能够对“宏图”有所了解。

1.4主要系统参数

任何商务软件或者产品线都包含软件规定、设计、实现和测试的说明和规范。

2.0数据设计

描述所有数据结构包括内部变量，全局变量和临时数据结构。

2.1内部软件数据结构

描述软件内部的构件之间的数据传输的结构。

2.2全局数据结构

描述主要部分的数据结构。

2.3临时数据结构

为临时应用而生成的文件的描述。

2.4数据库描述

作为应用程序的一部分，描述数据库结构。

3.0结构化和构件级别设计

描述程序结构。

3.1程序结构

详细描述应用程序所选定的程序结构。

3.1.1结构图

图形化描述结构。

3.1.2选择性

讨论其它可供考虑的结构。选定3.1.1中结构类型的原因。

3.2构件描述

详细描述结构中的每个软件构件。

3.2.1构件过程叙述(PSPEC)

描述构件的过程。

3.2.2构件接口描述

详细描述构件的输入和输出。

3.2.3构件执行细节

每个构件的详细演算描述。

3.2.3.1接口描述

3.2.3.2演算模型(e.g., PDL)

3.2.3.3规范/限制

]3.2.3.4本地数据结构

3.2.3.5在3.2.3.6设计中包含的执行结果

3.3软件接口描述

软件对外界的接口描述

3.3.1机器对外接口

与其他机器或者设备的接口描述。

3.3.2系统对外接口

对其它系统、产品和网络的接口描述。

3.3.3与人的接口

概述软件与任何人的界面。

4.0用户界面设计

描述软件的用户界面设计。

4.1描述用户界面

详细描述用户界面，包括屏幕显示图标、图片或者类型。

4.1.1屏幕图片

从用户角度描述界面。

4.1.2对象和操作

所有屏幕对象和操作的定义。

4.2界面设计规范

用户界面的设计和实现的规范和标准。

4.3可见构件

实现的GUI可见构件说明。

4.4 UIDS描述

用户界面开发系统描述。

5.0约束、限制和系统参数

会影响软件的规格说明、设计和实现的特殊事件。

6.0测试标准

测试策略和预备测试用例描述。

6.1测试的类别

规定实施测试的类别，包括尽量详细的描述。这里是针对黑盒测试现象的描述。

6.2期待软件反馈

测试期待的结果描述。

6.3执行界线

特殊执行需要的说明。

6.4重要构件确认

决定性构件或者需要特殊注意的构件的测试确认。

7.0附录

设计说明的补充信息。

7.1系统可跟踪矩阵

一个定期回归系统规格跟踪软件需求的矩阵。

7.2产品战略

如果规格说明书是为一个产品设计的，描述相关的产品战略。

7.3使用分析算法

描述所有分析活动所使用到的分析算法。

7.4补充信息(如果有需要特别说明的)