软件详细设计报告文档模板

软件详细设计报告文档模板

1.引言1 1.1编写目的1 1.2项目风险2 1.3文档约定2

1.4预期读者和阅读建议2 1.5参考资料2 2.支撑环境3

2.1数据库管理系统3

2.2开发工具、中间件以及数据库接口3 2.3硬件环境4 2.4网络环境4

2.5多种支撑环境开发要点5 3.部件详细设计5 4.词汇表6 5.部件表格式6 6.界面表格式7

1. 引言

引言是对这份软件系统详细设计报告的概览，是为了帮助阅读者了解这份文档如何编写的，并且应该如何阅读、理解和解释这份文档。

1.1 编写目的

说明这份软件系统详细设计报告是基于哪份软件产品需求分析报告、哪份软件产品概要设计报告和哪份软件产品数据库设计说明书(如果该软件产品需要数据库支持)编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件系统详细设计报告详尽说明了该软件产品的编码结构，从而对该软件产品的物理组成进行准确的描述。

如果这份软件系统详细设计报告只与整个系统的某一部分有关系，那么只定义软件系统详细设计报告中说明的那个部分或子系统。

. .可修编.

. -

1.2 项目风险

具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括：

● 任务提出者； ● 软件开发者； ● 产品使用者。

1.3 文档约定

描述编写文档时所采用的标准(如果有标准的话)，或者各种编写约定。编写约定应该包括：

● 部件编号方式； ● 界面编号方式； ● 命名规： ● 等等。

1.4 预期读者和阅读建议

列举本软件系统详细设计报告所针对的各种不同的预期读者，例如，可能的读者包括：

● 开发人员； ● 项目经理； ● 测试人员； ● 文档编写人员； ● 等等。 描述文档中，其余部分的容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。

1.5 参考资料

列举编写软件系统详细设计报告时所用到的参考文献及资料，可能包括：

● 本项目的合同书；

● 上级机关有关本项目的批文； ● 本项目已经批准的计划任务书； ● 用户界面风格指导；

● 开发本项目时所要用到的标难； ● 系统规格需求说明； ● 使用实例文档；

● 属于本项目的其它己发表文件；

● 本软件系统详细设计报告中所引用的文件、资料； ● 相关软件系统详细设计报告；

. .可修编.

. -

● 等等。

为了方便读者查阅，所有参考资料应该按一定顺序排列。如果可能，每份资料都应该给出：

● 标题名称；

● 作者或者合同签约者； ● 文件编号或者版本号； ● 发表日期或者签约日期； ● 出版单位或者资料来源。

2. 支撑环境

2.1 数据库管理系统

描述数据库管理系统、以及安装配置情况，需要描述的容可能包括：

● 产品名称以及发行厂商

这里的产品名称指的是数据库发行厂商发布产品时公布的正式商品名称，不应该 使用别名、简称、研发代号等非正式名称，以免混淆；同样的道理，发行厂商的 名称也应该使用正式名称。 ● 版本号

数据库管理系统的准确版本号，必须按产品的实际情况描述到最细节的版本号。 ● 补丁包版本号

描述实际上将要使用的数据库管理系统补丁包的版本号，必须注意，在某些情况 下该版本号不一定是最新的版本号。 ● 语言或代码集

对于只支持一种语言或者一个代码集的数据库管理系统来说，该项描述不具意 义。对于支持多种语言或者多个代码集的数据库管理系统来说，该项描述指的是 实际使用的语言或者代码集。 ● 安装位置

描述数据库管理系统的实际安装位置，应该分别对管理系统安缺位置和数据存放 位置进行描述，应该指明服务器名和安装卷号(盘号)。对于分布式数据库，必须 分别描述每一个数据库管理系统。 ● 配置参数

描述数据库管理系统在实际安装时应该配置的各个参数，对于分布式数据库，必 须分别描述每一个数据库管理系统的配置参数。 ● 等等

同时参照《市交通局信息化数据库建设规》。

2.2 开发工具、中间件以及数据库接口

描述所选用的工具软件和中间件的名称、版本号，以及开发工具与数据库或者中间件接

. .可修编.

. -

口的情况。如果使用了多种开发工具、辅助开发工具、第三方软件部件、多种中间件、多种接口、等答应该逐项分别描述，并且说明每一项的适用围。需要描述的容可能包括：

● 产品名称以及发行厂商

同2.1中产品名称以及发行厂商。 ● 版本号

同2.1中版本号。 ● 补丁包版本号

同2.1中补丁包版本号。 ● 语言或代码集

同2.1中语言或代码集。 ● 数据库接口名称

描述数据库接口的名称，如果使用别名时，应同时描述使用的别名。 ● 数据库接口方式

描述与数据库接口的方式，并说明该接口方式的特点；如果需要，还应该说明使 用时的注意事项。 ● 数据库接口设置

