系统概要设计报告模板

<项目名称>
系统概要设计报告
版本<1.1>
[注：以下提供的模板用于*******有限公司CMMI标准的模版。

其中用尖括号括起来并以蓝色显示的文本，它们用于向作者提供指导，在发布此文档之前应该将其删除。

]
[要定制Microsoft Word 中的自动字段（选中时显示灰色背景），请选择“文件>属性”，然后将标题、主题、作者和公司等字段替换为此文档的相应信息。

关闭该对话框后，通过选择“编辑>全选（或Ctrl-A）并按F9，或只是在字段上单击并按F9，可以在整个文档中更新自动字段。

对于页眉和页脚，这一操作必须单独进行。

按Alt-F9，将在显示字段名称和字段内容之间切换。

有关字段处理的详细信息，请参见Word 帮助。

]
文档信息及版本历史
版权信息
本文件内容由【上海*****（集团）有限公司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 (8)
6.3 子模块2 (8)
7 运行环境 (8)
7.1 软件平台 (8)
7.2 硬件平台 (8)
8 接口设计 (8)
9 系统备份设计 (8)
10 系统容错设计 (9)
11 设计约定 (9)
12 待解决问题 (9)
1概述
<提示：直接通过数据库进行操作的统计报表类系统，Sieble套件类系统该部分可以不描述> <注意：
●所有的正文使用正文格式；
●每段的首行都使用Tab键缩进，不要使用空格进行缩进；
●建议所有的文档编写者完成文档修改后，需要完成以下工作：确定当前版本、修改
版本历史、更新目录、更新页眉、检查文档封面；
●文档中编号的建议：本文档中基本上将标题都进行了编号，标题类的都使用数字型
的分级编号；若在3级分级编号中，还需要再分级，请使用符号编号，符号统一使
用“●”；
●关于文件名命名问题：在《配置项标识规范》发布前（发布后，按照此规范要求命
名)，为了便于历史记录和查找，建议可以先按照以下方式命名：
✧提交小组文档：文档名称+“_”+“日期简称”；
✧正式发布文档：文档名称+“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待解决问题
<列举系统尚存在的一些待解决的问题，如技术上的、业务上的还是管理上的>
—文档结束—。