系统详细设计书(模板)
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
客户(徽记)项目监理单位(徽记)密级:●绝密○机密○普通
项目名称
系统详细设计说明书
(版本号:)
[项目名称]—系统详细设计书
XXX公司
目录
第一章引言 (4)
1.1 文档目的 (4)
1.2 参考资料 (4)
第二章目标范围 (5)
2.1 业务目标 (5)
2.2 项目目标 (5)
2.3 设计目标 (5)
第三章系统结构 (6)
3.1 设计原则 (6)
3.2 系统框架 (6)
3.3 功能模块 (6)
3.4 部署结构 (6)
3.5 系统环境 (7)
第四章系统组件 (8)
4.1 组件规格 (8)
4.2 组件关系 (8)
4.3 组件模块 (9)
第五章系统数据 (10)
5.1 数据字典 (10)
5.2 数据结构/文件 (10)
第六章系统界面 (11)
6.1 界面结构 (11)
6.2 界面关系 (11)
6.3 数据和组件关联 (12)
第七章外部接口 (13)
7.1 输出接口 (13)
7.2 输入接口 (13)
第八章其他设计 (13)
[设计单位名称]
[项目名称]—系统详细设计书
第一章引言
1.1 文档目的
《系统详细设计书》是项目组的内部文档,是开发经理和开发人员在《系统逻辑设计书》的基础上,从系统的逻辑对象、数据实体和界面逻辑关系中进一步整理和细化得到的设计方案。《系统详细设计书》将确定系统采用的技术方案,平台,并明确实际开发的组件、数据库表、窗口以及页面等。详细设计是把现实的技术应用到逻辑模型上,并考虑到实现的可能性和最终系统的性能。
《系统逻辑设计书》的最终结果包含组件定义、特定平台上的用户界面设计,以及数据库的设计。《系统逻辑设计书》会说明系统的核心的算法,但具体每个模块的实现算法可以在模块的《开发文档》中说明。
《系统逻辑设计书》的主要读者是项目组成员。是开发经理制定《开发计划》、测试管理制定《测试计划》、实施人员制定《实施计划》的基础。
1.2 参考资料
说明编写《系统详细设计书》中参考的资料。其中必然包含的是《系统逻辑设计书》。
[设计单位名称]
第二章目标范围
在每个重要文档前面强调项目的目标和范围有利于保证项目执行过程中不发生偏差。项目的目标范围在《项目建议书》中已经有明确的定义,在《系统逻辑设计书》中也重复强调,这里可以根据项目进展做少量的修订。这部分内容应该基本同前面阶段的文档。
2.1 业务目标
从客户角度来看系统,说明系统实施后要能帮助客户解决哪些问题,使客户达到的什么目标。也要明确说明不解决的问题。这部分内容可以在《系统逻辑设计书》的基础上做少量修正。
2.2 项目目标
说明在当前阶段最终我们要达到的项目目标。这部分内容可以在《系统逻辑设计书》的基础上做少量修正。
2.3 设计目标
说明系统设计要达到的指标。综合并量化《需求分析报告》中第五章“系统规格”中的指标。
[项目名称]—系统详细设计书
第三章系统结构
3.1 设计原则
说明进行技术选型和实现方式时所遵循的原则。包括用户环境的限制、客户的要求、技术方面的考虑等等。
3.2 系统框架
说明系统的层次结构,以及这些层次之间的关系。
3.3 功能模块
系统总体的模块和功能组划分,这部分侧重每个模块和功能组的功能说明和接口。
3.4 部署结构
说明系统各个部署组成,说明每个层次所在的位置以及这些组成部分之间的联系。如果系统牵涉到其它外部系统,需要首先说明在用户方外部系统的部署结构。然后再说明开发系统的部署结构,验证系统的部署能满足用户整体系统部署环境下的要求。表示部署结构可以采用“网络、组件、数据拓扑图”的方式,在Visio中通过“企业应用”模板生成,例如:
[设计单位名称]
3.5 系统环境
说明最终系统实现的平台、工具以及软硬件环境。
[项目名称]—系统详细设计书
第四章系统组件
4.1 组件规格
说明每一个业务组件以及所提供的服务的接口。需要包括:
●类型:声明组件属于的类型,比如,是.dll, 是ActiveX dll, 是资源文件
(.bas, .js…),是exe, 是OCX, 是.lib等等。
●交互标准:描述组件之间采用何种交互标准(COM, DCOM…)。
●属性的访问:简要说明每一种属性的访问类型:只读,读/写。
●属性的物理类型:简要说明每一种属性的物理类型:整型,长整型,布尔型,
字符串型等等。
●接口:组件接口制定了组件之间的调用和被调用关系。它用于访问到接口之
下的服务,并且它可以表示一个或多个服务。一个发布的接口应当被视为接
口规范,保持不变。修改已有的接口应当发布为一个新的版本或作为一个完
全新的接口。
●每个接口提供的服务:类出服务的名称,然后给出具体的描述。
●前提条件:声明在执行一个操作之间的前提准备条件。前提条件意味着调用
者必须进行的检查工作。
●结果:声明操作执行之后环境情况如何。
●不变性:不变性是指对一个类的所有实例均不变的数据,如C++类中的静态
数据成员。
●依赖条件:与其他服务的依赖条件(组件内部或外部组件),按事件的执行顺
序或其他标准。
4.2 组件关系
说明组件之间存在的消息传递或者调用关系。组件关系的描述可以利用Visio的“COM和OLE”模板描述。例如: