标签：编程人员   程序员   规范   部件   man   提交   失败   documents   联网   

1《立项建议书》....................................................................................... 1

2《软件项目投标书》................................................................................. 6

3《软件产品开发任务书》........................................................................... 7

4《软件开发计划书》............................................................................... 10

5《用户需求报告》.................................................................................. 14

6《需求规格说明书》............................................................................... 18

7《需求报告 / 需求规格说明书评审记录表》.................................................. 22

8“图书馆信息系统”............................................................................... 24

9《概要设计说明书》............................................................................... 25

10《详细设计说明书》.............................................................................. 30

11《用户使用手册》................................................................................. 34

12《用户安装手册》................................................................................ 35

13《测试报告》...................................................................................... 36

14软件质量保证关键过程域SQA................................................................. 39

15《CMM软件质量保证过程文件》.............................................................. 42

16《CMM软件质量保证程序文件》.............................................................. 44

17《软件质量保证计划》........................................................................... 46

1《立项建议书》

1．引言（Introduction）

1.1 目的（Purpose）

本文档是软件立项书，目的是代替可行性分析。

1.2 范围（Scope）

本文档只适应于软件立项。

1.3 术语定义（Terms Glossary）

对软件组织内部和外部有关的行业术语、专用名词进行定义。

[1] ……

[2] ……

1.4 参考资料（References）

对书写该立项书所用到的有关资料进行说明。

[1] ……

[2] ……

1.5 相关文档（Related Documents）

当该文档变更时，可能对其他文档产生影响，受影响的文档叫做相关文档，需将它们一一列出。

[1] ……

[2] ……

1.6 版本更新记录（Version Updated Record）

任何一次版本创建或维护更新，都要追加一条记录。一个版本创建只有一次，但对它的维护更新可能有多次。大版本升级一次，定义为创建一次，如V1.0到V2.0。而V1.0到V1.1，只是维护更新一次。版本更新记录格式，如表3-2所示。

表3-2  版本更新记录

2．项目概述及架构（Project Summary and Framework）

2.1 项目概述（Project Summary）

宏观上说明该项目是什么、能干什么、要求干得怎么样。

2.2 项目架构（Project Framework）

宏观上描述该项目的架构：单机结构、C/S结构、B/S结构。并说明结构具体详细的运行平台：硬件的要求、操作系统的要求、数据库管理系统的要求、对外接口的要求。

3．客户群分析（Client Analysis）

3.1 客户群定位（Client Orientation）

单机结构、C/S结构、B/S结构对应哪三种客户群，每种客户群的数量、素质、市场前景等。

3.2 当前客户群分析（Current Client Analysis）

当前客户群是指已签订合作协议或将要签订合作协议的客户群，分析他们的数量、素质、市场前景等。

3.3 潜在客户群分析（Latency Client Analysis）

潜在客户群是指将来可能发展的客户群，分析他们的数量、素质、市场前景等。

4．项目功能（Project Function）

4.1 单机版功能（Stand-alone Function）

单机版功能，如表3-3所示。

表3-3  单机版功能

4.2 网络版功能（Network Function）

网络版功能，如表3-4所示。

表3-4  网络版功能

4.3 互联网络版功能（Internet Function）

互联网络版功能，如表3-5所示。

表3-5  互联网络版功能

5．项目性能（Project Performance）

5.1 响应时间（Response Time）

单机结构（包括主机多用户结构，即H/T结构）、C/S结构、B/S结构三种架构的终端数量，要求响应时间小于0.XX秒。

5.2 处理速度（Disposal Speed）

C/S结构、B/S结构两种架构的后台结算方式，结算速度分析。

5.3 最大终端负载（The Highest Terminal Load）

C/S结构、B/S结构两种架构的并发处理最大终端（用户）负载数量分析。

以上性能要求，最好也用列表的形式给出。

6．项目接口（Project Interface）

6.1 金融接口（Finance Interface）

金融接口列表，如表3-6所示。

表3-6  金融接口列表

6.2 政府接口（Government Interface）

政府接口列表，如表3-7所示。

表3-7  政府接口列表

6.3 互联网接口（Internet Interface）

互联网接口列表，如表3-8所示。

表3-8  互联网接口列表

7．投入产出分析（Analysis of the Devotion and the Output）

7.1 人力资源投入（Manpower Devotion）

人力资源投入，如表3-9所示。

表3-9  人力资源投入

7.2 设备资源投入（Facility Devotion）

设备资源投入，如表3-10所示。

表3-10  设备资源投入

7.3 其他经费资源投入（Other Outlay Devotion）

其他经费资源投入，如表3-11所示。

表3-11  其他经费资源投入

7.4 产出分析（Output Analysis）

产出分析，如表3-12所示。

表3-12  产 出 分 析

8．开发计划（Development Scheme）

8.1 进度计划（Plan Scheme）

开发进度计划，如表3-13所示。

表3-13  进 度 计 划

8.2 评审计划（Review Scheme）

各里程碑的评审计划，如表3-14所示。

表3-14  评 审 计 划

9．案例分析（Cases Analysis）

案例分析包括成功案例和失败案例分析。

9.1 国外案例分析（Cases Analysis in Foreign Countries）

案例1：……

案例2：……

9.2 国内案例分析（Cases Analysis in China）

案例1：……

案例2：……

10．风险分析（Risk Analysis）

10.1 需求风险（Risk of Requirement）

指项目组对用户需求获取的途径和能力有何风险，用户主动配合需求的程度。

10.2 政策风险（Risk of Policy）

指国家政策、行业政策、企业内部政策的变化对项目将会产生有利或不利的影响。

10.3 资源风险（Risk of Resource）

指开发和运行所需资源的风险程度。

10.4 技术风险（Risk of Technology）

指项目组采用新技术的风险程度。如最新开发工具的风险程度、最新设计思想的风险程度。

10.5 技能风险（Risk of Skill）

2《软件项目投标书》

续表

3《软件产品开发任务书》

任务书名称：大型商业MIS产品开发任务书。

下达日期：1999/04/01。

发出部门：XX公司研发中心。

接受部门：研发中心商业软件部。

1．目标

（1）做成商业MIS产品，其产品化程度要求很高。因此，一切信息都要规范化、标准化、代码化。保证在产品实施时，其客户化工作只需录入代码和修改代码，绝对不允许修改数据结构和表结构；

（2）配合市场销售部门、全国各地的分支机构和产品代理商，第一年开拓市场3~5个客户，第二年占领10% 的商业MIS市场。

2．功能模块划分及要求

大型商业MIS软件产品拟分为以下6个功能模块，要求每个功能模块具有高内聚、低耦合、信息隐蔽的性质，如表3-16所示。

表3-16  大型商业MIS产品的6个功能模块

