<项目名称>

系统概要设计报告

版本 <1.1>

[注：以下提供的模板用于*******有限公司CMMI标准的模版。其中用尖括号括起来并以蓝色显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。]

[要定制 Microsoft Word 中的自动字段（选中时显示灰色背景），请选择“文件>属性”，然后将 标题、主题、作者和公司等字段替换为此文档的相应信息。关闭该对话框后，通过选择“编辑>全选（或 Ctrl-A）并按 F9，或只是在字段上单击并按 F9，可以在整个文档中更新自动字段。对于页眉和页脚，这一操作必须单独进行。按 Alt-F9，将在显示字段名称和字段内容之间切换。有关字段处理的详细信息，请参见 Word 帮助。]

文档信息及版本历史

LXGS/F/CMMI/PRJ-SE-TS-M-3

版权信息

本文件内容由【上海*****（集团）有限公司EPG】负责解释

本文件的版权属于【上海*****（集团）有限公司】和

【XXXXXXX此处写用户单位名称】

任何形式的散发都必须先得到本文档版本所属单位的许可

【目录】

1     概述... 4

1.1      编写目的... 4

1.2      适用范围... 4

1.3      读者对象... 4

1.4      术语和缩写... 4

1.5      参考资料... 5

2     设计概述... 5

2.1      设计约束... 5

2.2      设计策略... 5

2.3      技术实现... 5

3     系统概述... 6

4     系统总体架构... 6

4.1      平台架构... 6

4.2      功能架构... 6

5     模块1. 7

5.1      模块结构... 7

5.2      子模块1. 7

5.3      子模块2. 7

6     模块2. 7

6.1      模块结构... 7

6.2      子模块1. 7

6.3      子模块2. 8

7     运行环境... 8

7.1      软件平台... 8

7.2      硬件平台... 8

8     接口设计... 8

9     系统备份设计... 8

10           系统容错设计... 8

11           设计约定... 8

12           待解决问题... 8

1        概述

<提示：直接通过数据库进行操作的统计报表类系统，Sieble套件类系统该部分可以不描述>

<注意：

l  所有的正文使用正文格式；

l  每段的首行都使用Tab键缩进，不要使用空格进行缩进；

l  建议所有的文档编写者完成文档修改后，需要完成以下工作：确定当前版本、修改版本历史、更新目录、更新页眉、检查文档封面；

l  文档中编号的建议：本文档中基本上将标题都进行了编号，标题类的都使用数字型的分级编号；若在3级分级编号中，还需要再分级，请使用符号编号，符号统一使用“l”；

l  关于文件名命名问题：在《配置项标识规范》发布前（发布后，按照此规范要求命名)，为了便于历史记录和查找，建议可以先按照以下方式命名：

²  提交小组文档：文档名称+“_”+“日期简称”；

²  正式发布文档：文档名称+“V”+版本号。>

1.1   编写目的

<此处填写本文档的目的>

<例如：XXX项目的目的是：根据《XXX需求规格说明书》进行功能和体系结构分析设计>

1.2   适用范围

<此处填写本文档的适用范围>

<例如：适用于XXX项目的系统分析和设计过程>

1.3   读者对象

1.4   术语和缩写

<此处填写本文档中所特有的术语和缩写，常用的术语和缩写统一编写在一个规范文档中>

1.5   参考资料

<此处填写本文档的参考资料>

2        设计概述

<填写设计的概要，包括对各种所使用的设计方法的简要描述>

2.1   设计约束

<包括

（1）需求约束。从需求文档（如《用户需求说明书》和《软件需求规格说明书》）中提取需求约束，例如：

²  本系统应当遵循的标准或规范

²  软件、硬件环境（包括运行环境和开发环境）的约束

²  接口/协议的约束

²  用户界面的约束

²  软件质量的约束，如正确性、健壮性、可靠性、效率（性能）、易用性、清晰性、安全性、可扩展性、兼容性、可移植性等等。