描述各种接口设置，包括：协议、端口号等等。 同时参照《市交通局信息化数据库建设规》。

2.3 硬件环境

描述所选用的硬件环境，各种机型，例如：服务器、工作站，应该分别描述。需要描述的容可能包括：

● 机型； ● 主频； ● 存容量； ● 磁盘容量； ● 特殊部件； ● 操作系统； ● 使用位置； ● 等等。

2.4 网络环境

描述可能影响应用软件访问数据库的各种网络环境，如果存在加密传输、VPN链路等情况，也必须描述。对于结构复杂的网络，还应该提供网络拓扑图和数据流向示意图。需要描述的容可能包括：

● 网络结构； ● 网络操作系统； ● 网络带宽； ● 路由组织； ● 加密传输方式； ● VPN链路连接方式；

. .可修编.

. -

● 等等。

2.5 多种支撑环境开发要点

当软件产品将来可能遇到的多种运行环境时，应该分别按照3.1节至3.4节的容列表描述。如果软件产品各个子系统的运行环境不完全一样时，应该分子系统按照3.1节至3.4节的容列表描述。

遇到上述情况时，不仅需要详细描述各种软件开发、调试、测试的环境，为了确实保证软件产品将来能够在各种可能的运行环境中正常运行，还需要对软件产品进行严格的配置管理。

3. 部件详细设计

这里所提及的软件部件，系指能够完成特定功能、相对独立的一些代码集合，它们可以是插件、组件、控件、函数、过程、子程序、动态连接库、等等。具体呈何种形态，取决于实际采用的开发工具和将要实现的软件结构。

按照合适的顺序，逐个描述软件部件的详细情况。描述的顺序可以是按层次横向进行描述，也可以是按模块纵向进行描述，总之描述的方式必须有利于读者理解软件结构。

每个部件采用一软件部件表进行描述，软件部件表的格式见附表一，其中；

● 部件编号

软件部件的统一顺序编号；对于实行配置管理的软件开发项目来说，该编号必须 与该部件在配置管理中的编号相同。 ● 部件名称

软件部件的正式英文名称，该名称是程序中使用的实际名称，必须符合国家相关软件命名标准。

● 所属子系统

指该部件所属的子系统；

对于不分为多个子系统的软件来说，不必填写该栏。 ● 部件调用者

指调用该部件的部件(或界面参数)的编号和名称。 ● 部件被调用者

指被该部件所调用的部件的编号和名称。 ● 部件入口参数

指该部件入口数据类名称或者数据名称，以及对这些数据的描述； 如果部件没有入口参数，该栏为空。 ● 部件出口参数

指该部件出口数据类名称或者数据名称，以及对这些数据的描述； 如果部件没有出口参数，该栏为空。 ● 算法

指该部件的算法形式表示，如果很简单、或者不存在，也可以为空。 ● 流程描述

指该部件的处理流程的详细表示或描述。

. .可修编.

. -

● 部件表示形式

指该部件完成开发后的最终表示形式，具体形式取决于开发工具和软件结构，表 示形式可能是：

 插件、组件、控件，  函数、过程、子程序，  存储过程，  动态连接库，  等等。 ● 运行环境

描述该部件所适合的运行环境，即说明该部件是针对何种运行环境所开发的； 可以直接描述运行环境，也可以描述运行环境的编号；

对于实行配置管理的软件开发项目来说，该描述必须与该部件在配置管理中的描 相同。

● 性能要求

指开发该部件时必须满足的专门要求，这些要求可以是：  精度  灵活性  响应时间  可重用性  等等。

提出的要求一般不宜超过3项，以排列的先后顺序表示优先级。

4. 词汇表

列出本文件中用到的专业术语的定义，以及有关缩写的定义(如有可能，列出相关的外文原词)。为了便于非软件专业或者非计算机专业人士也能够在一定的围，读懂软件系统详细设计报告，要求尽可能使用非软件专业或者非计算机专业的术语进行描述。所以这里所指的专业术语，是指业务层面上的专业术语，而不是软件专业或者计算机专业的术语。但是，对于无法回避的软件专业或者计算机专业术语，也应该列入词汇表，并且加以准确定义。

5. 部件表格式

部件编号 所属子系统 部件调用者 部件被调用者 部件入口参数 部件入口参数 算法： 部件名称 . .可修编.

. -

流程描述： 表示性能 性能要求 运行环境 说明：如果软件不见使用一表表述不完时，可以采用续表描述，但是必须注明是那表的续表。

6. 界面表格式

界面编号 界面性质 表示形式： 界面参数 参数名 容 说明 部件名称 界面介质 . .可修编.

. -

说明：如果软件不见使用一表表述不完时，可以采用续表描述，但是必须注明是那表的续表。

. .可修编.