3．功能模块详述

大型商业MIS软件，从组织结构上来说包括三个层次：

（1）物流配送中心

（2）大型商场（大型连锁超市）

（3）便利店（小型连锁超市）

作为一个完整的商业MIS系统来说，物流配送中心与大型商场（大型连锁超市）之间会发生物流、资金流、信息流的关系；大型商场（大型连锁超市）与便利店（小型连锁超市）之间也会发生物流、资金流、信息流的关系；而物流配送中心与便利店（小型连锁超市）之间没有任何关联。若将这三个模块分开来看，它们又可以各自独立成为一个单独的小型商业系统来使用。实际上，本大型商业MIS系统完成后，可以对功能模块进行组合或拆分，使其成为如下5个不同的小型商业MIS系统，供用户选择：

（1）物流配送中心 ＋ 大型商场（大型连锁超市）＋ 便利店（小型连锁超市）的完整的商业MIS软件。

（2）物流配送中心 ＋ 大型商场（大型连锁超市）的商业MIS软件。

（3）大型商场（大型连锁超市）＋ 便利店（小型连锁超市）的商业MIS系统。

（4）物流配送中心MIS系统。

（5）大型商场的商业MIS系统。

作为本软件的第一层，物流配送中心可以具有多个配送仓库，它根据大型商场（大型连锁超市）的需要以及各个仓库库存情况，向供应商订货，进行货物采购；并根据订货的情况进行配货，组织运输工具进行发货；期间，还伴随着向供应商付款、索取发票，以及向客户催款、开出发票等等。大型商场（大型连锁超市）作为本软件的第二层，除了要进行本商场的各种业务管理外，还要向上级物流配送中心订货、付款、索取发票，向下级便利店（小型连锁超市）送货，收取钱款等等。便利店（小型连锁超市）作为本软件的第三层，一要进行本商场的各种业务管理；二要根据库存情况，向大型商场（大型连锁超市）要货，并定期将销售金额上交给大型商场（大型连锁超市）。

考虑到目前有些商场，已经有了其他的商业管理软件，虽然软件还有不完善的地方，但已经购买前台POS机。为了给客户节省开支，有效地将前台POS机利用好，所以，本系统的前台销售软件就要做两个版本：Windows 版本与DOS 版本。

由于配送中心与大型商场（大型连锁超市）之间、大型商场（大型连锁超市）与便利店（小型连锁超市）之间在物理位置上有一定的距离，所以，它们之间的网络连接也是一个需要重视的大问题。本系统考虑采用两种解决方案：一是采用DDN专线（或光缆），本方案数据传输速度快，性能高，程序设计、实现都很简单，但用户每月都要支付价格不低的线路费用，这种方案比较适合那些经济实力比较雄厚的用户；二是采用电话线，用X.25通信协议，此方案数据传输速度稍慢，但也能满足用户需要，程序设计和实现要复杂许多，用户每月支付的线路费用将大幅度下降。

随着计算机网络技术的飞速发展，电子商务在流通领域的应用也越来越多。本MIS系统也准备在电子商务方面有所扩展，条件允许，可以实现网上订货、网上销售，甚至网上货币支付。

作为一个软件企业，应该不断地提取、积累自己的软件资源。不同开发平台的开发规范、商业类库、应用框架、构件、中间件等都是十分重要的软件资源，是软件公司的基础建设。因此，在设计、编码之前，要制订相应的开发规范，要组织开发、设计、管理一些类库和构件库。

软件产品是软件公司的财富来源，而软件的有效加密是保护公司产品、产权的有效手段，更是保障公司效益的有效途径。所以，还要考虑软件加密算法设计。

4．功能模块任务分配

根据研发中心商业软件部目前的人员情况，本系统的项目经理由商业软件部副经理亲自担任，负责整个系统的规划、设计、协调与实施；商业软件部主任工程师担任产品经理，负责项目的整体需求、数据库设计与Alpha测试。整个项目分为4个任务组，各个任务组组长在项目实施阶段，承担小项目经理职责。4个任务组的人数及开发任务，如表3-17所示。

表3-17  任务组的人数及开发任务

5．数据库与开发工具的选择

考虑到数据库的性能与价格比，数据库首选Sybase，其次是MS SQL Server。由于这两个数据库的天然联系，使得两个版本的程序设计的差异将十分微小。数据库设计工具采用PowerDesigner，程序开发工具选择为PowerBuilder 。某些PowerBuilder 不宜实现的功能，可由 VC++ 去完成。文档制作工具为Office 和PowerDesigner。

6．开发进度计划

研发中心商业软件部现有18人进入了本项目组。根据以往的实际工作经验，下面列出研发进度，如表3-18所示。

表3-18  进度计划（1999/04/01-1999/10/15）

7．评审计划

各里程碑的评审计划，如表3-19所示。

表3-19  里程碑评审计划

4《软件开发计划书》

1．引言（Introduction）

1.1 目的（Purpose）

本章提供整个软件开发计划的综述。主要是确定以下内容：

（1）软件生存周期的选取及裁剪。

（2）软件规范、方法和标准的选择。

（3）软件工作产品的规模估计。

（4）软件工作量和成本的估计。

（5）软件进度表的制定。

（6）软件风险的估计。

（7）软件项目培训计划。

1.2 范围（Scope）

说明该软件开发计划的范围，简要描述软件开发计划的内容。一般而言，对于一个较大的软件项目（工期6个人月以上），计划书包括如下内容：

（1）软件规模估计

（2）工作模块计划

（3）人力资源计划

（4）其他资源计划

（5）进度安排计划

（6）配置管理计划（可单独做一个计划）

（7）质量保证计划（可单独做一个计划）

1.3 术语定义（Terms Glossary）

将该软件开发计划中的术语、缩写词进行定义。包括用户应用领域与计算机领域的术语与缩写词等。例如：

[1] 软件相关组：指软件配置管理组、文档支持组、测试组。

[2] 软件质量保证组：指计划和实施软件质量保证活动的人员的集合。

1.4 参考资料（References）

说明该软件开发计划使用的参考资料，如项目的用户需求报告、商务合同、用户领域的资料等，每一个文件、文献要有标题、索引号或文件号，发布或发表日期以及出版单位。

[1] ……

[2] ……

1.5 相关文档（Related Documents）

当该文档变更时，可能对其他文档产生影响，受影响的文档叫相关文档，需将它们列出。

[1] ……

[2] ……

1.6 版本更新记录（Version Updated Record）

版本更新记录格式，如表4-8所示。

表4-8  版本更新记录

2．项目概述（Project Summary）

2.1 项目的目的（Project Purpose）

说明该软件项目的目的。

2.2 项目的范围（Project Scope）