（2）隐含约束。有一些假设或依赖并没有在需求文档中明确指出，但可能会对系统设计产生影响，应当尽可能地在此处说明。例如对用户教育程度、计算机技能的一些假设或依赖，对支撑本系统的软件硬件的假设或依赖等。>

2.2   设计策略

<根据产品的需求与发展战略，确定设计策略（Design Strategy）。例如：

²  扩展策略。说明为了方便本系统在将来扩展功能，现在有什么措施。

²  复用策略。说明本系统在当前以及将来的复用策略。

²  折衷策略。说明当两个目标难以同时优化时如何折衷，例如“时－空”效率折衷，复杂性与实用性折衷。>

2.3   技术实现

<本系统所采用的技术以及该技术的说明>

3        系统概述

<说明本系统“是什么”，描述本系统的主要功能>

4        系统总体架构

4.1   平台架构

<描述系统的平台架构设计，如主机、网络等>

<如果系统使用的主机较少，可直接在此说明。如果系统使用的主机多于2台，则在《系统平台设计说明书》中详细描述，此处直接参见《系统平台设计说明书》即可。>

4.2   功能架构

<将系统分解为若干模块，绘制功能逻辑图，说明各模块的主要功能,各模块如何协调工作，从而实现原系统的功能。可以用功能逻辑图表示。>

<建议分层描述本系统功能模块，功能模块可包含面向用户需求的功能模块，也可包含面向实现的功能模块（如实现数据库的通用访问等），层次建议两到三层。

功能逻辑图例样：

5        系统功能模块1

将模块分解为子模块，绘制功能逻辑图，说明各子模块的主要功能。说明各模块如何协调工作，从而实现该模块的功能。

5.1   模块结构

<对模块1中各子模块之间用功能逻辑图加以说明，并对子模块之间的关系加以说明>

功能逻辑图例样：

模块的名称定义和需求规格说明书中的第5章节功能需求描述中的功能模块名一一对应。

5.2   子模块1

 <对模块1的功能，结构，技术实现，逻辑处理说明>

5.3   子模块2

…

6        系统功能模块2

6.1   模块结构

6.2   子模块1

6.3   子模块2

…

7        运行环境

<系统实际运行时需要的环境：包括软件和硬件>

7.1   软件平台

7.2   硬件平台

8        数据库设计

<可以具体参见：《XXX_数据库设计说明书》>

9        接口设计

10  系统备份设计

11  系统容错设计

12  设计约定

<如果需要，可进行命名标准，界面风格，消息格式的定义和约定>

13  待解决问题

<列举系统尚存在的一些待解决的问题，如技术上的、业务上的还是管理上的>

—文档结束—

 

第二篇：软件概要设计报告文档模板

软件概要设计报告文档模板

1. 1 引言

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

1.1 1.1 编写目的

说明这份软件系统概要设计报告是基于哪份软件产品需求规格说明书编写的，开发这个软件产品意义、作用、以及最终要达到的意图。通过这份软件系统概要设计报告详尽说明了该软件产品的软件结构，包括数据库结构和出错处理，从而对该软件产品的结构的描述。

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

1.2 1.2 项目风险

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

●  任务提出者；

●  软件开发者；

●  产品使用者。

1.3 1.3 预期读者和阅读建议

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

●  用户；

●  开发人员；

●  项目经理；

●  营销人员；

●  测试人员；

●  文档编写人员；

●  等等。

描述文档中，其余部分的内容及其组织结构，并且针对每一类读者提出最适合的文档阅读建议。

1.4 1.4 参考资料

列举编写软件产品概要设计报告时所用到的参考文献及资料，可能包括：

●  本项目的合同书；

●  上级机关有关本项目的批文；

●  本项目已经批准的计划任务书；

●  用户界面风格指导；

●  开发本项目时所要用到的标准；

●  系统规格需求说明；

