软件概要设计报告文档模板
1. 引言.... 3
1.1 编写目的... 3
1.2 项目风险... 3
1.3 预期读者和阅读建议... 3
1.4 参考资料... 3
2. 设计概述.... 4
2.1 限制和约束... 4
2.2 设计原则和设计要求... 4
3. 系统逻辑设计.... 5
3.1 系统组织设计... 5
3.2 系统结构设计... 5
3.2.1 系统特性表... 6
3.2.2 系统特性结构图... 7
3.3 系统接口设计... 7
3.3.1 系统接口表... 7
3.3.2 系统接口传输协议说明... 8
3.4 系统完整性设计... 8
4. 系统出错处理设计.... 9
4.1 系统出错处理表... 9
4.2 维护处理过程表... 10
5. 技术设计.... 11
5.1 系统开发技术说明表... 11
5.2 开发技术应用说明... 12
6. 数据库设计.... 12
7. 词汇表.... 12
8. 进度计划.... 12
1. 引言
引言是对这份软件系统概要设计报告的概览，是为了帮助阅读者了解这份文档是如何编写的，并且应该如何阅读、理解和解释这份文档。
1.1 编写目的
说明这份软件系统概要设计报告是基于哪份软件产品需求规格说明书编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件系统概要设计报告详尽说明了该软件产品的软件结构，包括数据库结构和出错处理，从而对该软件产品的结构的描述。
如果这份软件系统概要设计报告只与整个系统的某一部分有关系，那么只定义软件系统概要设计报告中说明的那个部分或子系统。
1.2 项目风险
具体说明本软件开发项目的全部风险承担者，以及各自在本阶段所需要承担的主要风险，首要风险承担者包括：
● 任务提出者；
● 软件开发者；
● 产品使用者。
1.3 预期读者和阅读建议
列举本软件系统概要设计报告所针对的各种不同的预期读者，例如，可能的读者包括：
● 用户；
● 开发人员；
● 项目经理；
● 营销人员；
● 测试人员；
● 文档编写人员；
● 等等。
描述文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。
1.4 参考资料
列举编写软件产品概要设计报告时所用到的参考文献及资料，可能包括：
● 本项目的合同书；
● 上级机关有关本项目的批文；
● 本项目已经批准的计划任务书；
● 用户界面风格指导；
● 开发本项目时所要用到的标准；
● 系统规格需求说明；
● 使用实例文档；
● 属于本项目的其它已发表文件；
● 本软件系统概要设计报告中所引用的文件、资料：
● 相关软件系统概要设计报告：
● 等等。
为了方便读者查阅，所有参考资料应该按一定顺排列。如果可能，每份资料都应该给出：
● 标题名称；
● 作者或者合同签约者；
● 文件编号或者版本号；
● 发表日期或者签约日期；
● 出版单位或者资料来源。
2. 设计概述
本节描述现有开发条件和需要实现的目标，说明进行概要设计时应该遵循的设计原则和必须采用的设计方法。
2.1 限制和约束
简要描述起到限制和约束作用的各种可能存在的条件，例如：
● 技术条件；
● 资金状况；
● 开发环境(包括：工具和平台)；
● 时间限制；
● 等等。
并且说明在上述条件下，应该实现的系统目标，
2.2 设计原则和设计要求
描述对本软件系统进行概要设计的原则，通常可以考虑以下几方面的内容：
● 命名规则；
● 模块独立性原则：
● 边界设计原则；
● 数据库设计规则；
● 必须的安全措施；
● 安全性和保密原则；
● 系统灵活性要求；
● 系统易操作性要求；
● 系统可维护性要求；
● 等等。
3. 系统逻辑设计
本节内容主要根据软件产品需求规格说明书和软件产品数据字典建立系统的逻辑模型。此种模型暂时与系统的物理因素(例如：计算机、数据库管理系统)无关。它是系统需求与物理实现的中间结构，它的主要结果是建立：系统结构图、系统界面结构图、系统出错处理、以及系统开发技术说明。
说明：如果进行系统设计时尚未编写软件数据字典：应首先参照附录B说明，编写软件数据字典。在完成软件数据字典后，再进行系统设计。
3.1 系统组织设计
系统组织设计通过系统组织表描述本系统由哪些子系统(模块)组成，这些子系统与业务职能之间的关系，以及各个子系统的安装地点。系统组织表的格式如下：
其中：
● 子系统编号
给出本系统中指定子系统的顺序编号。如果本系统末划分为多个子系统，仅由一
个运行模块组成；则本项内容仍需要描述，但是本表内容只有一行。
说明：在一个系统中有可能安装若干个相同的子系统，在这种情况下，应该视为
一个子系统，并且对多个安装地点分别进行描述。如果相同的子系统通过系统设
置，实现的业务职能具有明显差异时，应该采用多行进行分别描述，并且在备注
中说明其差异所在。
● 子系统英文名称
给出本子系统的英文名称，该名称是在应用软件中实际使用的可执行文件名称，
必须能够说明该子系统的特点。
若本系统中只有一个子系统，则本项内容仍需要描述，但是本表内容只有一行。
● 子系统中文名称
给出本子系统的中文名称，该名称必须能够说明该子系统的特点。
若本系统中只有一个子系统，则本项内容仍需要描述，但是本表内容只有一行。
● 业务职能
描述该子系统完成的核心业务。
● 安装地点
描述该子系统实际安装的部门、或者某个具体地点。
● 备注
针对该子系统，需要说明的其它有关问题。
3.2 系统结构设计
本节将对系统特性作较为详细的描述，并给出系统特性结构图。
3.2.1 系统特性表
系统特性是系统中完成某项具体操作的基本单元，它由入口参数，出口参数以及处理过程三部分组成。
系统特性可以具有操作界面，也可以没有操作界面；可以被其它操作界面、或者系统特性调用，也可以调用其它操作界面、非操作界面、或者系统特性；但是不允许递归调用(调用自己)，包括间接递归调用。
当系统由多个子系统(模块)组成时，每个子系统分别使用一张系统特性表进行描述。系统特性表的格式如下：
其中
● 子系统编号
含义同上。
● 子系统英文名称
含义同上。
● 子系统中文名称
含义同上。
● 特性编号
整个系统所有特性的统一编号。
● 系统特性英文名称
系统特性的英文正式名称，将来用于软件开发中，必须符合命名规范。
● 系统特性中文名称
系统特性的中文正式名称，来源于需求规格说明书中，系统特性一节中的有关描
述。
● 操作功能
是指该特性实际完成的操作说明。
● 调用对象
是指调用该系统特性的系统对象，这里的系统对象可以是系统特性、也可以是操作界面。
● 被调用对象
是指被该系统特性调用的系统对象，这里的系统对象可以是系统特性、也可以是操作界面。
说明：某些较低层的系统特性，可能不存在被调用对象。
● 备注
描述与该系统特性有关的其它注意事项。
● 说明
描述与该系统特性表有关的其它注意事项。
3.2.2 系统特性结构图
系统特性结构图给出系统特性在逻辑层面上相互之间的关系，其主要依据来源于需求规格说明书中，系统特性一节中的有关描述。
如果系统划分为多个子系统，应分别给出系统与子系统、以及各个子系统与系统特性的结构图。
绘制系统与子系统结构图时，一般不需要描绘出系统特性，如果确有必要，尽可能只画出第一层系统特性。绘制子系统与系统特性结构图时，通常也不需要描绘出第二层系统特性，如果确有必要可以画出，但是尽可能不要画出第三层系统特性。
3.3 系统接口设计
系统接口是一种非可视的系统界面，在多数情况下，它对用户是透明的。
本节将对系统接口作较为详细的描述，并给出接口说明清单。
3.3.1 系统接口表
接口作为系统的一种输入／输出形式，分为网络接口、数据库接口、RS-232串行通讯接口、IEEE—485串行总线接口、并行I/O接口等等多种类型。
对于一些为可视界面服务的接口，例如：打印机接口、显示器接口等，因为这类接口对应用软件是透明的，所以不在本节描述范围内。
当系统由多个子系统(模块)组成时，每个子系统分别使用一张系统接口表进行描述。系统接口表的格式如下：
其中：
● 子系统编号
含义同上。
● 子系统英文名称
含义同上。
● 子系统中文名称
含义同上。
● 接口编号
整个系统所有接口的统一编号。
● 接口名称
系统接口的正式名称，必须符合通常习惯。
● 接口类型
指出该接口所传输的数据在该模块中起到的作用。
● 接口性质
指出该接口在通讯中起到的作用，这里的作用可以是：
n 输入；
n 输出；
n 双向。
● 接口速率
指出该接口的传输速率。如果该接口依赖于其它通讯方式，那么传输速率将不高于它所依赖的其它通讯方式的速率。
● 接口协议
给出该接口实际使用的通讯协议。
● 相关对象
给出直接使用本接口的系统对象，这里的系统对象，可以是操作界面，也可以是系统特性。
● 备注
描述与该系统接口有关的其它注意事项。
● 说明
描述与该系统接口表有关的其它注意事项。
3.3.2 系统接口传输协议说明
逐项详细描述系统接口表中所列出各个系统接口使用的传输协议，以及其它相关内容，例如：驱动程序、动态连接库、等等。
3.4 系统完整性设计
描述系统对象(数据元、数据类)，所受到的逻辑约束关系。
当系统由多个子系统(模块)组成时，每个子系统应分别使用一张系统完整性约束表进行描述。系统完整性约束表的格式如下：
其中：
● 子系统编号
含义同上。
● 子系统英文名称
含义同上。
● 子系统中文名称
含义同上。
● 约束编号
整个系统所有约束的统一编号。
● 完整性名称
系统完整性约束的正式名称，必须符合通常习惯。
● 相对对象名
完整性约束中的相关对象(数据元和数据类)。
● 约束表达式
用一阶逻辑表达式表达的约束方程式。
● 备注
描述与该系统完整性约束有关的其它注意事项。
● 说明
描述与该系统完整性约束表有关的其它注意事项。
4. 系统出错处理设计
本节描述系统发生外界及内在错误时，所提供的错误信息及处理方法，它包括系统出错处理表及维护处理过程表。
4.1 系统出错处理表
本表给出有关出错处理的产生原因、提示信息、以及建议处理方法。
当系统由多个子系统(模块)组成时，每个子系统分别使用一张系统出错处理表进行描述。系统出错处理表的格式如下：
其中：
● 子系统编号
含义同上。
● 子系统英文名称
含义同上。
● 子系统中文名称
含义同上。
● 错误编号
整个系统所有错误的统一编号。
● 错误名称
错误的正式名称，该名称应该是常用的，并且为人们所普遍接受的。
● 错误原因
对该错误产生原因的解释与说明。
● 错误信息
产生该错误时，向用户发出的提示信息。
● 处理方式
对该错误处理的一种建议，此项允许缺省。
● 备注
描述与该系统错误有关的其它注意事项。
● 说明
描述与该系统错误表有关的其它注意事项。
4.2 维护处理过程表
系统出错时，将调用维护处理过程对错误进行处理，有关维护处理过程的各项内容由维护处理过程表进行描述。
当系统有多个子系统(模块)组成时，每个子系统分别使用一张维护处理过程表进行描述。维护处理过程表的格式如下：
其中：
● 子系统编号
含义同上。
● 子系统英文名称
含义同上。
● 子系统中文名称
含义同上。
● 错误编号
含义同上。
● 处理过程英文名称
系统维护处理过程的英文正式名称，将来用于软件开发中，必须符合命名规范。
● 处理过程中文名称
系统维护处理过程的中文正式名称，是系统维护处理过程英文名称的中文说明。
● 处理功能
描述本维护处理过程对错误的处理方式。
由于一个维护处理过程有可能具有对多个错误进行处理的能力，因此该处理功能
必须是针对本项错误编号的。
● 入口参数
进行本项错误处理时，赋给维护处理过程的入口参数。
● 出口参数
进行本项错误处理时，维护处理过程返回的出口参数。
● 备注
描述与该系统错误有关的其它注意事项。
● 说明
描述与该系统错误表有关的其它注意事项。
5. 技术设计
系统技术设计描述系统各个特性实际使用的开发技术，以及具体开发技术使用时应该注意的事项。
5.1 系统开发技术说明表
本表描述系统各个特性开发时实际使用的具体技术，只有一些不太常用的技术需要在这里描述。一些常用技术，例如：通过数据库接口调用存储过程，则不必冗述。
当系统由多个子系统(模块)组成时，每个子系统分别使用一张系统开发技术说明表进行描述。系统开发技术说明表的格式如下：
其中：
● 子系统编号
含义同上。
● 子系统英文名称
含义同上。
● 子系统中文名称
含义同上。
● 技术编号
这个系统所使用各种技术的统一编号。
● 开发技术英文名称
该开发技术的英文正式名称，可以便用缩写。
该名称应该是常用的，并且为人们所普遍接受的。
● 开发技术中文名称
该开发技术的中文正式名称，是该开发技术英文名称的中文说明。
该名称应该是常用的，并且为人们所普遍接受的。
● 处理功能
描述本开发技术的处理目的。
● 系统特性编号
含义同上。
由于一项开发技术可能在多处使用，因此针对一项开发技术，有可能存在多个系
统特性编号，在此必须一一列出。
● 备注
描述与该系统开发技术相关的其它注意事项。
● 说明
描述与该系统开发技术说明表有关的其它注意事项。
5.2 开发技术应用说明
逐项详细描述系统开发技术说明表中所列出各项系统开发技术使用的技术要点，以及其它相关内容，例如：所需的服务、使用的动态连接库、调用的组件、等等。
6. 数据库设计
如果该软件产品需要使用数据库，不论是使用数据库平台支撑的，还是采用由软件产品开发者自行定义的；都应该在完成软件产品需求分析报告后，开始进行软件产品详细设计之前，按照软件产品数据库设计说明文档模板完成数据库设计工作。
7. 词汇表
列出本文件中用到的专业术语的定义，以及有关缩写的定义(如有可能，列出相关的外文原向)。为了便于非软件专业或者非计算机专业人士阅读软件系统概要设计报告，要求使用非软件专业或者非计算机专业的术语进行描述。所以这里所指的专业术语，是指业务层面上的专业术语，而不是软件专业或者计算机专业的术语。但是，对于无法回避的软件专业或者计算机专业术语，也应该列入词汇表，并且加以准确定义。
8. 进度计划
列出进度计划，包括各子系统、各子模块完成进度计划，人员配备计划等。