本章的内容，主要参照《立项建议书》/《合同》与《用户需求报告》中相关章节，简要描述该软件项目的实现范围：

（1）主要功能点列表

（2）主要性能点列表

（3）主要接口列表

（4）本软件项目与其他软件项目之间的关系

（5）项目实施方面的限制等内容

2.3 项目的使用对象（Project Reader）

在本章节中，要识别出顾客与最终用户，对顾客与最终用户的情况要有简单描述，如最终用户的教育水平、技术水平及本系统的使用频度等。

3．项目组织（Project Organization）

项目组织是为开发项目而组建的队伍。建议以框图的方式表示项目的组织结构，并对每一组织的负责人和职责加以说明。可能的项目组织单元，如：

（1）项目管理组

（2）质量保证组

（3）配置管理组

（4）软件工程组

（5）测试组

（6）需求管理组

各组织说明如下：

（1）项目管理组，执行SPP和SPTO过程，对项目实施负全部责任。

（2）质量保证组，执行SQA过程，负责项目过程与产品的质量控制和报告。

（3）配置管理组，执行SCM过程，负责项目产品的版本、配置管理以及配置库状态报告。

（4）软件工程组，执行软件项目工程过程，负责项目产品的开发和维护工作。

（5）测试组，执行软件项目测试过程，负责项目产品的测试。

（6）需求管理组，负责对需求基线和需求变更进行管理。

4．软件生存周期（Software Life Cycle）

本章节记录项目策划生存期定义的工作结果，需要描述的主要内容：

（1）项目生存期框图

（2）项目生存期说明

5．规范、方法和标准（Criterion，Means，Standard）

本章节中需要描述采用的供开发和维护软件用的规范、方法和标准。

6．任务与工作产品（Task and Work Products）

项目任务和工作产品，是指根据项目生存期阶段划分的任务，和相应阶段的工作产品。记录项目生存期各阶段确定的需重点控制的阶段任务和工作产品。建议以表格的形式，列出生存期各阶段的任务和工作产品。项目包含的任务，如：

（1）需求分析

（2）系统设计

（3）系统实现

（4）测试

（5）产品交付

（6）产品维护

项目可能包含的产品，如：

（1）需求分析说明书

（2）规格分析说明书

（3）系统设计说明书

（4）源代码

（5）各种测试报告

（6）用户手册

（7）软件问题维护记录

7．工作产品、任务规模、工作量估计（Estimates of Work Product，Task Size and Workload）

项目规模估算是为了确定项目所需的人工。需要描述的主要内容有：

（1）对软件工作产品规模估计依据的简要描述。

（2）每种任务和工作产品规模估计的结果。

（3）规模估算的结果，建议用《任务规模和工作量估算表》的形式列出。

8．成本估计（Estimates of Costs）

成本估计，是指对项目完成过程中耗费的人力、物力、财力资源的估算。成本估计应按类别进行估算，可能的成本估算类别，如：

（1）直接人工

（2）直接费用

（3）间接成本

（4）制造费用

（5）管理费用

（6）不可预见费用

9．关键计算机资源计划（Critical Computer Resource Plan）

项目的关键计算机资源计划，是指系统在开发环境、测试环境、及用户目标环境中，对关键计算机资源，如计算机存储能力、计算机处理器速度、通信通道容量、服务器处理能力等的估计，使之能满足软件开发、测试、运行的要求。

10．软件项目进度计划（Software Project Schedule）

件项目进度计划，是对项目的进度、人员工作分工所做的计划，此计划依据上述各章的估算和分析结果，计划方式建议采用表格的形式。若采用工具制定项目计划，应将工具生成的图表作为项目计划的附件。本章节中需要描述的主要内容有：

（1）软件项目每个阶段的进度时间表

（2）设定的里程碑

（3）评审时间

（4）缓冲时间

11．配置管理计划（可单独做一个计划）（Configuration Management Planning）

本书单独作为一章论述。

12．质量保证计划（可单独做一个计划）（Software Quality Assurance Planning）

本书单独作为一章论述。

13．风险分析（Risks Analysis）

项目风险分析，是指对可能发生的将会对项目按预期时间、资源和预算完成产生重大影响的事件的分析包括：

（1）被识别出的重大风险事件：政策风险、技术风险、技能风险等。

（2）易发生重大风险事件的高风险区域：用户需求、设计、测试、运行平台等。

（3）重大风险事件的级别：功能不全、性能不稳、迅速受限制等。

（4）拟采取的预防措施：增加投入、纠错、延时等。

（5）风险事件发生后建议采用的处理措施：更改计划、降低难度系数等。

14．设备工具计划（Equipment and Tools Planning）

项目设备工具计划，是根据项目的工作指派及进度确定项目所需要的设备和工具，以确保设备工具在任务执行前到位，保证项目任务的顺利执行，在本计划中应包含以下几方面的内容：

（1）所需的设备

（2）基本的要求

（3）应到位的时间

15．培训计划（Training Planning）

项目的培训计划，应根据项目的特点和项目组成员技能情况，制定出项目组成员所需的培训内容，培训计划中应包含以下几方面：

（1）培训内容

（2）培训时间

（3）教员

（4）接受培训的人员

（5）培训目的（应达到的效果）

16．项目评审（Project Reviews）

项目评审，是对项目策划过程所做的定期性评审。其内容可分为：

（1）评审点

（2）评审周期

（3）评审层次

（4）评审条款和措施

（5）管理评审活动中提交的工作产品（列出被评审的工作产品）

17．度量（Measurement）

度量是按规定在项目进行过程中，需要采集的度量数据，以便量化地反映项目的进展情况，为管理者提供对项目进展的适当的可视性，同时度量数据是项目过程改善的数据基础。应规定项目度量值的记录人（一般为项目经理或其指定人员）、记录时间（一般以定期评审为基础）和记录的数据。常用的度量数据如：

（1）项目过程的评审次数

（2）项目计划修改次数

（3）项目各阶段的人员投入（各阶段投入的人月数）

（4）各类任务耗用时间统计（如设计、编码、测试、文档编写等）

5《用户需求报告》

1．概述（Summary）

本文档是进行需求规格定义、项目策划、概要设计的基础，也是用户进行验收的依据。

1.1 用户简介（User Synopsis）

在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围，进行关于功能、进度、成本、性能等方面的平衡决策。

对于产品开发类项目，需要在此将该产品定义的用户群的特点描述清楚。

1.2 项目的目的与目标（Purpose and Aim of Project）

项目的目的是对开发本系统意图的总概括。项目的目标是将目的细化后的具体描述。项目目标应是明确的、可度量的、可以达到的, 项目的范围应能确保项目的目标可以达到。

对于项目的目标可以逐步细化，以便与系统的需求建立对应关系，检查系统的功能是否覆盖了系统目标。

