项目的详细设计文档怎么写

1.软件开发中详细设计文档怎么写

原发布者：阳阳1A

QR-RD-022(Ver1.2)XXX系统详细设计说明书（内部资料请勿外传）XX公司版权所有不得复制文档变更记录1.引言1.1编写目的和范围说明写这份详细设计说明书的目的。本详细设计说明书编写的目的是说明程序模块的设计考虑，包括程序描述、输入/输出、算法和流程逻辑等，为软件编程和系统维护提供基础。本说明书的预期读者为系统设计人员、软件开发人员、软件测试人员和项目评审人员。1.2术语表定义系统或产品中涉及的重要术语，为读者在阅读文档时提供必要的参考信息。1.3参考资料列出有关资料的名称、作者、文件编号或版本等。参考资料包括：a.需求说明书、架构设计说明书等；b.本项目的其他已发表的文件；c.引用文件、资料、软件开发标准等。1.4使用的文字处理和绘图工具文字处理软件：wordoffice绘图工具：Visio2.全局数据结构说明本章说明本程序系统中使用的全局数据常量、变量和数据结构。2.1常量staticStringSERVER_ADDRESS服务器地址booleanloginFlag登录状态2.2变量BlueUserInfo 用户账户结构体2.3数据结构包括数据结构名称，功能说明，具体数据结构说明（定义、注释、取值）等。3.模块设计3.1用例图3.2功能设计说明3.2.1登录模块模块1主要分为以下几个子模块：子模块1、子模块2和子模块N。3.2.1.1设计图

2.如何写详细设计文档

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

·

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

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

接口设计，

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

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

·

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

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

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

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

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

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

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

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

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

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

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

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

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

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

详细设计文档规范

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 补充信息 （如果有需要特别说明的）

4.怎么写项目开发的文档

软件开发中文档的编写是一个不可缺少的环节，常见的如《需求分析》、《概要分析》、《数据库设计》等。在“软件人”的阵营里向来存在两种观点，注重文档还是关心代码。

我这里写一个《用户信息模块的概要设计文档》，只列举主要内容了

1.功能描述：用于完成系统用户信息的新增、删除、修改、查询；

2.功能用例：一个主用例用户信息，附加新增、删除、修改、查询4个子用例，操作人员为管理员，图形就不画了，很简单的；

3.业务流程：查询有效范围用户信息——》新增用户信息——》判断当前帐号是否存在——》存在给出提示，反之保存成功提示。

4.约束限制：超级管理员可操作所有（包含删除，我这里考虑仅是逻辑删除、非物理删除）的用户信息；系统管理员可操作除系统管理员、超级管理员外的全部用户信息；单位管理员可操作本单位用户信息；用户帐号信息系统内全局唯一；

5.系统性能：要求同时支持500个并发操作；页面操作响应时间小于1s；页面大小小于1kb;

当前用户所属员工信息不存在时，可直接进行员工信息的添加，并完成用户信息的同步保存，确保事务的完整性；

6.运行环境：依赖系统整体运行环境为准（存在特殊需要注明）；

7.操作实体：用户信息、员工信息、系统日志等。

8.异常处理：如果系统框架中已经提供相关说明，这里仅需要注明符合系统架构异常处理方式即可。

9.外部接口：输入—用户ID，输出—用户信息；

10.其他说明：用户帐号必须定义为字母开头，数字与字母组合，并保证全局唯一；用户密码采用md5算法加密，系统架构已提供相关接口。

11.注意事项：用户帐号不能为空，不能存在空格，不能超过6位；超级用户信息仅在系统初始化中完成其信息写入操作，其他用户无权对其进行修改。

项目组中也不是所有人都必须参与文档的编写，通常业务需求人员、设计人员、架构师、项目经理、小组长占大多数，而且这些人中很多也不是专注于写代码的角色。

5.概要设计和详细设计怎么写 知乎

撰写的设计文档主要分为：总体概要设计文档 + 详细设计文档，后简称为“概设”+“详设”。

总设和详设都应该包含的部分：

(1) 需求：一般以产品的语言描述，这一块可以拷贝产品需求文档中的story list部分；

(2) 名词解释（可选）：非相关领域内的同学需要看到文档需要提前了解的一些概念性质的东西；

(3) 设计目标：又分为功能目标和性能目标，功能目标一般是对产品需求的技术描述，性能目标是根据产品给出的数据对性能进行的评估。一般来说，新服务必须要有性能目标一项，性能目标可能会影响设计方案。

除了都应该包含的部分，总体概要设计一般还包含：

(1) 系统架构：一般来说会有个简单的架构图，并配以文字对架构进行简要说明；