●  使用实例文档；

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

●  本软件系统概要设计报告中所引用的文件、资料：

●  相关软件系统概要设计报告：

●  等等。

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

●  标题名称；

●  作者或者合同签约者；

●  文件编号或者版本号；

●  发表日期或者签约日期；

●  出版单位或者资料来源。

2. 设计概述

本节描述现有开发条件和需要实现的目标，说明进行概要设计时应该遵循的设计原则和必须采用的设计方法。

2.1 限制和约束

简要描述起到限制和约束作用的各种可能存在的条件，例如：

●  技术条件；

●  资金状况；

●  开发环境(包括：工具和平台)；

●  时间限制；

●  等等。

并且说明在上述条件下，应该实现的系统目标，

2.2 设计原则和设计要求

描述对本软件系统进行概要设计的原则，通常可以考虑以下几方面的内容：

●  命名规则；

●  模块独立性原则：

●  边界设计原则；

●  数据库设计规则；

●  必须的安全措施；

●  安全性和保密原则；

●  系统灵活性要求；

●  系统易操作性要求；

●  系统可维护性要求；

●  等等。

3. 系统逻辑设计

本节内容主要根据软件产品需求规格说明书和软件产品数据字典建立系统的逻辑模型。此种模型暂时与系统的物理因素(例如：计算机、数据库管理系统)无关。它是系统需求与物理实现的中间结构，它的主要结果是建立：系统结构图、系统界面结构图、系统出错处理、以及系统开发技术说明。

说明：如果进行系统设计时尚未编写软件数据字典：应首先参照附录B说明，编写软件数据字典。在完成软件数据字典后，再进行系统设计。

3.1 系统组织设计

系统组织设计通过系统组织表描述本系统由哪些子系统(模块)组成，这些子系统与业务职能之间的关系，以及各个子系统的安装地点。系统组织表的格式如下：

其中：

●  子系统编号

给出本系统中指定子系统的顺序编号。如果本系统末划分为多个子系统，仅由一个运行模块组成；则本项内容仍需要描述，但是本表内容只有一行。

说明：在一个系统中有可能安装若干个相同的子系统，在这种情况下，应该视为一个子系统，并且对多个安装地点分别进行描述。如果相同的子系统通过系统设置，实现的业务职能具有明显差异时，应该采用多行进行分别描述，并且在备注中说明其差异所在。

●  子系统英文名称

给出本子系统的英文名称，该名称是在应用软件中实际使用的可执行文件名称，必须能够说明该子系统的特点。

若本系统中只有一个子系统，则本项内容仍需要描述，但是本表内容只有一行。

●  子系统中文名称

给出本子系统的中文名称，该名称必须能够说明该子系统的特点。若本系统中只有一个子系统，则本项内容仍需要描述，但是本表内容只有一行。

●  业务职能

描述该子系统完成的核心业务。

●  安装地点

描述该子系统实际安装的部门、或者某个具体地点。

●  备注

针对该子系统，需要说明的其它有关问题。

3.2 系统结构设计

本节将对系统特性作较为详细的描述，并给出系统特性结构图。

系统特性是系统中完成某项具体操作的基本单元，它由入口参数，出口参数以及处理过程三部分组成。

系统特性可以具有操作界面，也可以没有操作界面；可以被其它操作界面、或者系统特性调用，也可以调用其它操作界面、非操作界面、或者系统特性；但是不允许递归调用(调用自己)，包括间接递归调用。

当系统由多个子系统(模块)组成时，每个子系统分别使用一张系统特性表进行描述。系统特性表的格式如下：

其中

●  子系统编号

含义同上。

●  子系统英文名称

含义同上。

●  子系统中文名称

含义同上。

●  特性编号

整个系统所有特性的统一编号。

●  系统特性英文名称

系统特性的英文正式名称，将来用于软件开发中，必须符合命名规范。

●  系统特性中文名称