1.3 术语定义（Terms Glossary）

将该用户需求报告中的术语、缩写进行定义, 包括用户应用领域与计算机领域的术语与缩写等。

1.4 参考资料（References）

说明该用户需求报告使用的参考资料，如：

[1] 商务合同

[2] 招标书

[3] 用户领域的资料

[4] 用户需求调查表

[5] 参照的标准

每一个文件、文献要有标题、或文件号，发布或发表日期以及出版单位。

1.5 相关文档（Related Documents）

说明用户需求报告的变更，以及可能受变更影响的其他相关文档，如：

[1] 项目开发计划

[2] 需求规格说明书

1.6 版本更新信息（Version Updated Record）

版本更新记录格式，如表5-11所示。

表5-11  版本更新记录

2．现有系统描述（System in Existence）

2.1 组织结构与职责（Organizing Framework and Function）

将用户的组织结构逐层详细描述，建议采用树状的组织结构图进行表达，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围很有帮助。取得用户的组织结构，是需求获取步骤中的工作任务之一。

2.2 岗位定义（Role Definition）

用户环境中的企业岗位和组织结构一样，也是分析人员理解企业业务的基础，是需求获取的工作任务，同时也是分析人员提取对象的基础。每个岗位的职责可以进行详细的描述，建议采用表格的形式，如表5-12所示。

表5-12  岗 位 定 义

对用户岗位的识别，也包括使用了计算机系统后的系统管理人员岗位。

2.3 作业流程（Busywork Flow）

企业的作业流程，首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图、Use case图、程序流程图加上文字说明。

图形可以将流程描述得很清楚，但是还要附加一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述的内容，需要用文字进行详细描述。

2.4 单据、账本、报表（Bill of Document，Account and Report）

现行系统中用户正在使用的正式的或非正式的单据、账本、报表等可以收集起来，并进行穷举、分类、归纳。单据、账本、报表是用户系统中信息的载体，是进行系统需求分析的基础，无论采用哪种分析方法，这都是必不可少的信息源。

2.4.1 单据（Bill of Document）

单据的格式可用表格描述，如表5-13所示。

表5-13  单据的描述格式

各数据项的详细说明如下：

2.4.2 账本（Account）

因为账本上的数据是统计数据，所以一个账本一般对应一张中间表，账本的格式可用表格描述，如表5-14所示。

表5-14  账本的描述格式

各数据项的详细说明如下：

2.4.3 报表（Report）

因为报表上的数据是统计数据，所以一个报表一般对应一张中间表，报表的格式可用表格描述，如表5-15所示。

2.5 存在的问题（Existent Question）

在现行的系统中，决策层、管理层、操作层各存在哪些方面的问题需要计算机来解决，尤其是决策层、管理层这些问题中包含了用户的需求与期望，有些问题是新系统可以解决的，有些问题则不是。

表5-15  报表的描述格式

各数据项的详细说明如下：

2.6 可能的变化（Possible Change）

对于现行的系统，将来可能会有哪些变化，需要在此描述。企业中的变化是永恒的，系统分析员需要描述哪些变化可能引起系统范围变更。

3．目标系统功能需求（Function of Target System）

3.1 功能需求分析（Function Analysis）

决策层、管理层、操作层各有哪些具体功能要求。

3.2 功能需求点列表（Function List）

在功能需求分析完成后，要详细列出用户需求功能点列表，提供给后续设计、编程、测试中使用，更是为了用户测试验收中使用。功能需求点列表的格式，如表5-16所示。

表5-16  功能需求点列表

4．目标系统性能需求（Performance of Target System）

4.1 时间要求（Time Request）

如：

（1）响应时间，如查询的最长等待时间。

（2）更新处理时间，如记账的最长时间。

（3）数据的转换和传送时间，如远程数据传输的时间要求。

（4）解题时间。

4.2 空间要求（Space Request）

如：

（1）支持的终端数。

（2）支持的并行操作的使用者数。

（3）处理的文件和记录数。

（4）表和文件的大小规模（要按可预见的增长，对数据及其分量的存储要求做出估算）。

（5）处理任务的数量。

（6）在正常情况下和峰值工作条件下，在一定时间周期中要处理的数据总数。

（7）对输入和输出数据的精度要求。

（8）对处理和传输过程中的精度要求。

4.3 性能需求点列表（Performance List）

详细列出用户性能点列表，提供给后续分析、设计、编程、测试中使用，更是为了用户测试验收中使用。需求性能点列表的格式，如表5-17所示。

表5-17  性能需求点列表

5．目标系统界面与接口需求（Interface of Target System）

5.1 界面需求（Interphase Requirement）

界面的原则要求，如方便、简洁、美观、一致等。整个系统的界面风格定义，某些功能模块的特殊的界面要求。

（1）输入设备：键盘、鼠标、条码扫描器、扫描仪等；

（2）输出设备：显示器、打印机、光盘刻录机、磁带机、音箱等；

（3）显示风格：图形界面、字符界面、IE界面等；

（4）显示方式：1024*768、640*480等；

（5）输出格式：显示布局、打印格式等。

5.2 接口需求（Interface Requirement）

与其他系统的接口，如监控系统、控制系统、银行结算系统、税控系统、财务系统、政府网络系统及其他系统等。

（1）与系统特殊外设的接口，如CT机、磁共振、柜员机（ATM）、IC卡、盘点机等。

（2）与中间件的接口，要列出接口规范、入口参数、出口参数、传输频率等。

应在此列举出所有的外部接口名称、接口标准、规范。外部接口列表，如表5-18所示。

表5-18  外部接口需求点列表

6．目标系统其他需求（Other Requirements of Target System）

6.1 安全性（Security）

6.2 可靠性（Dependability）

6.3 灵活性（Agility）

6.4 特殊需求（Special requirements）

如：

（1）进度需求：系统的阶段进度要求。

（2）资金需求：投资额度。

（3）运行环境需求：平台、体系结构、设备要求。

（4）培训需求：用户对培训的需求，是否提供多媒体教学光盘。

（5）推广需求：推广的要求，如在上百个远程部门推广该系统，是否要有推广的支持软件。

7．目标系统假设与约束条件（Suppose and Restriction of Target System）

假设与约定条件是对预计的系统风险的描述, 如：

（1）法律、法规和政策方面的限制。

（2）硬件、软件、运行环境和开发环境方面的条件和限制。

（3）可利用的信息和资源。

（4）系统投入使用的最晚日期。

6《需求规格说明书》

1．概述（Summary）

本文档是进行项目策划、概要设计和详细设计的基础，也是软件企业测试部门进行内部验收测试的依据。

1.1 用户简介（User Synopsis）

