软件详细设计说明书

展开全部 面向对象软件设计说明书模板 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) 对每个场景做一则条目，包括以下内容： 场景名：给它一个可以望文生义的名字 场景描述：简要叙述场景是干什么的以及发生的动作的顺序。

顺序图：描述各种事件及事...

详细设计说明书的说明书

1引言1.1编写目的说明编写这份详细设计说明书的目的，指出预期的读者。

1.2背景a.待开发软件系统的名称；b.本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。

1.3定义列出本项目中用到专门术语的定义和外文首字母组词的原词组。

软件工程中《软件需求规格说明书》和《详细设计说明书》区别。

展开全部 软件著作权申请中的文档，就是在软件设计过程中形成的文档。

根据软件工程的要求，在软件设计制作过程中，会形成多个文档。

整个过程一般会包括，用户需求报告、软件设计说明书、软件模块分析、软件模块设计和检测、软件整体统调和测试、生成用户操作手册等。

根据软件著作权登记的要求，这些过程中形成的对软件本身起说明性作用的文档，均可以作为软件著作权登记中的文档提交。

一般会提交设计说明书或者操作手册(即用户手册)。

所以，编写方法可以参见软件工程的相关教材。

...

软件开发详细设计说明书中的功能设计怎么写？请详述.

详细设计就是把项目里每个功能点都要完完整整列出来。

展开全部好比用户注册：在XX页面输入用户名、密码、电话、地址。

提交之后会返回什么样消息。

出错会提示什么情况。

最后还要加个流程图。

而需求只需要写明大概功能点要达到什么要的目的就可以了。

没这么细。

...

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

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

换言之，一个大型软 件系统在完成了一半的时候，其实还没有开始一行代码工作。

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