系统特性的中文正式名称，来源于需求规格说明书中，系统特性一节中的有关描

述。

●  操作功能

是指该特性实际完成的操作说明。

●  调用对象

是指调用该系统特性的系统对象，这里的系统对象可以是系统特性、也可以是操作界面。

●  被调用对象

是指被该系统特性调用的系统对象，这里的系统对象可以是系统特性、也可以是操作界面。

说明：某些较低层的系统特性，可能不存在被调用对象。

●  备注

描述与该系统特性有关的其它注意事项。

●  说明

描述与该系统特性表有关的其它注意事项。

系统特性结构图给出系统特性在逻辑层面上相互之间的关系，其主要依据来源于需求规格说明书中，系统特性一节中的有关描述。

如果系统划分为多个子系统，应分别给出系统与子系统、以及各个子系统与系统特性的结构图。绘制系统与子系统结构图时，一般不需要描绘出系统特性，如果确有必要，尽可能只画出第一层系统特性。绘制子系统与系统特性结构图时，通常也不需要描绘出第二层系统特性，如果确有必要可以画出，但是尽可能不要画出第三层系统特性。

3.3 系统接口设计

系统接口是一种非可视的系统界面，在多数情况下，它对用户是透明的。

本节将对系统接口作较为详细的描述，并给出接口说明清单。

接口作为系统的一种输入／输出形式，分为网络接口、数据库接口、RS-232串行通讯接口、IEEE—485串行总线接口、并行I/O接口等等多种类型。

对于一些为可视界面服务的接口，例如：打印机接口、显示器接口等，因为这类接口对应用软件是透明的，所以不在本节描述范围内。

当系统由多个子系统(模块)组成时，每个子系统分别使用一张系统接口表进行描述。系统接口表的格式如下：

其中：

●  子系统编号

含义同上。

●  子系统英文名称

含义同上。

●  子系统中文名称

含义同上。

●  接口编号

整个系统所有接口的统一编号。

●   接口名称

系统接口的正式名称，必须符合通常习惯。

●  接口类型

指出该接口所传输的数据在该模块中起到的作用。

●  接口性质

指出该接口在通讯中起到的作用，这里的作用可以是：

n 输入；

n 输出；

n 双向。

●  接口速率

指出该接口的传输速率。如果该接口依赖于其它通讯方式，那么传输速率将不高于它所依赖的其它通讯方式的速率。

●  接口协议

给出该接口实际使用的通讯协议。

●  相关对象

给出直接使用本接口的系统对象，这里的系统对象，可以是操作界面，也可以是系统特性。

●  备注

描述与该系统接口有关的其它注意事项。

●  说明

描述与该系统接口表有关的其它注意事项。

逐项详细描述系统接口表中所列出各个系统接口使用的传输协议，以及其它相关内容，例如：驱动程序、动态连接库、等等。

3.4 系统完整性设计

描述系统对象(数据元、数据类)，所受到的逻辑约束关系。当系统由多个子系统(模块)组成时，每个子系统应分别使用一张系统完整性约束表进行描述。系统完整性约束表的格式如下：

其中：

●  子系统编号

含义同上。

●  子系统英文名称

含义同上。

●  子系统中文名称

含义同上。

●  约束编号

整个系统所有约束的统一编号。

●  完整性名称

系统完整性约束的正式名称，必须符合通常习惯。

●  相对对象名

完整性约束中的相关对象(数据元和数据类)。

●  约束表达式

用一阶逻辑表达式表达的约束方程式。

●  备注

描述与该系统完整性约束有关的其它注意事项。

●  说明

描述与该系统完整性约束表有关的其它注意事项。

4. 系统出错处理设计

本节描述系统发生外界及内在错误时，所提供的错误信息及处理方法，它包括系统出错处理表及维护处理过程表。

4.1 系统出错处理表