在本章节中要将用户的基本情况描述清楚，以便于分析人员划定系统范围，进行功能、进度、成本、性能等方面的平衡决策。

对于产品开发类项目，需要在此将该产品定义的用户群的特点描述清楚。

1.2 项目的目的与目标（Purpose and Aim of Project）

项目的目的是对开发本系统的意图的总概括。项目的目标是将目的细化后的具体描述。项目目标应是明确的、可度量的、可以达到的, 项目的范围应能确保项目的目标可以达到。

对于项目的目标可以逐步细化，以便与系统的需求建立对应关系，检查系统的功能是否覆盖了系统的目标。

1.3 术语定义（Terms Glossary）

将该需求规格说明书中的术语、缩写进行定义, 包括用户应用领域与计算机领域的术语与缩写等。

1.4 参考资料（References）

说明该用户需求报告使用的参考资料，如：

[1] 商务合同

[2] 招标书

[3] 用户领域的资料

[4] 用户需求调查表

[5] 用户需求报告

[6] 参照的标准

每一个文件、文献要有标题、或文件号，发布或发表日期以及出版单位。

1.5 相关文档（Related Documents）

[1] 项目开发计划

[2] 概要设计说明书

[3] 详细设计说明书

1.6 版本更新信息（Version Updated Record）

版本更新记录格式，如表5-19所示。

表5-19  版本更新记录

2．目标系统描述（System in Target）

2.1 组织结构与职责（Organizing Framework and Function）

将目标系统的组织结构逐层详细描述，建议采用树状的组织结构图进行表达，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围很有帮助。取得用户的组织结构，是需求获取步骤中的工作任务之一。

2.2 角色定义（Role Definition）

用户环境中的企业角色，和组织机构一样，也是分析人员理解企业业务的基础，是需求获取的工作任务，同时也是分析人员提取对象的基础。每个角色的授权可以进行详细的描述，建议采用表格的形式，如表5-20所示。

表5-20  角 色 定 义

对用户角色的识别也包括使用了计算机系统后的系统管理人员。

2.3 作业流程（业务模型）（Busywork Flow）（Operation Model）

目标系统的作业流程是对现有系统作业流程的重组、优化与改进。企业的作业流程首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图、Use case图、其他示意图的形式。

图形可以将流程描述得很清楚，但是还要附加一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述的内容，需要用文字进行详细描述。

2.4 单据、账本、报表（Bill of Document，Account and Report）

目标系统中用户将使用的正式单据、账本、报表等，并进行穷举、分类、归纳。单据、账本、报表是用户系统中信息的载体，是进行系统需求分析的基础，无论采用哪种分析方法，这都是必不可少的信息源。

2.4.1 单据（Bill of Document）

因为单据上的数据是原始数据，所以一种单据一般对应一个实体，一个实体一般对应一张基本表。单据的格式可用表格描述，如表5-21所示。

表5-21  单据的描述格式

各数据项的详细说明如下：

2.4.2 账本（Account）

因为账本上的数据是统计数据，所以一个账本一般对应一张中间表，账本的格式可用表格描述，如表5-22所示。

表5-22  账本的描述格式

各数据项的详细说明如下：

2.4.3 报表（Report）

因为报表上的数据是统计数据，所以一个报表一般对应一张中间表，报表的格式可用表格描述，如表5-23所示。

表5-23  报表的描述格式

各数据项的详细说明如下：

2.5 可能的变化（Possible Change）

对于目标系统，将来可能会有哪些变化，需要在此描述。企业中的变化是永恒的，系统分析员需要描述哪些变化可能引起系统范围变更。

3．目标系统功能需求（Function of Target System）

3.1 功能需求分析（Function Analysis）

决策层、管理层、操作层各有哪些具体功能要求。

3.2 功能需求点列表（功能模型）（Function List）（Function Model）

在功能需求分析完成后，要详细列出用户需求功能点列表，提供给续设计、编程、测试中使用，更是为了用户测试验收中使用。需求功能点列表的格式，如表5-24所示。

表5-24  功能需求点列表

4．目标系统性能需求（Performance of Target System）

4.1 时间要求（Time Request）

如：

（1）响应时间，如查询的最长等待时间。

（2）更新处理时间，如记账的最长时间。

（3）数据的转换和传送时间，如远程数据传输的时间要求。

（4）解题时间。

4.2 空间性能（Space Request）

如：

（1）支持的终端数。

（2）支持的并行操作的使用者数。

（3）处理的文件和记录数。

（4）表和文件的大小规模（要按可预见的增长，对数据及其分量的存储要求做出估算）。

（5）处理任务的数量。

（6）在正常情况下和峰值工作条件下，在一定时间周期中要处理的数据总数。

（7）对输入和输出数据的精度要求。

（8）对处理和传输过程中的精度要求。

4.3 性能需求点列表（性能模型）（Performance List）（Performance Model）

详细列出用户性能点列表，提供给后续分析、设计、编程、测试中使用，更是为了用户测试验收中使用。需求性能点列表的格式，如表5-25所示。

表5-25  性能需求点列表

5．目标系统界面与接口需求（Interface of Target System）

5.1 界面需求（Interphase Requirement）

界面的原则要求，如方便、简洁、美观、一致等。整个系统的界面风格定义，某些功能模块的特殊的界面要求。

（1）输入设备：键盘、鼠标、条码扫描器、扫描仪等；

（2）输出设备：显示器、打印机、光盘刻录机、磁带机、音箱等；

（3）显示风格：图形界面、字符界面、IE界面等；

（4）显示方式：1024×768、640×480等；

（5）输出格式：显示布局、打印格式等。

5.2 接口需求点列表（接口模型）（Interface Requirement）（Interface Model）

（1）与其他系统的接口，如监控系统、控制系统、银行结算系统、税控系统、财务系统、政府网络系统及其他系统等。

（2）与系统特殊外设的接口，如CT机、磁共振、柜员机（ATM）、IC卡、盘点机等。

（3）与中间件的接口，要列出接口规范、入口参数、出口参数、传输频率等。

应在此列举出所有的外部接口名称、接口标准、规范。外部接口列表，如表5-26所示。

表5-26  接口需求点列表

6．目标系统其他需求（Oher Requirement of Target System）

6.1 安全性（Security）

6.2 可靠性（Dependability）

6.3 灵活性（Agility）

6.4 特殊需求（Special Requirement）

如：

（1）进度需求：系统的阶段进度要求。

（2）资金需求：投资额度。

（3）运行环境需求：平台、体系结构、设备要求。

（4）培训需求：用户对培训的需求，是否提供多媒体教学光盘。

（5）推广需求：推广的要求，如在上百个远程的部门推广该系统，是否要有推广的支持软件。

7．目标系统假设与约束条件（Suppose and Restriction of Target System）