(2) 模块简介：架构图中如果有很多模块，需要对各个模块的功能进行简要介绍；

(3) 设计与折衷：设计与折衷是总体概要设计中最重要的部分；

(4) 潜在风险（可选）；

输出总体概要设计的时候，很多方案还是不确定的，需要在设计评审会议上确认。

总体概要设计重点在“方案折衷”，总体概要设计评审完毕之后，此时应该是所有方案都确认了，需要输出各模块的详细设计，详细设计重点在“详细”：

(1)总体概要设计结论汇总（可选）：达成一致的结论有个简要概述，说明详设是对这些结论的实现；

(2)交互流程：简要的交互可用文字说明，复杂的交互建议使用流程图，交互图或其他图形进行说明；

(3)数据库设计：这个是应该放在总设还是详设呢？

(4)接口形式：有了数据库+接口+流程，别的同学拿到详设文档，基本也能够搞定了；

(5)其他细节：例如公式等；

理论上输出了详细设计之后，无论谁拿到了这个详设文档，都是能够完成该项目的。

个人实践分享：

一、大图

(1) 大系统或复杂流程，其架构图或者流程图会非常大，经常比A4纸或word的一页大很多，此时不宜在word中直接贴图形，贴了也看不清，建议将图放在wiki上，文档中直接贴链接；

(2) 一定要保存viso或者其他图形的源文件，否则今后改动起来要重画，代价可想而知；

二、设计与折衷

(1) 设计与折衷是总设中最重要的内容，总设评审中，主要就是讨论这些折衷的优劣；

(2) 评审过后，不但要邮件周知结论，还要在总设中进行更新，说明最终决定使用了哪种方案，为什么使用这种方案；根据自己的经验，接手别人的模块、项目，拿到代码和文档，设计方案对我来说完全是个谜！！！

(3) 有时候因为排期或者其他原因，不一定采用了最优的设计方案，此时更应该在总设中记录决策的过程与原因；

(4) 最后，设计折衷是一个很好的自我辩解的机会：因为项目进度，或者历史遗留问题，我不得不采取了一个这样的设计，不要再骂我了。

三、性能目标

性能目标是新模块文档必不可少的一部分，很多项目对性能影响较大的话，也必须撰写性能目标，性能一般来说可能包含以下部分：

(1) 日平均请求：一般来自产品人员的评估；

(2) 平均QPS：日平均请求 除以 4w秒得出，为什么是4w秒呢，24小时化为86400秒，取用户活跃时间为白天算，除2得4w秒；

(3) 峰值QPS：一般可以以QPS的2~4倍计算；

互联网公司，产品迭代块，项目周期长，基本没有“文档”一说，但其实写好文档，对系统和项目未来的维护是非常有帮助的。

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

按照以下格式填就好了，不过是我自己写的，有不好的地方大家互相学习修改一下~ 详细设计文档规范 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 补充信息 （如果有需要特别说明的）。

7.我该怎么写详细开发文档

以下nbsp；是我们单位的nbsp；项目开发计划书nbsp；希望对你有帮助编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、nbsp；所需经费预算、所需软、硬件条件等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开nbsp；发工作。

编制内容要求如下：nbsp;nbsp;nbsp;nbsp;1nbsp；引言nbsp;nbsp;nbsp;1.1编写目的nbsp;nbsp;nbsp;nbsp；说明编写这份项目开发计划的目的，并指出预期的读者。nbsp;nbsp;nbsp;1.2背景nbsp;nbsp;nbsp；说明：nbsp;nbsp;nbsp;a.待开发的软件系统的名称；nbsp;nbsp;nbsp;b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；nbsp;nbsp;nbsp;C.该软件系统同其他系统或其他机构的基本的相互来往关系。

nbsp;nbsp;nbsp;1.3定义nbsp;nbsp;nbsp;nbsp；列出本文件中用到的专门术语的定义和外文首字母组词的原词组。nbsp;nbsp;nbsp;1.4参考资料nbsp;nbsp;nbsp；列出用得着的参考资料，如：nbsp;nbsp;nbsp;a.本项目的经核准的计划任务书或合同、上级机关的批文；nbsp;nbsp;nbsp;b.属于本项目的其他已发表的文件；nbsp;nbsp;nbsp;C.本文件中各处引用的文件、资料，包括所要用到的软件开发标准。

以下nbsp；是我们单位的nbsp；项目开发计划书nbsp；希望对你有帮助编制项目开发计划的目的是用文件的形式，把对于在开发过程中各项工作的负责人员、开发进度、nbsp；所需经费预算、所需软、硬件条件等问题作出的安排记载下来，以便根据本计划开展和检查本项目的开nbsp；发工作。