本表给出有关出错处理的产生原因、提示信息、以及建议处理方法。当系统由多个子系统(模块)组成时，每个子系统分别使用一张系统出错处理表进行描述。系统出错处理表的格式如下：

其中：

●  子系统编号

含义同上。

●  子系统英文名称

含义同上。

●  子系统中文名称

含义同上。

●  错误编号

整个系统所有错误的统一编号。

●  错误名称

错误的正式名称，该名称应该是常用的，并且为人们所普遍接受的。

●  错误原因

对该错误产生原因的解释与说明。

●  错误信息

产生该错误时，向用户发出的提示信息。

●  处理方式

对该错误处理的一种建议，此项允许缺省。

●  备注

描述与该系统错误有关的其它注意事项。

●  说明

描述与该系统错误表有关的其它注意事项。

4.2 维护处理过程表

系统出错时，将调用维护处理过程对错误进行处理，有关维护处理过程的各项内容由维护处理过程表进行描述。

当系统有多个子系统(模块)组成时，每个子系统分别使用一张维护处理过程表进行描述。维护处理过程表的格式如下：

其中：

●  子系统编号

含义同上。

●  子系统英文名称

含义同上。

●  子系统中文名称

含义同上。

●  错误编号

含义同上。

●  处理过程英文名称

系统维护处理过程的英文正式名称，将来用于软件开发中，必须符合命名规范。

●  处理过程中文名称

系统维护处理过程的中文正式名称，是系统维护处理过程英文名称的中文说明。

●  处理功能

描述本维护处理过程对错误的处理方式。

由于一个维护处理过程有可能具有对多个错误进行处理的能力，因此该处理功能

必须是针对本项错误编号的。

●  入口参数

进行本项错误处理时，赋给维护处理过程的入口参数。

●  出口参数

进行本项错误处理时，维护处理过程返回的出口参数。

●  备注

描述与该系统错误有关的其它注意事项。

●  说明

描述与该系统错误表有关的其它注意事项。

5. 技术设计

系统技术设计描述系统各个特性实际使用的开发技术，以及具体开发技术使用时应该注意的事项。

5.1 系统开发技术说明表

本表描述系统各个特性开发时实际使用的具体技术，只有一些不太常用的技术需要在这里描述。一些常用技术，例如：通过数据库接口调用存储过程，则不必冗述。当系统由多个子系统(模块)组成时，每个子系统分别使用一张系统开发技术说明表进行描述。系统开发技术说明表的格式如下：

其中：

●  子系统编号

含义同上。

●  子系统英文名称

含义同上。

●  子系统中文名称

含义同上。

●  技术编号

这个系统所使用各种技术的统一编号。

●  开发技术英文名称

该开发技术的英文正式名称，可以便用缩写。

该名称应该是常用的，并且为人们所普遍接受的。

●  开发技术中文名称

该开发技术的中文正式名称，是该开发技术英文名称的中文说明。

该名称应该是常用的，并且为人们所普遍接受的。

●  处理功能

描述本开发技术的处理目的。

●  系统特性编号

含义同上。

由于一项开发技术可能在多处使用，因此针对一项开发技术，有可能存在多个系统特性编号，在此必须一一列出。

●  备注

描述与该系统开发技术相关的其它注意事项。

●  说明

描述与该系统开发技术说明表有关的其它注意事项。

5.2 开发技术应用说明

逐项详细描述系统开发技术说明表中所列出各项系统开发技术使用的技术要点，以及其它相关内容，例如：所需的服务、使用的动态连接库、调用的组件、等等。

6. 数据库设计

如果该软件产品需要使用数据库，不论是使用数据库平台支撑的，还是采用由软件产品开发者自行定义的；都应该在完成软件产品需求分析报告后，开始进行软件产品详细设计之前，按照软件产品数据库设计说明文档模板完成数据库设计工作。

7. 词汇表

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

8. 进度计划

列出进度计划，包括各子系统、各子模块完成进度计划，人员配备计划等。