假设与约定条件是对预计的系统风险的描述,如：

（1）法律、法规和政策方面的限制。

（2）硬件、软件、运行环境和开发环境方面的条件和限制。

（3）可利用的信息和资源。

（4）系统投入使用的最晚时间。

7《需求报告 / 需求规格说明书评审记录表》

《用户需求报告 / 需求规格说明书评审记录表》

（Review Table of Requirements）

              评审组长签字：                   评审组成员签字：

表5-28 《需求变更管理表》

（Modification Table of Requirements）

                    申请人：                   审批人：

8“图书馆信息系统”

“图书馆信息系统”的概念数据模型CDM（见图6-10）和物理数据模型PDM（见图6-11）分析。

首先，介绍一下在E-R图中实体的表示法，如图6-10所示。一个矩形框表示一个实体，框内第一部分（第一行）的文字表示该实体的名称，如“图书”。第二部分表示该实体的多个属性，每个属性占一行，如“图书号、书名、单价、作者”等。带下划线的属性为主关键字，即主键PK（或主码），如“图书号”。两个实体之间的关系，用一条连线表示。关系有三种：一对一关系，就是一条连线；一对多关系，多的一端是一个三叉线（ERwin工具中为一个黑色小圆球）；多对多关系，两端都是三叉线。连线的一端若有一个小圆圈，则表示非强制型的关系；连线的一端若有一个小十字架，则表示强制型的关系。

图6-10  “图书馆信息系统”的概念数据模型CDM

系统的E-R图又称为系统的概念数据模型CDM，有了它以后，利用PowerDesigner工具，就能自动生成物理数据模型PDM。

首先分析“图书馆信息系统”的概念数据模型CDM，如图6-10所示。因为图书馆的主要功能不外乎两点，藏书与为读者服务。其他许多功能都是围绕这两项功能而展开的。所以“图书馆信息系统”的主要实体是“图书”和“读者”。

“图书”的属性有图书号、书名、作者、出版社、单价等，“读者”的属性有读者号、姓名、电话等。

由于一本图书可以被多个读者在不同时间借阅，一名读者又可以一次或多次借阅多本图书，所以该两个实体之间是多对多的关系。为了消除这个多对多关系，在两者之间插入第3个实体，该实体取名为“借还书”。“借还书”至少有两个属性：借书还书时间、借书还书标志。另外，它还有两个外键，图书号和读者号。当增加“借还书”这个实体之后，原来一个多对多的关系，现在变为两个一对多的关系：“图书”对“借还书”，“读者”对“借还书”。 “图书馆信息系统”中还有许多其他实体，它们都是围绕这3个主要实体及其关系而展开的。这3个实体是“图书馆信息系统”的核心。例如，“书库”和“单位”这两个实体，就是分别围绕“图书”和“读者”而展开的。“书库”表示图书存放在什么地方，以及该书是否借出，即该本书的架位号、架位地址，以及借出标志位的状态。由于一个架位号上可放多本书，所以“书库”和“图书”是一对多的关系。同样，“单位”表示读者在什么单位，即该读者的单位名称、单位地址和单位电话等，由于一个单位可有多个读者，所以“单位”和“读者”是一对多的关系。以上实体、属性、关系如图6-10所示。

图6-11  “图书馆信息系统”的物理数据模型PDM

9《概要设计说明书》

1．导言（Introduction）

本章对该文档的目的、功能范围、术语、相关文档、参考资料、版本更新进行说明。

1.1 目的（Purpose）

本文档的目旨在推动软件工程的规范化，使设计人员遵循统一的概要设计书写规范，节省制作文档的时间，降低系统实现的风险，做到系统设计资料的规范性与全面性，以利于系统的实现、测试、维护、版本升级等。

1.2 范围（Scope）

本文档用于软件设计阶段的概要设计，它的上游（依据的基线）是《需求分析规格书》，它的下游是《详细设计说明书》，并为《详细设计说明书》提供测试的依据。

软件概要设计的范围是：软件系统总体结构设计、全局数据库和数据结构设计、外部接口设计、主要部件功能分配设计、部件之间的接口设计等方面的内容。该范围应覆盖《需求规格说明书》中的功能点列表、性能点列表、接口列表。

1.3 命名规则（Naming Rule）

变量对象命名规则：申明全局变量、局部变量对象的命名规则。

数据库对象命名规则：申明数据库表名、字段名、索引名、视图名等对象的命名规则。

1.4 术语定义（Terms Glossary）

术语定义或解释一般用表格形式给出，如表6-5所示。

表6-5  术语定义或解释表

1.5 参考资料（References）

[1] 用户需求报告

[2] 软件开发合同

[3] 数据库设计规范

[4] 命名规范

1.6 相关文档（Related Documents）

[1] 《详细设计说明书》

[2] 源程序清单

[3] 测试计划及报告

[4] 《用户使用手册》

1.7 版本更新记录（Version Updated Record）

版本更新记录格式，如表6-6所示。

表6-6  版本更新记录

2．总体设计（Design of Collective）

2.1 总体结构设计（Design of Collective Structure）

软件系统的总体逻辑结构，按照不同的设计方法，有不同的总体逻辑结构。本指南以结构化设计方法为主，画出系统总体结构图，列出系统的功能模块清单编号、名称、功能，并尽可能描绘出功能模块之间的关系。若用面向对象的Rose工具进行分析和设计，则遵照Rose的要求进行。

总体结构示意图，如图6-13所示。

图6-13  总体结构示意图

2.2 运行环境设计（Design of Running Environment）

该软件系统的运行环境：

硬件平台：

（1）服务器的最低配置要求

（2）工作站的最低配置要求

（3）外设的要求

软件平台：

（1）服务器操作系统

（2）数据库管理系统

（3）中间件

（4）客户端的操作系统

（5）客户端的平台软件

网络平台：

（1）通信协议

（2）通信带宽

2.3 子系统清单（Subsystem List）

子系统清单，如表6-7所示。

表6-7  子系统清单

2.4 功能模块清单（Function Module List）

功能模块清单，如表6-8所示。

表6-8  功能模块清单

3．模块（部件）功能分配（Functional Distribution of Module）

具有功能独立、能被调用的信息单元叫做模块。模块是结构化设计中的概念，部件是面向对象设计中的概念。

模块功能分配的目的，就是为了将具有相同功能的模块合并，从中提取公用模块，形成公用部件，按照构件或中间件的方式加以实现，作为本系统的公用资源，甚至作为公司级组织的公用资源，从而充实公司级的构件库或中间件库，优化系统设计，加快开发速度，提高开发质量。

3.1 专用模块功能分配（Functional Distribution of Expert Module）

专用模块功能分配，如表6-9所示。

表6-9  专用模块功能分配