编制内容要求如下：nbsp;nbsp;nbsp;nbsp;1nbsp；引言nbsp;nbsp;nbsp;1.1编写目的nbsp;nbsp;nbsp;nbsp；说明编写这份项目开发计划的目的，并指出预期的读者。nbsp;nbsp;nbsp;1.2背景nbsp;nbsp;nbsp；说明：nbsp;nbsp;nbsp;a.待开发的软件系统的名称；nbsp;nbsp;nbsp;b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；nbsp;nbsp;nbsp;C.该软件系统同其他系统或其他机构的基本的相互来往关系。

nbsp;nbsp;nbsp;1.3定义nbsp;nbsp;nbsp;nbsp；列出本文件中用到的专门术语的定义和外文首字母组词的原词组。nbsp;nbsp;nbsp;1.4参考资料nbsp;nbsp;nbsp；列出用得着的参考资料，如：nbsp;nbsp;nbsp;a.本项目的经核准的计划任务书或合同、上级机关的批文；nbsp;nbsp;nbsp;b.属于本项目的其他已发表的文件；nbsp;nbsp;nbsp;C.本文件中各处引用的文件、资料，包括所要用到的软件开发标准。

nbsp；列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。nbsp;nbsp;nbsp;2nbsp；项目概述nbsp;nbsp;nbsp;nbsp;2.1nbsp；工作内容nbsp;nbsp;nbsp；简要地说明在本项目的开发中须进行的各项主要工作。

nbsp;nbsp;nbsp;2.2主要参加人员nbsp;nbsp;nbsp；扼要说明参加本项目开发工作的主要人员的情况，包括他们的技术水平。nbsp;nbsp;nbsp;nbsp;2.3产品nbsp;nbsp;nbsp;2.3.1程序nbsp;nbsp;nbsp；列出需移交给用户的程序的名称、所用的编程语言及存储程序的媒体形式，并通过引用有关文件，逐项说明其功能和能力。

nbsp;nbsp;nbsp;nbsp;2.3.2文件nbsp;nbsp;nbsp；列出需移交给用户的每种文件的名称及内容要点。nbsp;nbsp;nbsp;nbsp;2.3.3服务nbsp;nbsp;nbsp；列出需向用户提供的各项服务，如培训安装、维护和运行支持等，应逐项规定开始日期、所提供支持nbsp；的级别和服务的期限。

nbsp;nbsp;nbsp;2.3.4非移交的产品nbsp;nbsp;nbsp;nbsp；说明开发集体应向本单位交出但不必向用户移交的产品（文件甚至某些程序）。nbsp;nbsp;nbsp;2.4验收标准nbsp;nbsp;nbsp;nbsp；对于上述这些应交出的产品和服务，逐项说明或引用资料说明验收标准。

nbsp;nbsp;nbsp;nbsp;2.5完成项目的员迟用限nbsp;nbsp;nbsp;nbsp;2.6本计划的批准者和批准日期nbsp;nbsp;nbsp;nbsp;3nbsp；实施计划nbsp;nbsp;nbsp;nbsp;3.1工作任务的分门与人员分工nbsp;nbsp；软件开发网nbsp;nbsp;nbsp；对于项目开发中需完成的各项工作，从需求分析、设计、实现、测试直到维护，包括文件的编制、审批、打印、分发工作，用户培训工作，软件安装工作等，按层次进行分解，指明每项任务的负责人和参加人员。nbsp;nbsp;nbsp;3.2nbsp；接口人员nbsp;nbsp;nbsp；说明负责接口工作的人员及他们的职责，包括：nbsp;nbsp;nbsp;anbsp；.负责本项目同用户的接口人员；nbsp;nbsp;nbsp;b.负责本项目同本单位各管理机构，如合同计划管理部门、财务部门、质量管理部门等的接口人员；nbsp;nbsp;nbsp;nbsp;c.负责本项目同各分合同负责单位的接口人员等。

nbsp;nbsp;nbsp;nbsp;3.3进度nbsp;nbsp;nbsp;nbsp；对于需求分析、设计、编码实现、测试、移交、培训和安装等工作，给出每项工作任务的预。定开始日期、完成日期及所需资源，规定各项工作任务完成的先后顺序以及表征每项工作任务完成的标志性事件（即所谓“里程碑“）。

nbsp;nbsp;nbsp;nbsp;3.4预算nbsp;nbsp;nbsp;nbsp；逐项列。

转载请注明出处育才学习网 » 项目的详细设计文档怎么写