3.2 公用模块功能分配（Function Distribute of Public Module）

公用模块功能分，如表6-10所示。

表6-10  公用模块功能分配

4．数据结构设计（Design of Data Structure）

数据库设计的工具目前主要有3个：ERwin，PowerDesigner，OracleDesigner。后面两种工具都支持中文的概念数据模型设计，并能自动将概念数据模型转换为物理数据模型，自动生成建表程序和主键索引程序。前面一种工具只能支持英文的物理数据模型设计。3个工具的共同特点是都能生成E-R图及其相应的数据字典。

4.1 数据库表名清单（DB Table List）

数据库表名清单，如表6-11所示。

表6-11  数据库表名清单

4.2 数据库表之间关系说明（Relation of DB Table）

可以用E-R图表示，也可以用文字说明。

4.3 数据库表的详细清单（Particular List of DB Table）

每个表的详细清单内容包括：表名、字段中文名、字段英文名、字段的类型、宽度、精度、主键/外键、空否、取值约束（默认值、最大值、最小值）、索引否。同时要指出该表的索引：索引文件名、索引字段名、索引特性（主键索引、惟一索引unique、聚集索引clustered）。详细清单可以用列表给出，如表6-12所示。

表6-12  表名：XXXX

4.4 视图设计（View Design）

视图设计与授权有关，设计时参照需求文档的用户授权范围。视图设计中要给出视图的中文名、英文名，视图中的中文列名、英文列名、类型、宽度、精度，每一列的具体算法，对应的基本表名。

4.5 其他数据结构设计（Design of Other Data Structure）

此小节描述系统的其他数据结构设计内容。

5．接口设计（Interface Design）

对应每一个接口，都要详细列出下列内容。

（1）接口名称

（2）接口内容

（3）接口设施

（4）接口的数据结构

（5）接口的传输速率（Mbps）

（6）接口带宽

（7）接口协议

6．其他设计（Other Design）

本章描述前面没有说明的设计。

7．设计检查列表（Check-up List of Design）

按照需求文档的功能、性能和接口3个列表，设计出概要设计检查列表，以检查概要设计是否覆盖需求分析，没有覆盖就是不符合项，并将检查结果列出。

7.1 功能设计检查列表（Check-up List of Function Design）

功能设计检查列表，如表6-13所示。

表6-13  功能设计检查列表

7.2 性能设计检查列表（Check-up List of Performance Design）

性能设计检查列表，如表6-14所示。

表6-14  性能设计检查列表

7.3 接口设计检查列表（Check-up List of Interface Design）

接口设计检查列表，如表6-15所示。

表6-15  接口设计检查列表

10《详细设计说明书》

1．导言（Introduction）

本章对该文档的目的、功能范围、术语、相关文档、参考资料、版本更新进行说明。

1.1 目的（Purpose）

本文档的目旨在推动软件工程的规范化，使设计人员遵循统一的详细设计书写规范，节省制作文档的时间，降低系统实现的风险，做到系统设计资料的规范性与全面性，以利于系统的实现、测试、维护、版本升级等。详细设计的详细程度，应达到可以编写程序的程度。

1.2 范围（Scope）

本文档用于软件设计阶段的详细设计，它的上游（依据的基线）是《概要设计说明书》，它的下游是源程序清单及单元测试计划，并为单元测试报告提供测试依据。该范围应覆盖《概要设计说明书》中的功能点列表、性能点列表、接口列表。

软件详细设计的范围是：各子系统的公用模块实现设计、专用模块实现设计、存储过程实现设计、触发器实现设计、外部接口实现设计、部门角色授权设计、其他详细设计等。

按照3层结构（B/A/S）的布局，详细设计应从下面3个方面进行。数据库服务器上的面向数据的设计：数据字典物理设计、基本表物理设计、中间表物理设计（报表设计）、临时表物理设计、视图物理设计、存储过程物理设计、触发器物理设计。应用服务器上的面向业务逻辑的设计：接口数据设计、中间件设计、数据通信传输设计、可视构件设计、非可视构件设计、角色授权设计、功能点设计（功能点列表设计）。浏览器上的面向对象的设计：录入修改界面设计、浏览查询界面设计、登录注册界面设计、信息发布界面设计。

1.3 术语定义（Terms Glossary）

术语定义，如表6-16所示。

表6-16  术语定义

1.4 参考资料（References）

[1] 《概要设计说明书》

[2] 《需求分析说明书》

[3] 《软件合同》

[4] 命名规范

[5] 程序设计规范

[6] 界面设计规范

1.5 相关文档（Related Documents）

[1] 源程序清单

[2] 单元测试计划及报告

[3] 《用户使用手册》

1.6 版本更新记录（Version Updated Rcord）

版本更新记录，如表6-17所示。

表6-17  版本更新记录

2．模块实现设计（Implemental Design of Module）

功能模块包括：登录注册模块、信息发布模块、菜单模块、录入修改模块、查询统计模块、数据处理模块、报表输出模块、前台网站模块、后台处理模块、数据传输与接收模块等等。详细设计是面向模块的，或者说是面向部件（或构件）的，不是面向组织结构或部门单位的。一个组织或单位，根据角色的授权，可以挂上某些功能模块。若为C/S或B/A/S结构，则要说明该模块运行在哪一层上。

2.1 公用模块设计（Design of Public Module）

公用模块的提取与设计特别重要，设计它的目的是为了复用，因此它直接影响到系统的详细设计、编程、运行的质量。每个公用模块的设计要包括如下内容：

（1）模块编号：按照命名规则，如：G-XXX，将此公用模块编号写上。

（2）模块名称：此公用模块的英文名。

（3）模块功能：详细列出此公用模块的所有功能。

（4）模块背景描述：对背景进行简单的描述。为什么需要此模块功能，其上下文环境。涉及业务背景内容，与需求相结合。

（5）模块算法设计：用伪语言（例如，if…endif，case…endcase， do…enddo，…）详细描述出此公用模块的算法，标准是使程序人员据此能顺利地书写程序。

（6）模块调用方法：详细列出调用的方式、入口参数、出口参数、异常处理。

（7）模块编写者：编写者姓名。

（8）模块编写日期：编写日期：yyyy/mm/dd。

（9）模块修订者：修订者姓名。

（10）模块修订日期：修订日期：yyyy/mm/dd。

（11）模块测试者：测试者姓名。

（12）模块测试日期：测试日期：yyyy/mm/dd。

2.2 专用模块设计（Design of Expert Module）

非公用模块是为了处理一些特殊需求，它不可复用，每个非公用模块设计包括如下内容：

（1）模块编号：按照命名规则，如：M1-XXX，将此专用模块编号写上。

（2）模块名称：此模块的中文名。

（3）模块功能：详细列出此模块的所有功能。

（4）模块背景描述：对背景进行简单的描述。为什么需要此模块功能，其上下文环境。涉及业务背景内容，与需求相结合。

（5）模块算法设计：用伪语言（例如，if…endif，case…endcase， do…enddo，…）详细描述出此专用模块的算法，标准是使程序人员据此能顺利地书写程序。

（6）模块编写者：编写者姓名。

（7）模块编写日期：编写日期：yyyy/mm/dd。

（8）模块修订者：修订者姓名。

（9）模块修订日期：修订日期：yyyy/mm/dd。

（10）模块测试者：测试者姓名。

（11）模块测试日期：测试日期：yyyy/mm/dd。

2.3 存储过程设计（Design of Storage Process）

存储过程是一种特殊的公用模块，它在数据库服务器上执行，这里将它单独列出来，规定其详细设计模板为：

（1）存储过程中文名：此存储过程的中文名。

（2）存储过程英文名：此存储过程的英文名。

（3）存储过程功能: 详细描述其功能。

（4）存储过程算法: 用伪语言详细描述其算法，使编程人员据此能顺利书写程序。

（5）存储过程调用方式：详细列出调用的方式、入口参数、出口参数、异常处理。

（6）模块编写者：编写者姓名。

（7）模块编写日期：编写日期：yyyy/mm/dd。

（8）模块修订者：修订者姓名。

（9）模块修订日期：修订日期：yyyy/mm/dd。

（10）模块测试者：测试者姓名。

（11）模块测试日期：测试日期：yyyy/mm/dd。

2.4 触发器设计（Design of Trigger）

触发器也是一种公用模块，不过它是隐式执行，这里将它单独列出来，规定其详细设计模板为：

（1）触发器中文名：此触发器的中文名。

（2）触发器英文名：此触发器的英文名。

（3）触发器功能：详细描述其功能。

（4）触发器算法：用伪语言详细描述其算法，使编程人员据此能顺利书写程序。

（5）触发器激活条件：详细描述其激活条件，使编辑人员据此能顺利书写程序。

（6）触发器编写者：编写者姓名。

（7）触发器编写日期：编写日期：yyyy/mm/dd。

（8）触发器修订者：修订者姓名。

（9）触发器修订日期：修订日期：yyyy/mm/dd。

（10）触发器测试者：测试者姓名。

（11）触发器测试日期：测试日期：yyyy/mm/dd。

注意：过多地使用触发器反而会使系统的效率降低。因此，凡是能用存储过程代替触发器功能的地方，一律用存储过程来实现。

3. 接口实现设计（Implemental Design of Interface）

每个外部接口实现模块的设计要包括如下内容：

（1）接口中文名称：此接口的中文名。

（2）接口英文名称：此接口的英文名。

（3）接口内容与功能：详细描述接口的内容与功能，如实现数据传输或数据交换。

（4）接口硬件设施：详细描述接口的硬件设施，如交换机、传感器或输出设备。

（5）接口软件或中间件：详细描述接口软件或中间件的名称、功能、使用方法、生产厂商。

（6）接口的数据结构：详细描述接口的数据结构，如文件结构、数据库表结构。

（7）接口的传输速率（Mbps）：定量说明每秒最大流量。

（8）接口带宽：定量说明带宽，如XXMbps。

（9）接口协议：说明具体协议。

（10）接口程序的算法：用伪语言详细描述其算法，使编码人员据此能顺利书写程序。

（11）接口编写者：编写者姓名。

（12）接口编写日期：编写日期：yyyy/mm/dd。

（13）接口修订者：修订者姓名。

（14）接口修订日期：修订日期：yyyy/mm/dd。

（15）接口测试者：测试者姓名。

（16）接口测试日期：测试日期：yyyy/mm/dd。

4．其他实现设计（Other Implemental Designs）

本章描述前面没有说明的设计。如部门角色授权设计、界面设计、包装设计、维护设计等。

4.1 角色授权设计（Accredited Design of Role）

授权表的横坐标表示角色（部件、单位或岗位），纵坐标表示功能模块，“●”表示授权。该授权表是工作站上菜单设计的依据，如表6-18所示。

表6-18  角色授权设计

4.2 其他详细设计（Other Particular Designs）

根据需要进行设计。如界面设计、包装设计、维护设计等。

5．详细设计检查列表（Check-up List of Design）

按照概要设计文档的功能、性能和接口3个列表，设计出详细设计检查列表，以检查详细设计是否覆盖概要，没有覆盖就是不符合项，并将检查结果列出。

5.1 功能设计检查列表（Check-up List of Function Design）

功能设计检查列表，如表6-19所示。

表6-19  功能设计检查列表

5.2 性能设计检查列表（Check-up List of Performance Design）

性能设计检查列表，如表6-20所示。

表6-20  性能设计检查列表

5.3 接口设计检查列表（Check-up List of Interface Design）

接口设计检查列表，如表6-21所示。

表6-21  接口设计检查列表

《概要设计说明书/详细设计说明书评审记录表》

（Review Table of Design）

评审组长签字：                   评审组成员签字：

11《用户使用手册》

1．前言(Preface)

提供手册的概述，在此可以说明编写这份手册的目的、指明本手册的读者。

1.1 内容简介(Introduction)

简单地介绍编写背景，系统适用的用户。

1.2 基本概念(Basic Concept)

说明定义的术语在本手册中的含义。

1.3 主要功能(Mostly Function)

对系统进行简单讲解和功能介绍。

1.4 操作流程(Operate Flow)

操作流程说明。全面模拟用户操作，从安装、进入、初始化、到用户具体操作，对整个流程进行描述。

1.5 步骤说明(Step Show)

针对操作流程的每一步进行说明。如果在使用说明中有相应的解释，应指明用户查找的位置。

2．功能(Function)

这部分包括用户使用的所有功能，是用户使用手册的最重要的部分，要详细描述。

2.1 使用流程(Use Flow)

描述具体功能的使用顺序。如果功能之中有分类，比如，有些功能用户用不到，有些用得到，就要分开写流程。

2.2 具体描述(Description)

描述顺序是按照使用流程的每一步进行的。

2.3 进行此功能的业务介绍(Operation Introduce)

对此功能进行简单介绍，说明所能完成的功能。

2.4 操作步骤(Handle Step)

用鼠标选择相应的功能，进入相应的界面，进行功能键以及栏目的介绍。

2.5 举例(Example)

针对某一功能，对于一些比较难的问题，应该进行举例说明。

2.6 特殊提示及注意事项(Prompt and Notice)

在使用说明中，每一部分都会归纳一些问题，需要提示用户或者让用户注意，应按照以下规定的格式进行编写：字体采用仿宋字，字号采用小五号字。