⽬录
1. 范围.... 12. 总体要求.... 12.1 总体功能要求... 12.2 软件开发平台要求... 1
2.3 软件项⽬的开发实施过程管理要求... 22.3.1 软件项⽬实施过程总体要求... 22.3.2 软件项⽬实施变更要求... 22.3.3 软件项⽬实施⾥程碑控制... 23. 软件开发.... 33.1 软件的需求分析... 33.1.1 需求分析... 3
3.1.2 需求分析报告的编制者... 43.1.3 需求报告评审... 43.1.4 需求报告格式... 43.2 软件的概要设计... 43.2.1 概要设计... 4
3.2.2 编写概要设计的要求... 43.2.3 概要设计报告的编写者... 4
3.2.4 概要设计和需求分析、详细设计之间的关系和区别... 43.2.5 概要设计的评审... 43.2.6 概要设计格式... 43.3 软件的详细设计... 53.3.1 详细设计... 53.3.2 特例... 5
3.3.3 详细设计的要求... 53.3.4 数据库设计... 53.3.5 详细设计的评审... 53.3.6 详细设计格式... 53.4 软件的编码... 53.4.1 软件编码... 53.4.2 软件编码的要求... 53.4.3 编码的评审... 63.4.4 编程规范及要求... 6
3.5 软件的测试... 63.5.1 软件测试... 63.5.2 测试计划... 63.6 软件的交付准备... 63.6.1 交付清单... 63.7 软件的鉴定验收... 73.7.1 软件的鉴定验收... 73.7.2 验收⼈员... 73.7.3 验收具体内容... 73.7.4 软件验收测试⼤纲... 73.8 培训... 7
3.8.1 系统应⽤培训... 7
3.8.2 系统管理的培训（可选）... 8.... 9.... 21.... 33.... 43..... 55
1. 范围
本指南⽤于指导软件开发者为南京市交通局开发软件项⽬的过程，通过规范软件项⽬承担单位的开发过程达到提⾼软件质量，降低维护成本的⽬的。开发者应根据本指南进⾏软件开发和编制软件开发⽂档。本指南是对软件项⽬承担单位的基本要求。在本指南的附录A⾄E中提供了⽂档的编写模板供开发者参考，在进⾏具体软件开发时，开发者可根据实际情况采编写，但必须提供双⽅约定的⽂档，⽂档中约定的内容必须描述清楚。
2. 总体要求
2.1 总体功能要求
⽹络应⽤环境以Internet/Intranet技术为核⼼。
开发者应在充分分析需求的基础上，选择采⽤B/S结构或者C/S结构。
软件系统的数据库应依照《南京市交通局信息化数据库建设规范》进⾏设计和建设。
本指南中没有规定开发者采⽤何种具体的软件⼯程开发⽅法，开发者可根据项⽬具体特点、⾃⾝擅长来选择采⽤⾯向过程的⽅法、⾯向对象的⽅法或⾯向数据的⽅法，但建议开发 商使⽤⾯向对象软件⼯程的⽅法，如：采⽤⽬前被⼴泛使⽤的RUP(Rational Unified Process)⽅法来进⾏分析、设计和开发。
2.2 软件开发平台要求
开发者开发的软件必须能够在南京市交通局规定的软件平台上正常运⾏。⽬前软件平台为：数据库管理系统：Oracle 9i以上版本
中间件(应⽤服务器)系统：IBM WebSphereOA系统：
Lotus Domino/Notes⽹络架构：
完全⽀持TCP/IP协议开发⼯具或技术体系：
为保证软件的上下兼容性，开发者应选择⽐较通⽤的开发⼯具的较新版本进⾏开发，如Microsoft Visual Studio.Net，Borland Delphi，C++Builder, 或J2EE(Java2 P1atform Enterprise Edition)等。
2.3 软件项⽬的开发实施过程管理要求
2.3.1 软件项⽬实施过程总体要求
（⼀）开发者提交软件开发⼯作⼤纲，交通局组织专家组对⼯作⼤纲进⾏评审，并提出整改意见。
（⼆）通过评审后，开发者根据整改意见完善⼯作⼤纲，经过交通局认可后组织项⽬组进⾏软件开发。软件开发⼯作按照需求分析、概要设计、详细设计、编码、测试等⼏个阶段进⾏，在开发过程中，开发者需分阶段提交相关⽂档。
（三）在软件开发⼯作完成后，开发者应向交通局提交完整的软件⽂档，交通局组织验收组对软件进⾏验收审查。
2.3.2 软件项⽬实施变更要求
在开发过程中，需求或设计不可避免地需要发⽣变更，相关变更必须经过交通局书⾯同 意⽅可进⾏。在需求或设计发⽣变更时，需要对原有⽂档进⾏修改，并提供完整的变更记录， 以使变更处于可控制的状态。变更单如下表所⽰：
表 2-1 变更单
需求变更申请
输⼊名称，版本，⽇期等信息 变更申请的审批意见
审批意见： 签字 ⽇期 审批意见： 签字 ⽇期
更改需求⽂档变更后的需求⽂档更改⼈签字
需求评审⼩组签字
变更结束
项⽬经理签字
输⼊名称，版本，完成⽇期等信息 重新评审需求⽂档
评审意见： 签字 ⽇期 签字 ⽇期
申请变更的需求⽂档变更的内客及其理由评估需求变更将对项⽬造成的影响申请⼈签字 项⽬经理签字
客户签字(合同项⽬)
2.3.3 软件项⽬实施⾥程碑控制
交通局将分四个阶段进⾏把关，召开专家审查会。
（⼀） 需求分析（结合原型进⾏审查）确认； （⼆） 概要设计+数据库设计； （三） 预验收（试运⾏后）； （四） 正式验收（推⼴使⽤后）。
3. 软件开发
合同签订以后，项⽬承担单位即可组织项⽬组进⾏软件开发⼯作。软件开发必须严格按照软件⼯程的要求进⾏。开发过程包括开发者的活动和任务。此过程由软件需求分析、概要设计、详细设计、编码、测试、验收、鉴定等活动组成。
3.1 软件的需求分析
3.1.1 需求分析
⾸先，开发者和交通局应共同对交通局的应⽤需求作充分的调研，提交完整的需求分析 报告。在需求分析报告中必须描述的基本问题是：功能、性能、强加于实现的设计、属 性、外部接⼝。应当避免把设计或项⽬需求写⼊需求分析报告中。它必须说明由软件获得的 结果，⽽不是获得这些结果的⼿段。
软件需求可以⽤若⼲种⽅法来表达，如通过输⼊、输出说明；使⽤代表性的例⼦；⽤规范化的模型。开发者应尽可能地使⽤模型的⽅式，因为这是表达复杂需求的精确和有效的⽅法。⽐如⽤统⼀建模语⾔（UML）来描述需求。编写需求分析报告的要求a．⽆歧义性
对最终产品的每⼀个特性⽤某⼀术语描述；若某⼀术语在某⼀特殊的⾏⽂中使⽤时具有多种含义，那么应对该术语的每种含义做出解释并指出其适⽤场合。b．完整性
需求分析报告应该包括全部有意义的需求，⽆论是关系到功能的、性能的、设计约束的、还是关系到外部接⼝⽅⾯的需求；对所有可能出现的输⼊数据的响应予以定义，要对合法和⾮合法的输⼊值的响应做出规定；填写全部插图、表、图⽰标记等；定义全部术语和度量单位。c．可验证性
需求分析报告描述的每⼀个需求应是可以验证的。可以通过⼀个有限处理过程来检查软件产品是否满⾜需求。d．⼀致性
在需求分析报告中的各个需求的描述不能互相⽭盾。e．可修改性
需求分析报告应具有⼀个有条不紊、易于使⽤的内容组织；没有冗余，即同⼀需求不能在需求分析报告中出现多次。f．可追踪性
每⼀个需求的源流必须清晰，在进⼀步产⽣和改变⽂件编制时，可以⽅便地引证每⼀个需求。g．运⾏和维护阶段的可使⽤性
需求分析报告必须满⾜运⾏和维护阶段的需要。在需求分析报告要写明功能的来源和⽬的。
3.1.2 需求分析报告的编制者
需求分析报告应由交通局和开发者双⽅共同完成。其中：交通局负责根据实际需要提出希望软件实现的功能；软件开发者根据交通局提出的性能需求，结合软件开发编写需求分析。
3.1.3 需求报告评审
在软件需求分析⼯作完成后，软件开发者应向交通局提交《软件需求分析报告》。交通局组织有关⼈员对需求进⾏评审，以决定软件需求是否完善和恰当。评审完成后，就可以进⼊软件的设计阶段。
3.1.4 需求报告格式
《软件需求分析报告》需按⼀定的格式进⾏编写，具体的《软件需求分析报告》⽂档编写模板请见附录A。
3.2 软件的概要设计
3.2.1 概要设计
在交通局和开发者双⽅认可的《需求分析报告》基础上，开发者进⾏下——步的⼯作。 ⾸先，开发者需要对软件系统进⾏概要设计，即系统设计。概要设计需要对软件系统的设计 进⾏考虑，包括系统的基本处理流程、系统的组织结构、模块划分、功能分配、接⼝设计、 运⾏设计、数据结构设计和出错处理设计等，为软件的详细设计提供基础。
3.2.2 编写概要设计的要求
a．⼀致性
概要设计的要求应该与需求分析报告所描述的需求⼀致。同时，概要设计的各项要求之间也应该⼀致。b．合理性
概要设计所提出的设计⽅法和标准应该是合理的、恰当的。c．可追踪性
对概要设计所提出的各项要求应该可以得到它的清晰的源流，即在需求分析报告客户有明确的需求描述。d．可⾏性
根据概要设计进⾏详细设计、操作和维护应该是可⾏的。
3.2.3 概要设计报告的编写者
概要设计报告由开发者根据需求分析报告的要求进⾏编写。
3.2.4 概要设计和需求分析、详细设计之间的关系和区别
需求分析不涉及具体的技术实现，⽽概要设计注重于从宏观上和框架上来描述采⽤何种技术⼿段、⽅法来实现这些需求。详细设计相对概要设计更注重于微观上和框架内的设计， 是编码的依据。概要设计是指导详细设计的依据。
3.2.5 概要设计的评审
在软件概要设计⼯作完成后，软件开发者应向交通提交《软件系统概要设计报告》。在交通局对《概要设计报告》评审通过后，即可进⼊详细设计阶段。
3.2.6 概要设计格式
《软件系统概要设计报告》需按⼀定的格式进⾏编写，具体的《软件系统概要设计报 告》⽂档编写模板请见附录B。
3.3 软件的详细设计
3.3.1 详细设计
在概要设计的基础上，开发者需要进⾏软件系统的详细设计。在详细设计中，描述实 现具体模块所涉及到的主要算法、数据结构、类的层次结构及调⽤关系，需要说明软件系统各个层次中的每⼀个程序(每个模块或⼦程序)的设计考虑，以便进⾏编码和测试。应当保证 软件的需求完全分配给整个软件。详细设计应当⾜够详细，能够根据详细设计报告进⾏编码。
3.3.2 特例
如果软件系统⽐较简单，层次较少，可以不必进⾏专门的详细设计，⽽和概要设计结合起来。
3.3.3 详细设计的要求
a．⼀致性
详细设计的要求应该与需求分析报告所描述的需求、与概要设计⼀致。同时，详细设计的各项要求之间也应该是⼀致的。b．合理性
详细设计所提出的设计⽅法和标准应该是合理的、恰当的。c．可追踪性
对详细设计所提出的各项要求应该可以得到它的清晰的源流，即可在需求分析报告、概要设计报告中有明确的需求描述。d．可⾏性
根据详细设计进⾏编码、测试、操作和维护应该是可⾏的。
3.3.4 数据库设计
如果软件产品需要使⽤到数据库，软件的详细设计应包括对数据库的设计。数据库设计应在软件的需求分析、概要设计完成之后、详细设计的其它⼯作之前进⾏。在进⾏数据库设计时，应当按照交通局制定的《南京市交通局信息化数据库建设规范》要求进⾏。
3.3.5 详细设计的评审
在软件详细设计完成后，软件开发者应向交通局提交《软件系统数据库设计报告》和《软件系统详细设计报告》。在交通局对《软件系统数据库设计报告》、《软件系统详细设计报告》评审通过后，即可进⼊软件编码阶段。
3.3.6 详细设计格式
《软件系统详细设计报告》、《软件系统数据库设计报告》需按⼀定的格式进⾏编写， 具体的《软件系统详细设计报告》⽂档编写模板和《软件系统数据库设计报告》⽂档编写模 板请见附录C、附录D。
3.4 软件的编码
3.4.1 软件编码
在软件编码阶段，开发者根据《软件系统详细设计报告》中对数据结构、算法分析和模块实现等⽅⾯的设计要求，开始具体的编写程序⼯作，分别实现各模块的功能，从⽽实现对⽬标系统的功能、性能、接⼝、界⾯等⽅⾯的要求。
3.4.2 软件编码的要求
a．模块化编码b．代码可读性c．可维护性d．模块接⼝标准化e．界⾯风格统⼀e．注释的应⽤
3.4.3 编码的评审
为了尽早发现软件中的障碍，提⾼软件产品的质量，开发者在编码的过程中应该强调代码评审⼯作。将代码评审报告作为⽂档的⼀部分，提交给交通局。
3.4.4 编程规范及要求
为了提⾼编程实现的质量，软件的程序设计必须遵照国家颁布的相关编程规范。
主要内容包括：规范化的程序内部⽂档、数据结构的详细说明、清晰的语句结构、编码规范。编码规范的内容包括命名规范、界⾯规范、提⽰及帮助信息规范、热键定义等。
其中数据库部分应遵守《南京市交通局信息化数据库建设规范》的要求。在软件编码的同时应进⾏单元测试。
3.5 软件的测试
3.5.1 软件测试
为了尽早发现软件产品中的错误，从⽽达到提⾼软件质量、降低软件维护的费⽤，开发者应在编码过程中对各个模块的程序代码进⾏单元测试，系统集成时进⾏集成测试，系统集成完成后对整个软件进⾏系统测试。单元测试是在软件开发过程中针对程序模块进⾏正确性检验。集成测试是在单元测试的基础上，将所有模块按照设计要求组装成系统或⼦系统，对模块组装过程和模块接⼝进⾏正确性检验。软件系统测试不仅是检测软件的整体⾏为表 现，从另⼀个侧⾯看，也是对软件开发设计的再确认。进⾏软件系统测试⼯作时。测试主要包括界⾯测试、可⽤性测试、功能测试、稳定性(强度)测试、性能测试、强壮性(恢复)测试、逻辑性测试、破坏性测试、安全性测试等。
开发者针对单元测试，集成测试，系统测试分别制定《测试计划》。集成测试需要根据需求分析报告和概要设计制作测试⽤例，并须经过评审。软件测试按照《测试计划》、《需求分析报告》的要求进⾏，最后形成《软件测试报告》。
3.5.2 测试计划
在软件编码开始之前，开发者应向交通局提交《测试计划》，在软件交付时，开发者应向交通局提交《软件测试报告》，以确保开发者的软件得到了充分的测试。开发的软件必须经过充分的测试证明其符合设计要求、运⾏稳定、安全可⽤⽅可交付交通局。
3.6 软件的交付准备
3.6.1 交付清单
在软件测试证明软件达到要求后，软件开发者应向交通局提交开发的⽬标安装程序、数据库的数据字典、《⽤户安装⼿册》、《⽤户使⽤指南》、需求报告、设计报告、测试报告等双⽅合同约定的产物。
《⽤户安装⼿册》应详细介绍安装软件对运⾏环境的要求、安装软件的定义和内容、在客户端、服务器端及中间件的具体安装步骤、安装后的系统配置。
《⽤户使⽤指南》应包括软件各项功能的使⽤流程、操作步骤、相应业务介绍、特殊提⽰和注意事项等⽅⾯的内容，在需要时还应举例说明。
3.7 软件的鉴定验收
3.7.1 软件的鉴定验收
在软件开发完成后，为了确保软件是按照需求分析的要求进⾏开发的，保证软件产品的质量，需要对软件产品进⾏鉴定验收。在开发者如期交付软件后，由交通局负责确定具体的鉴定验收⽇期。
3.7.2 验收⼈员
由交通局聘请具有⼀定的分析、设计、编程和软件测试经验的验收组长和其他专业⼈员组成。验收组设组长⼀名(可设有副组长)，负责整个验收的计划、组织⼯作。
3.7.3 验收具体内容
验收内容应该包括：合法性检查、⽂档检查、软件⼀致性检查、软件系统测试与测试结果评审等⼏项⼯作。合法性检查检查软件开发⼯具是否合法、使⽤的函数库、控件、组件是否有合法的发布许可。⽂档检查检查开发者提交的⽂档必须齐全，质量是否过关。需要开发者提供的⽂档包括：项⽬实施计划；详细技术⽅案；
软件需求规格说明书(STP)(含数据字典)；概要设计说明书(PDD)；
详细设计说明书(DDD)(含数据库设计说明书)；软件测试计划(STP)(含测试⽤例)；软件测试报告(STR)；
⽤户⼿册(SUM)(含操作、使⽤、维护、应急处理⼿册)；源程序(SCL)(不可修改的电⼦⽂档)；项⽬实施计划(PIP)；项⽬开发总结(PDS)；软件质量保证计划(SQAP)；
此外，验收组可以根据需要对其它⽂档(如软件配置计划、项⽬进展报表、阶段评审报 表等)进⾏检查。⽂档的质量根据完备性、正确性、简明性、可追踪性、⾃说明性、规范件等⽅⾯进⾏踪合评定。验收需要对软件代码进⾏检查，以确保其符合规范，并检查其⼀致性。
3.7.4 软件验收测试⼤纲
在软件进⾏鉴定验收前，开发者需按照⼀定的格式编写《软件验收测试⼤纲》，具体的格式请见附录E。
3.8 培训
3.8.1 系统应⽤培训
主要培训内容包括：系统操作使⽤、业务管理流程。培训对象：应⽤操作⼈员。
3.8.2 系统管理的培训（可选）
主要培训内容包括：系统安装、调试、维护；系统管理。培训对象：系统管理⼈员。
开发者应详细列出培训计划，包括培训内容、教材、时间和⼈员等。
附录A 软件需求分析报告⽂档模板
1. 引⾔.... 111.1 编写⽬的... 111.2 项⽬风险... 111.3 ⽂档约定... 11
1.4 预期读者和阅读建议... 111.5 产品范围... 121.6 参考⽂献... 122. 综合描述.... 122.1 产品的状况... 122.2 产品的功能... 132.3 ⽤户类和特性... 132.4 运⾏环境... 13
2.5 设计和实现上的... 132.6 假设和约束(依赖) 143. 外部接⼝需求.... 143.1 ⽤户界⾯... 143.2 硬件接⼝... 153.3 软件接⼝... 153.4 通讯接⼝... 1. 系统功能需求.... 1.1 说明和优先级... 1.2 激励／响应序列... 174.3 输⼊／输出数据... 175. 其它⾮功能需求.... 175.1 性能需求... 175.2 安全措施需求... 185.3 安全性需求... 185.4 软件质量属性... 185.5 业务规则... 185.6 ⽤户⽂档... 186. 词汇表.... 197. 数据定义.... 198. 分析模型.... 209. 待定问题列表.... 20
1. 引⾔
引⾔是对这份软件产品需求分析报告的概览，是为了帮助阅读者了解这份⽂档是如何编写的，并且应该如何阅读、理解和解释这份⽂档。
1.1 编写⽬的
说明这份软件产品需求分析报告是为哪个软件产品编写的，开发这个软件产品意义、作⽤、以及最终要达到的意图。通过这份软件产品需求分析报告详尽说明了该软件产品的需求规格，包括修正和(或)发⾏版本号，从⽽对该软件产品进⾏准确的定义。
如果这份软件产品需求分析报告只与整个系统的某⼀部分有关系，那么只定义软件产品需求分析报告中说明的那个部分或⼦系统。
1.2 项⽬风险
具体说明本软件开发项⽬的全部风险承担者，以及各⾃在本阶段所需要承担的主要风险，⾸要风险承担者包括：
任务提出者；软件开发者；
产品使⽤者。
1.3 ⽂档约定
描述编写⽂档时所采⽤的标准(如果有标准的话)，或者各种排版约定。排版约定应该包括：
正⽂风格；提⽰⽅式；重要符号；
也应该说明⾼层次需求是否可以被其所有细化的需求所继承，或者每个需求陈述是否都有其⾃⼰的优先级。
1.4 预期读者和阅读建议
列举本软件产品需求分析报告所针对的各种不同的预期读者，例如，可能包括：
⽤户；开发⼈员；项⽬经理；营销⼈员；测试⼈员；
⽂档编写⼊员。
并且描述了⽂档中，其余部分的内容及其组织结构，并且针对每⼀类读者提出最适合的⽂档阅读建议。
1.5 产品范围
说明该软件产品及其开发⽬的的简短描述，包括利益和⽬标。把软件产品开发与企业⽬标，或者业务策略相联系。描述产品范围时需注意，可以参考项⽬视图和范围⽂档，但是不能将其内容复制到这⾥。
1.6 参考⽂献
列举编写软件产品需求分析报告时所⽤到的参考⽂献及资料，可能包括：
本项⽬的合同书；
上级机关有关本项⽬的批⽂；本项⽬已经批准的计划任务书；⽤户界⾯风格指导；
开发本项⽬时所要⽤到的标淮；系统规格需求说明；使⽤实例⽂档；
属于本项⽬的其它⼰发表⽂件；
本软件产品需求分析报告中所引⽤的⽂件、资料；相关软件产品需求分析报告；
为了⽅便读者查阅，所有参考资料应该按⼀定顺序排列。如果可能，每份资料都应该给出：
标题名称；
作者或者合同签约者；⽂件编号或者版本号；发表⽇期或者签约⽇期；出版单位或者资料来源。
2. 综合描述
这⼀部分概述了正在定义的软件产品的作⽤范围以及该软件产品所运⾏的环境、使⽤该软件产品的⽤户、对该软件产品⼰知的、有关该软件产品的假设和依赖。
2.1 产品的状况
描述了在软件产品需求分析报告中所定义的软件产品的背景和起源。说明了该软件产品是否属于下列情况：
是否是产品系列中的下⼀成员；
是否是成熟产品所改进的下⼀代产品；是否是现有应⽤软件的替代品(升级产品)；是否是⼀个新型的、⾃主型的产品。
如果该软件产品需求分析报告定义的软件系统是：
⼤系统的⼀个组成部分；
与其它系统和其它机构之间存在基本的相互关系。
那么必须说明软件产品需求分析报告定义的这部分软件是怎样与整个⼤系统相关联的，或者（同时）说明相互关系的存在形式，并且要定义出两者之间的全部接⼝。
2.2 产品的功能
因为将在需求分析报告的第4部分中详细描述软件产品的功能，所以在此只需要概略地总结。仅从业务层⾯陈述本软件产品所应具有的主要功能，在描述功能时应该针对每⼀项需求准确地描述其各项规格说明。如果存在引起误解的可能，在陈述本软件产品主要功能的作⽤领域时，也需要对应陈述本软件产品的⾮作⽤领域，以利读者理解本软件产品。
为了很好地组织产品功能，使每个读者都容易理解，可以采⽤列表的⽅法给出。也可以采⽤图形⽅式，将主要的需求分组以及它们之间的联系使⽤数据流程图的顶层图或类图进⾏表⽰，这种表⽰⽅法是很有⽤的。
参考⽤户当前管理组织构架，了解各个机构的主要职能，将有助于陈述软件产品的主要功能。
2.3 ⽤户类和特性
确定有可能使⽤该软件产品的不同⽤户类，并且描述它们相关的特征。往往有⼀些软件需求，只与特定的⽤户类有关。描述时，应该将该软件产品的重要⽤户类与⾮重要⽤户类区分开。
⽤户不⼀定是软件产品的直接使⽤者，通过报表、应⽤程序接⼝、系统硬件接⼝得到软件产品的数据和服务的⼈、或者机构也有他们的需求。所以，应该将这些外部需求视为通过报表、应⽤程序接⼝、系统硬件接⼝附加给软件产品的附加⽤户类。
2.4 运⾏环境
描述了本软件的运⾏环境，⼀般包括：
硬件平台；
操作系统和版本；
⽀撑环境(例如：数据库等)和版本；其它与该软件有关的软件组件；与该软件共存的应⽤程序。
2.5 设计和实现上的
确定影响开发⼈员⾃由选择的问题，并且说明这些问题为什么成为⼀种。可能的包括下列内容：
必须使⽤的特定技术、⼯具、编程语⾔和数据库；避免使⽤的特定技术、⼯具、编程语⾔和数据库；要求遵循的开发规范和标准
例如，如果由客户的公司或者第三⽅公司负责软件维护，就必须定义转包者所使⽤的设计符号表⽰和编码标准；
企业策略的；法规的；⼯业标准的；硬件的
例如，定时需求或存储器；
数据转换格式标淮的。
2.6 假设和约束(依赖)
列举出对软件产品需求分析报告中，影响需求陈述的假设因素(与⼰知因素相对⽴)。如果这些假设因素不正确、不⼀致或者被修改，就会使软件产品开发项⽬受到影响。这些假设的因素可能包括：
计划使⽤的商业组件，或者其它软件中的某个部件；假定产品中某个⽤户界⾯将符合⼀个特殊的设计约定；
有关本软件⽤户的若⼲假定(例如：假定⽤户会熟练使⽤SQL语⾔。)；
有关本软件开发⼯作的若⼲假定(例如：⽤户承诺的优惠、⽅便、上级部门给予的特殊和⽀持等。)；有关本软件运⾏环境的⼀些问题；
此外，确定本软件开发项⽬对外部约束因素所存在的依赖。有关的约束可能包括：
⼯期约束；经费约束；⼈员约束；设备约束；
地理位置约束；其它有关项⽬约束；
3. 外部接⼝需求
通过本节描述可以确定，保证软件产品能和外部组件正确连接的需求。关联图仅能表⽰⾼层抽象的外部接⼝，必须对接⼝数据和外部组件进⾏详细描述，并且写⼊数据定义中。如果产品的不同部分有不同的外部接⼝，那么应该把这些外部接⼝的全部详细需求并⼊到这⼀部分实例中。
注意：必须将附加⽤户类的特征与外部接⼝需求加以区分，附加⽤户类的特征描述的是通过接⼝取得软件产品的数据和服务的⼈的需求；⽽外部接⼝需求描述的是接⼝本⾝的需求。
3.1 ⽤户界⾯
陈述需要使⽤在⽤户界⾯上的软件组件，描述每⼀个⽤户界⾯的逻辑特征。必须注意，这⾥需要描述的是⽤户界⾯的逻辑特征，⽽不是⽤户界⾯。以下是可能包括的⼀些特征：
将要采⽤的图形⽤户界⾯(GUl)标准或者产品系列的风格；有关屏幕布局或者解决⽅案的；
将要使⽤在每⼀个屏幕(图形⽤户界⾯)上的软件组件，可能包括：n 选单；n 标准按钮；n 导航链接；n 各种功能组件；n 消息栏；
快捷键；
各种显⽰格式的规定，可能包括：n 不同情况下⽂字的对齐⽅式；
n 不同情况下数字的表现格式与对齐⽅式n ⽇期的表现⽅法与格式；n 计时⽅法与时间格式；n 等等。
错误信息显⽰标准；
对于⽤户界⾯的细节，例如：⼀个特定对话框的布局，应该写⼊具体的⽤户界⾯设计说明中，⽽不能写⼊软件需求规格说明中。如果采⽤现成的、合适的⽤户界⾯设计规范(标准)，或者另⽂描述，可以在这⾥直接说明，并且将其加⼊参考⽂献。
3.2 硬件接⼝
描述待开发的软件产品与系统硬件接⼝的特征，若有多个硬件接⼝，则必须全都描述。接⼝特征的描述内容可能包括：
⽀持的硬件类型；
软、硬件之间交流的数据；控制信息的性质；使⽤的通讯协议；
3.3 软件接⼝
描述该软件产品与其它外部组件的连接，这些外部组件必须明确它们的名称和版本号以资识别，可能的外部组件包括：
操作系统；数据库；⼯具；
函数库；
集成的商业组件
说明：这⾥所说的“集成的商业组件”，是指与系统集成的商业组件，⽽不是与软件产品集成的商业组件。例如：中间件、消息服务，等等。描述并且明确软件产品与软件组件之间交换数据或者消息的⽬的。描述所需要的服务，以及与内部组件通讯的性质。确定软件产品将与组件之间共享的数据。如果必须使⽤⼀种特殊的⽅法来实现数据共享机制，例如：在多⽤户系统中的⼀个全局数据区，那么就必须把它定义为⼀种实现上的。
3.4 通讯接⼝
描述与软件产品所使⽤的通讯功能相关的需求，包括：
电⼦邮件；WEB浏览器；
⽹络通讯标准或者协议；数据交互⽤电⼦表格；必须定义相关的：
消息格式；
通讯安全或加密问题；数据传输速率；
同步和异步通讯机制；
4. 系统功能需求
需要进⾏详细的需求记录，详细列出与该系统功能相关的详细功能需求，并且，唯⼀地标识每⼀项需求。这是必须提交给⽤户的软件功能，使得⽤户可以使⽤所提供的功能执⾏服务或者使⽤所指定的使⽤实例执⾏任务。描述软件产品如何响应⼰知的出错条件、⾮法输⼊、⾮法动作。
如果每⼀项功能需求都能⽤⼀项，也只需要⽤⼀项测试⽤例就能进⾏验证，那么就可以认为功能需求已经适当地进⾏描述了。如果某项功能需求找不到合适的测试⽤例，或者必须使⽤多项测试⽤例才能验证，那么该项功能需求的描述必然存在某些问题。
功能需求是根据系统功能，即软件产品所提供的主要服务来组织的。可以通过使⽤实例、运⾏模式、⽤户类、对象类或者功能等级来组织这部分内容，也可以便⽤这些元素的组合。总⽽⾔之，必须选择⼀种是读者容易理解预期产品的组织⽅案。
⽤简短的语句说明功能的名称，例如：“4.1系统参数管理”。按照服务组织的顺序，逐条阐述系统功能。⽆论说明的是何种功能，都应该针对该系统功能重复叙述4.1~ 4.3这三个部分。
可以通过各种⽅式来组织这⼀部分内容，例如采⽤：使⽤实例、运⾏模式、⽤户类、对象类、功能等级等，也可以采⽤它们的组合。其最终⽬的是，让读者容易理解即将开发的软件产品。⼀般来说，每个使⽤实例都对应⼀个系统功能，因⽽按照使⽤实例来组织内容⽐较容易让⽤户理解。
对应⼀些被共享的独⽴使⽤实例，可以定义⼀些公⽤系统功能。
必须特别注意的是，在2.2节“产品的功能”中描述的全部需求，以及它们的规格说明；必须在某个系统功能描述中有所反映，⽽且不应重复。
4.1 说明和优先级
对该系统功能进⾏简短的说明，并且指出该系统功能的优先级是：⾼、中、还是低。需要的话，还可以包括对特定优先级部分的评价，例如：利益、损失、费⽤和风险，其相对优先等级可以从1(低)到9(⾼)。
4.2 激励／响应序列
列出输⼊激励(⽤户动作、来⾃外部设备的信号或者其它触发)并且定义针对这——功能⾏为的系统响应序列，这些序列将与使⽤实例中相关的对话元素相对应。
描述激励／响应序列时，不仅需要描述基本过程，⽽且应该描述可选(扩充)过程，包括例外(引起任务不能顺序完成的情况称为例外)。疏忽了可选过程，有可能影响软件产品的功能；如果遗漏例外过程，则有可能会引发系统崩溃。如果采⽤流程图来描述激励／响应序列，⽐较容易让⽤户理解。
4.3 输⼊／输出数据
列出输⼊数据(⽤户输⼊、来⾃外部接⼝的输⼊或者其它输⼊)并且定义针对这些输⼊数据的处理(计算)⽅法，以及相应地输出数据，描述对应区别：输⼊数据和输出数据。
当有⼤量数据需要描述时，也可以分类描述数据，并且注明各项数据的输⼊、输出属性。
对于每⼀项数据，均需要描述：
数据名称；实际含义；数据类型；数据格式；数据约束；
对于复杂的处理⽅法，仅仅给出算法原理是不够的，必须描述详细的计算过程，并且列出每⼀步具体使⽤的实际算式；如果计算过程中涉及查表、判断、迭代等处理⽅法，应该给出处理依据和相关数据。如果计算⽅法很简单，也可以将其从略，不加描述。
5. 其它⾮功能需求
在这⾥列举出所有⾮功能需求，主要包括可靠性、安全性、可维护性、可扩展性、可测试性等。
5.1 性能需求
阐述不同应⽤领域对软件产品性能的需求，并且说明提出需求的原理或者依据，以帮助开发⼈员做出合理的设计选择。尽可能详细地描述性能需求，如果需要，可以针对每个功能需求或者特征分别陈述其性能需求。在这⾥确定：
相互合作的⽤户数量；
系统⽀持的并发操作数量；响应时间；
与实时系统的时间关系：容量需求n 存储器；n 磁盘空间；
n 数据库中表的最⼤⾏数。
5.2 安全措施需求
详尽陈述与软件产品使⽤过程中可能发⽣的损失、破坏、危害相关的需求。定义必须采取的安全保护或动作，以及必须预防的潜在危险动作。明确软件产品必须遵从的安全标准、策略、或规则。
5.3 安全性需求
详尽陈述与系统安全性、完整性问题相关的需求，或者与个⼈隐私问题相关的需求。这些问题将会影响到软件产品的使⽤，和软件产品所创建或者使⽤的数据的保护。定义⽤户⾝份认证，或备授权需求。明确软件产品必须满⾜的安全性或者保密性策略。也可以通过称为完整性的质量属性来阐述这些需求。⼀个典型的软件系统安全需求范例如下：“每个⽤户在第⼀次登录后，必须更改他的系统预置登录密码，系统预置的登录密码不能重⽤。”
5.4 软件质量属性
详尽陈述对客户和开发⼈员⾄关重要的在软件产品其它⽅⾯表现出来的质量功能。这些功能必须是确定的、定量的、在需要时是可以验证的。⾄少也应该指明不同属性的相对侧重点，例如：易⽤性优于易学性，或者可移植性优于有效性。
5.5 业务规则
列举出有关软件产品的所有操作规则，例如：那些⼈在特定环境下可以进⾏何种操作。这些本⾝不是功能需求，但是他们可以暗⽰某些功能需求执⾏这些规则。⼀个业务规则的范例如下：“进⾏达到或者超过10，000，00元⼈民币的储蓄业务时，必须通过附加的管理员认证。”列举业务规则时，可以根据规则的数量，选取合适的编⽬⽅式。
5.6 ⽤户⽂档
列举出将与软件产品⼀同交付的⽤户⽂档，并且明确所有⼰知⽤户⽂档的交付格式或标准，例如：
安装指南纸质⽂档，16开本；
⽤户⼿册纸质⽂档，16开本；
在线帮助
电⼦⽂档，与软件产品⼀同分发、配置；
使⽤教程电⼦⽂档，与软件产品⼀同分发、配置。
6. 词汇表
列出本⽂件中⽤到的专业术语的定义，以及有关缩写的定义(如有可能，列出相关的外⽂原词)。为了便于⾮软件专业或者⾮计算机专业⼈⼠阅读软件产品需求分析报告，要求使⽤⾮软件专业或者⾮计算机专业的术语描述软件需求。所以这⾥所指的专业术语，是指业务层⾯上的专业术语，⽽不是软件专业或者计算机专业的术语。但是，对于⽆法回避的软件专业或者计算机专业术语，也应该列⼊词汇表并且加以准确定义。
7. 数据定义
数据定义是⼀个定义了应⽤程序中使⽤的所有数据元素和结构的共享⽂档，其中对每个数据元素和结构都准确描述：含义、类型、数据⼤⼩、格式、计量单位、精度以及取值范围。数据定义的维护独⽴于软件需求规格说明，并且在软件产品开发和维护的任何阶段，均向风险承担者开放。
如果为软件开发项⽬创建⼀个独⽴的数据定义，⽽不是为每⼀项特性描述有关的数据项，有利于避免冗余和不⼀致性。但是却不利于多⼈协同编写需求分析报告，容易遗漏数据，也不⽅便阅读。因此还是建议为每个特性描述有关的数据项，汇总数据项创建数据定义，再根据数据定义复核全部数据，使得它们的名称和含义完全⼀致。必须注意的是，为了避免⼆义性，在汇总数据项时应该根据数据项所代表的实际意义汇总，⽽不是根据数据项的名称汇总。
在数据定义中，每个数据项除了有⼀个中⽂名称外，还应该为它取⼀个简短的英⽂名称，该英⽂名称应该符合命名规范，因为在软件开发时将沿⽤该英⽂名称。可以使⽤等号表⽰数据项，名称写在左边，定义写在右边。常见数据项的描述⽅式如下：
原数据元素
⼀个原数据元素是不可分解的，可以将⼀个数量值赋给它。定义原数据元素必须确定其含义、类型、数据⼤⼩、格式、计量单位、精度以及取值范围。采⽤以星号为界的⼀⾏注释⽂本，描述原数据元素的定义。
选择项
选择项是⼀种只可以取有限离散值的特殊原数据元素，描述时⼀⼀枚举这些值，并⽤⽅括号括起来写在原数据元素的定义前。在两项离散值之间，使⽤管道符分隔。
组合项
组合项是⼀个数据结构或者记录，其中包含了多个数据项。这些数据项可以是原数据元素，也可以是组合数据项，各数据项之间⽤加号连接。其中每个数据项都必须是数据定义中定义过的，结构中也可以包括其它结构，但是绝对不允许递归。如果数据结构中有可选项，使⽤圆括号把该项括起来。
重复项
重复项是组合项的⼀种特例，其中有⼀项将有多个实例出现在数据结构中，使⽤花括号把该项括起来。如果知道该项可能允许的范围，就按“最⼩值：最⼤值”的形式写在花括号前。
8. 分析模型
这是⼀个可选部分，包括或涉及到相关的分析模型，例如：
数据流程图；类图；
状态转换图；实体-关系图。
9. 待定问题列表
编辑⼀张在软件产品需求分析报告中待确定问题时的列表，把每⼀个表项都编上号，以便跟踪调查。
1. 引⾔.... 231.1 编写⽬的... 231.2 项⽬风险... 23
1.3 预期读者和阅读建议... 231.4 参考资料... 232. 设计概述.... 242.1 和约束... 24
2.2 设计原则和设计要求... 243. 系统逻辑设计.... 253.1 系统组织设计... 253.2 系统结构设计... 253.2.1 系统特性表... 263.2.2 系统特性结构图... 273.3 系统接⼝设计... 273.3.1 系统接⼝表... 27
附录B 软件概要设计报告⽂档模板
3.3.2 系统接⼝传输协议说明... 283.4 系统完整性设计... 284. 系统出错处理设计.... 294.1 系统出错处理表... 294.2 维护处理过程表... 305. 技术设计.... 31
5.1 系统开发技术说明表... 315.2 开发技术应⽤说明... 326. 数据库设计.... 327. 词汇表.... 328. 进度计划.... 32
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. 进度计划
列出进度计划，包括各⼦系统、各⼦模块完成进度计划，⼈员配备计划等。
附录C 软件详细设计报告⽂档模板
1. 引⾔.... 351.1 编写⽬的... 351.2 项⽬风险... 351.3 ⽂档约定... 35
1.4 预期读者和阅读建议... 351.5 参考资料... 362. ⽀撑环境.... 362.1 数据库管理系统... 36
2.2 开发⼯具、中间件以及数据库接⼝... 372.3 硬件环境... 372.4 ⽹络环境... 38
2.5 多种⽀撑环境开发要点... 383. 部件详细设计.... 384. 词汇表.... 39
5. 部件表格式.... 406. 界⾯表格式.... 40
1. 引⾔
引⾔是对这份软件系统详细设计报告的概览，是为了帮助阅读者了解这份⽂档如何编写的，并且应该如何阅读、理解和解释这份⽂档。
1.1 编写⽬的
说明这份软件系统详细设计报告是基于哪份软件产品需求分析报告、哪份软件产品概要设计报告和哪份软件产品数据库设计说明书(如果该软件产品需要数据库⽀持)编写的，开发这个软件产品意义、作⽤、以及最终要达到的意图。通过这份软件系统详细设计报告详尽说明了该软件产品的编码结构，从⽽对该软件产品的物理组成进⾏准确的描述。
如果这份软件系统详细设计报告只与整个系统的某⼀部分有关系，那么只定义软件系统详细设计报告中说明的那个部分或⼦系统。
1.2 项⽬风险
具体说明本软件开发项⽬的全部风险承担者，以及各⾃在本阶段所需要承担的主要风险，⾸要风险承担者包括：
任务提出者；软件开发者；产品使⽤者。
1.3 ⽂档约定
描述编写⽂档时所采⽤的标准(如果有标准的话)，或者各种编写约定。编写约定应该包括：
部件编号⽅式；界⾯编号⽅式；命名规范：等等。
1.4 预期读者和阅读建议
列举本软件系统详细设计报告所针对的各种不同的预期读者，例如，可能的读者包括：
开发⼈员；项⽬经理；测试⼈员；
⽂档编写⼈员；等等。
描述⽂档中，其余部分的内容及其组织结构，并且针对每⼀类读者提出最适合的⽂档阅读建议。
1.5 参考资料
列举编写软件系统详细设计报告时所⽤到的参考⽂献及资料，可能包括：
本项⽬的合同书；
上级机关有关本项⽬的批⽂；本项⽬已经批准的计划任务书；⽤户界⾯风格指导；
开发本项⽬时所要⽤到的标难；系统规格需求说明；使⽤实例⽂档；
属于本项⽬的其它⼰发表⽂件；
本软件系统详细设计报告中所引⽤的⽂件、资料；相关软件系统详细设计报告；等等。
为了⽅便读者查阅，所有参考资料应该按⼀定顺序排列。如果可能，每份资料都应该给出：
标题名称；
作者或者合同签约者；⽂件编号或者版本号；发表⽇期或者签约⽇期；出版单位或者资料来源。
2. ⽀撑环境
2.1 数据库管理系统
描述数据库管理系统、以及安装配置情况，需要描述的内容可能包括：
产品名称以及发⾏⼚商
这⾥的产品名称指的是数据库发⾏⼚商发布产品时公布的正式商品名称，不应该使⽤别名、简称、研发代号等⾮正式名称，以免混淆；同样的道理，发⾏⼚商的名称也应该使⽤正式名称。
版本号
数据库管理系统的准确版本号，必须按产品的实际情况描述到最细节的版本号。
补丁包版本号
描述实际上将要使⽤的数据库管理系统补丁包的版本号，必须注意，在某些情况下该版本号不⼀定是最新的版本号。
语⾔或代码集
对于只⽀持⼀种语⾔或者⼀个代码集的数据库管理系统来说，该项描述不具意义。对于⽀持多种语⾔或者多个代码集的数据库管理系统来说，该项描述指的是实际使⽤的语⾔或者代码集。
安装位置
描述数据库管理系统的实际安装位置，应该分别对管理系统安缺位置和数据存放位置进⾏描述，应该指明服务器名和安装卷号(盘号)。对于分布式数据库，必须分别描述每⼀个数据库管理系统。
配置参数
描述数据库管理系统在实际安装时应该配置的各个参数，对于分布式数据库，必须分别描述每⼀个数据库管理系统的配置参数。
等等
同时参照《南京市交通局信息化数据库建设规范》。
2.2 开发⼯具、中间件以及数据库接⼝
描述所选⽤的⼯具软件和中间件的名称、版本号，以及开发⼯具与数据库或者中间件接⼝的情况。如果使⽤了多种开发⼯具、辅助开发⼯具、第三⽅软件部件、多种中间件、多种接⼝、等答应该逐项分别描述，并且说明每⼀项的适⽤范围。需要描述的内容可能包括：
产品名称以及发⾏⼚商同2.1中产品名称以及发⾏⼚商。
版本号同2.1中版本号。
补丁包版本号同2.1中补丁包版本号。
语⾔或代码集同2.1中语⾔或代码集。
数据库接⼝名称
描述数据库接⼝的名称，如果使⽤别名时，应同时描述使⽤的别名。
数据库接⼝⽅式
描述与数据库接⼝的⽅式，并说明该接⼝⽅式的特点；如果需要，还应该说明使⽤时的注意事项。
数据库接⼝设置
描述各种接⼝设置，包括：协议、端⼝号等等。同时参照《南京市交通局信息化数据库建设规范》。
2.3 硬件环境
描述所选⽤的硬件环境，各种机型，例如：服务器、⼯作站，应该分别描述。需要描述的内容可能包括：
机型；主频；内存容量；磁盘容量；特殊部件；操作系统；使⽤位置；等等。
2.4 ⽹络环境
描述可能影响应⽤软件访问数据库的各种⽹络环境，如果存在加密传输、VPN链路等情况，也必须描述。对于结构复杂的⽹络，还应该提供⽹络拓扑图和数据流向⽰意图。需要描述的内容可能包括：
⽹络结构；
⽹络操作系统；⽹络带宽；路由组织；
加密传输⽅式；
VPN链路连接⽅式；等等。
2.5 多种⽀撑环境开发要点
当软件产品将来可能遇到的多种运⾏环境时，应该分别按照3.1节⾄3.4节的内容列表描述。如果软件产品各个⼦系统的运⾏环境不完全⼀样时，应该分⼦系统按照3.1节⾄3.4节的内容列表描述。
遇到上述情况时，不仅需要详细描述各种软件开发、调试、测试的环境，为了确实保证软件产品将来能够在各种可能的运⾏环境中正常运⾏，还需要对软件产品进⾏严格的配置管理。
3. 部件详细设计
这⾥所提及的软件部件，系指能够完成特定功能、相对独⽴的⼀些代码集合，它们可以是插件、组件、控件、函数、过程、⼦程序、动态连接库、等等。具体呈何种形态，取决于实际采⽤的开发⼯具和将要实现的软件结构。
按照合适的顺序，逐个描述软件部件的详细情况。描述的顺序可以是按层次横向进⾏描述，也可以是按模块纵向进⾏描述，总之描述的⽅式必须有利于读者理解软件结构。
每个部件采⽤⼀张软件部件表进⾏描述，软件部件表的格式见附表⼀，其中；
部件编号
软件部件的统⼀顺序编号；对于实⾏配置管理的软件开发项⽬来说，该编号必须与该部件在配置管理中的编号相同。
部件名称
软件部件的正式英⽂名称，该名称是程序中使⽤的实际名称，必须符合国家相关软件命名标准。
所属⼦系统指该部件所属的⼦系统；
对于不分为多个⼦系统的软件来说，不必填写该栏。
部件调⽤者
指调⽤该部件的部件(或界⾯参数)的编号和名称。
部件被调⽤者
指被该部件所调⽤的部件的编号和名称。
部件⼊⼝参数
指该部件⼊⼝数据类名称或者数据名称，以及对这些数据的描述；如果部件没有⼊⼝参数，该栏为空。
部件出⼝参数
指该部件出⼝数据类名称或者数据名称，以及对这些数据的描述；如果部件没有出⼝参数，该栏为空。
算法
指该部件的算法形式表⽰，如果很简单、或者不存在，也可以为空。
流程描述
指该部件的处理流程的详细表⽰或描述。
部件表⽰形式
指该部件完成开发后的最终表⽰形式，具体形式取决于开发⼯具和软件结构，表⽰形式可能是：n 插件、组件、控件，n 函数、过程、⼦程序，n 存储过程，n 动态连接库，n 等等。
运⾏环境
描述该部件所适合的运⾏环境，即说明该部件是针对何种运⾏环境所开发的；可以直接描述运⾏环境，也可以描述运⾏环境的编号；
对于实⾏配置管理的软件开发项⽬来说，该描述必须与该部件在配置管理中的描相同。
性能要求
指开发该部件时必须满⾜的专门要求，这些要求可以是：n 精度n 灵活性n 响应时间n 可重⽤性n 等等。
提出的要求⼀般不宜超过3项，以排列的先后顺序表⽰优先级。
4. 词汇表
列出本⽂件中⽤到的专业术语的定义，以及有关缩写的定义(如有可能，列出相关的外⽂原词)。为了便于⾮软件专业或者⾮计算机专业⼈⼠也能够在⼀定的范围内，读懂软件系统详细设计报告，要求尽可能使⽤⾮软件专业或者⾮计算机专业的术语进⾏描述。所以这⾥所指的专业术语，是指业务层⾯上的专业术语，⽽不是软件专业或者计算机专业的术语。但是，对于⽆法回避的软件专业或者计算机专业术语，也应该列⼊词汇表，并且加以准确定义。
5. 部件表格式
部件编号所属⼦系统部件调⽤者部件被调⽤者部件⼊⼝参数部件⼊⼝参数算法： 流程描述： 表⽰性能性能要求
部件名称
运⾏环境
说明：如果软件不见使⽤⼀张表表述不完时，可以采⽤续表描述，但是必须注明是那张表的续表。
6. 界⾯表格式
界⾯编号界⾯性质表⽰形式： 界⾯参数
参数名 内容
说明
部件名称界⾯介质
说明：如果软件不见使⽤⼀张表表述不完时，可以采⽤续表描述，但是必须注明是那张表的续表。
1. 引⾔.... 451.1 编写⽬的... 451.2 项⽬来源... 451.3 ⽂档约定... 45
1.4 预期读者和阅读建议... 451.5 参考资料... 452. 数据库命名规则.... 463. 数据库设计说明.... 463.1 数据库逻辑设计... 463.2 数据库物理设计... 463.3 数据库分布... 473.4 基表设计... 473.5 视图设计... 483.6 索引设计... 493.7 完整性约束... 503.8 授权设计... 503.9 触发器设计... 513.10 存储过程设计... 513.11 数据复制设计... 524. 词汇表.... 535. 历史数据处理.... 53
附录D 软件数据库设计报告⽂档模板
1. 引⾔
引⾔是对这份数据库设计说明书的概览，是为了帮助阅读者了解这份⽂档是如何编写的，并且应该如何阅读、理解和解释这份⽂档。
1.1 编写⽬的
说明这份数据库设计说明书是为哪份软件产品编写的，开发这个软件产品意义、作⽤以及最终要达到的意图。通过这份数据库设计说明书详尽准确地描述了该软件产品的数据库结构。如果这份数据库设计说明书只与整个系统的某⼀部分有关系，那么只定义数据库设计说明书中说明的那个部分或⼦系统。
1.2 项⽬来源
具体说明本软件开发项⽬的全部风险承担者，以及各⾃在本阶段所需要承担的主要风险，⾸要风险承担者包括：
任务提出者；
软件开发者；产品使⽤者。
1.3 ⽂档约定
描述编写⽂档时所采⽤的各种排版约定。排版约定应该包括：
命名⽅法；提⽰⽅式；通配符号：等等。
1.4 预期读者和阅读建议
列举本数据库设计说明书所针对的各种不同的预期读者，例如，可能包括：
开发⼈员；项⽬经理；测试⼈员；
⽂档编写⼈员。
并且描述了⽂档中，其余部分的内容及其组织结构，并且针对每⼀类读者提出最适合的⽂档阅读建议。
1.5 参考资料
列举编写需求规格说明书时所⽤到的参考⽂献及资料，可能包括；
本项⽬的合同书；
上级机关有关本项⽬的批⽂；本项⽬已经批准的计划任务书；⽤户界⾯风格指导；
开发本项⽬时所要⽤到的标准；系统规格需求说明；使⽤实例⽂档；
属于本项⽬的其它已发表⽂件；
本数据库设计说明书中所引⽤的⽂件、资料；相关软件产品数据库设计说明书；等等。
为了⽅便读者查阅，所有参考资料应该按⼀定顺序排列。如果可能，每份资料都应该给出：
标题名称；
作者或者合同签约者；⽂件编号或者版本号；发表⽇期或者签约⽇期；出版单位或者资料来源。
2. 数据库命名规则
完整并且清楚的说明本数据库的命名规则，在《南京市交通局信息化数据库建设规范》中已经给出了⼀个完整的数据库命名规则，开发者应遵守执⾏，如果本数据库的命名规则与该规范不完全⼀致，应作出解释。
3. 数据库设计说明
3.1 数据库逻辑设计
数据库设计⼈员根据《软件需求分析报告》，创建与数据库相关的实体关系图(E-R图)。如采⽤⾯对对象的分析和设计⽅法，则此处的实体相当于类。
在此处，应给出逻辑设计的完整的E-R图。
3.2 数据库物理设计
在此处应给出完整的数据库物理结构E-R图。开发者应根据逻辑设计的结果，进⾏数据库的物理设计，并对表结构进⾏规范化处理(第⼀范式，第⼆范式，第三范式)。
3.3 数据库分布
数据库分布采⽤⼀张表格进⾏描述，其格式如下：
数据库数据库
管理系统编号 其中：
数据库编号
给出本系统中指定数据库的顺序编号。
若本系统中只有⼀个数据库，则本项内容不需要描述，本表内容也只有⼀⾏。说明： 在⼀个系统中可能安装若⼲个相同的或者不同的数据库管理系统，⼀个数据库管理系统也可能安装⼀个或者多个数据库。
数据库管理系统名称
给出本系统中指定数据库管理系统的商品名称。
若本系统中只有⼀种数据库管理系统，则本项内容不需要描述。
数据库管理系统版本号
给出本系统中指定数据库管理系统的版本号。
若本系统中只有⼀个版本的数据库管理系统，则本项内容不需要描述。
数据库英⽂名称
给出本数据库的英⽂名称，该名称是在应⽤软件中实际使⽤的名称，必须符合《南京市交通局信息化数据库建设规范》中相关命名规范。
数据库中⽂名称
给出本数据库的中⽂名称，该名称是本数据库英⽂名称的说明。
数据库安装物理位置
给出本数据库安装的实际位置，必须描述清楚该位置是在那个物理设备的哪⼀个逻辑存储设备上，以及存储⽂件的名称。
名称 版本号 管理系统
英⽂名称
中⽂名称
物理位置 数据库
数据库
数据库
安装数据库3.4 基表设计
每个基表采⽤⼀张表格进⾏描述，其格式如下：
数据库编号：基表编号：
基表英⽂名称：基表中⽂名称：字段编号
说明：
其中
数据库编号含义同上。
基表编号
给出本基表的顺序编号。
基表英⽂名称
英⽂字段名 中⽂字段名 字段类型 备注
给出本基表的英⽂名称，该名称是在应⽤软件中实际使⽤的名称，必须符合命名规范。
基表中⽂名称
给出本基表的中⽂名称，该名称是本基表英⽂名称的说明。
字段编号
该基表中，各个字段的顺序编号。
英⽂字段名
该基表中，各个字段的英⽂名称，该名称必须符合《南京市交通局信息化数据库建设规范》中相关命名规范。
中⽂字段名
该基表中，各个字段的中⽂名称，该名称是英⽂字段名的说明。
字段类型
该基表中，各个字段的类型；如果需要，在说明类型时，还需要说明字段长度。
备注
该基表中，各个字段有关的性说明，需要描述的内容可能包括：n 值域；n 缺省值；n 空字段；
n 显⽰格式与⼩数位数；n 有效性规则与约束；n 标题；n 等等
说明
说明⼀些有关本表的、必须描述清楚的问题，需要描述的内容可能包括：n 主关键字；
n 索引、排序⽅式和类型；n 触发器；n 数据复制；n 等等
3.5 视图设计
每个视图采⽤⼀张表格进⾏描述，其格式如下：
数据库编号：视图编号：
视图英⽂名称：视图中⽂名称：相关基表和视图：字段编号英⽂字段名 说明：
其中：
数据库编号含义同上。
中⽂字段名 字段类型 字段源 备注
视图编号
给出本视图的顺序编号。
视图英⽂名称
给出本视图的英⽂名称，该名称是在应⽤软件中实际使⽤的名称，必须符合命名规范。
视图中⽂名称
给出本视图的中⽂名称，该名称是本视图英⽂名称的说明。
相关基表和视图
列出建⽴该视图时，所⽤到的基表和视图。
字段编号
该视图中，各个字段的顺序编号。
英⽂字段名
该视图中，各个字段的英⽂名称，该名称必须符合《南京市交通局信息化数据库建设规范》中相关命名规范。
中⽂字段名
该视图中，各个字段的中⽂名称，该名称是英⽂字段名的说明。
字段类型
该视图中，各个字段的类型；如果需要，在说明类型时，还需要说明字段长度。
字段源
该视图中，各个字段的来源，即该字段原来是那个表或者那个视图中的那个字段；在某些情况下，字段可能来⾃⼀个特定的表达式。
备注
该视图中，各个字段有关的性说明，包括：n 值域；n 缺省值；n 空字段；
n 显⽰格式与⼩数位数；n 有效性规则与约束；n 标题；n 等等。
说明
说明⼀些有关本视图的、必须描述清楚的问题，需要描述的内容可能包括：n 索引；n 权限；n 等等
3.6 索引设计
每个数据库的所有采⽤⼀张表格进⾏描述，其格式如下：数据库编号：索引编号
基表名称
索引名称 字段集名称
备注
其中：
数据库编号含义同上。
索引编号
给出本项索引的顺序编号。
基表名称
给出本项索引所在的基表名称。
索引名称给出本项索引的名称。
字段集名称
给出本项索引所在的字段名称或者字段集名称。
备注
描述有关本项索引中，其它需要说明的事项，例如：排序⽅式、等等。
3.7 完整性约束
每个数据库的完整性约束采⽤⼀张表格进⾏描述，其格式如下：数据库编号：
索引编号
其中：
数据库编号含义同上。
约束编号
给出本项完整性约束的顺序编号。
完整性约束名
给出本项完整性约束的名称。
基表名
给出本项完整性约束所在的基表名称。
字段名
给出本项完整性约束所在的字段名称。
约束表达式
给出本项完整性约束的逻辑表达式。
备注
描述有关本项完整性约束中，其它需要说明的事项。
基表名称
索引名称
字段集名称
备注
3.8 授权设计
每个数据库的授权采⽤⼀张表格进⾏描述，其格式如下：
数据库编号：授权编号
⽤户名称
对象名称 权限
备注
其中：
数据库编号含义同上。
授权编号
给出本项授权的顺序编号。
⽤户名称
给出本项授权的⽤户名称，这⾥的⽤户不⼀定是具体⽤户，也可以是⽤户组。
对象名称
给出本项授权的对象名称，例如：基表、字段、等等。必须注意到，⼀个⽤户可能存在多项授权，应该逐项描述。
权限
被授权⽤户在该对象上拥有的访问权限，例如：查询权、修改权、等等。
备注
描述有关本项授权中，其它需要说明的事项。
3.9 触发器设计
数据库编号含义同上。
触发器编号
给出本触发器的顺序编号。
触发器英⽂名称
给出本触发器的英⽂名称，必须符合《南京市交通局信息化数据库建设规范》中相关命名规范。
触发器中⽂名称
给出本触发器的中⽂名称，该名称是本触发器英⽂名称的说明。
触发器条件
给出该触发器产⽣触发的条件。
触发器结果
给出该触发器被触发后所执⾏的动作内容。
3.10 存储过程设计
每个数据库的授权采⽤⼀张表格进⾏描述，其格式如下：
数据库编号：存储过程编号：存储过程英⽂名称：存储过程中⽂名称：存储过程内容：
说明： 其中：
数据库编号
含义同上。
存储过程编号
给出本存储过程的顺序编号。
存储过程英⽂名称
给出本存储过程的英⽂名称，该名称是在应⽤软件中实际使⽤的名称，必须符合命名规范。
存储过程中⽂名称
给出本存储过程的中⽂名称，该名称是本存储过程英⽂名称的说明。
存储过程内容
给出该存储过程算法或者描述详细内容，如果需要，应该辅以流程图说明。
说明
描述本存储过程需要说明的⼀些事项。
3.11 数据复制设计
每项数据复制采⽤⼀张表格进⾏描述，其格式如下：数据复制编号：复制英⽂名称：复制中⽂名称：源数据库编号：⽬标数据库编号：复制说明：执⾏⽅式：
源数据库名称
基表名称字段名称 备注：其中：
数据复制编号给出本数据复制的顺序编哥
数据复制英⽂名称
给出本数据复制的英⽂名称，该名称是在应⽤软件中实际使⽤的名称，必须符合命名规范。
数据复制中⽂名称
给出本数据复制的中⽂名称，该名称是本数据复制英⽂名称的说明。
源数据库编号
作为复制数据源的数据库编号，编号含义同上。
⽬标数据库编号
作为复制⽬标的数据库编号，编号含义同上。
复制说明
给出该复制的详细描述，如果需要，应该辅以⽰意图说明。
执⾏⽅式
给出该复制的执⾏⽅式，描述时应该说明：
⾃动执⾏
基表名称 ⽬标数据库名称
字段名称 必须说明执⾏周期或者执⾏条件。
调⽤执⾏
必须说明被那个模块调⽤，以及是⼿动调⽤，还是条件调⽤。
源数据库名称
给出对应源数据库编号的源数据库名称。
⽬标数据库名称
给出对应⽬标数据库编号的⽬标数据库名称。
基表名称
分别给出源数据库和⽬标数据库中，进⾏对应复制的源基表名称和⽬标基表名事例。
字段名称
分别给出源基表和⽬标基表中，进⾏对应复制的源字段名称和⽬标字段名称。
备注
描述本复制中需要说明的⼀些特殊事项。
4. 词汇表
列出本⽂件中⽤到的专业术语的定义，以及有关缩写的定义(如有可能，列出相关的外⽂原词)。为了便于⾮软件专业或者⾮计算机专业⼈⼠(例如：⽂档编写⼈员等等。)
阅读数据库设计说明书，要求使⽤⾮软件专业或者⾮计算机专业的术语进⾏描述。所以这⾥所指的专业术语，是指业务层⾯上的专业术语，⽽不是软件专业或者计算机专业的术语。但是，对于⽆法回避的软件专业或者计算机专业术语，也应该列⼊词汇表，并且加以准确定义。
5. 历史数据处理
严格说来，历史数据处理并不属于数据库设计范畴。但是对于⼤多数数据库来说，如果历史数据处理不当，少则数⽉、多则数年，最终将使数据库⽆法正常运⾏。这段时间的长短取决于数据库设计容量⼤⼩，以及数据流强度(即在单位时间内进⼊数据库的数据记录数量)⾼低。因此应该设计专门的归档数据库，并根据历史数据需要保存备查的时间长短，定期将历史数据转移到归档数据库中。设计归档数据库时，需要根据具体情况进⾏考虑，下⾯列出⼀些可能需要考虑的内容：
历史数据需要备查的时间长短。数据转移周期的时间单位
例如：⽇、周、旬、⽉、季、年、等等。
数据转移的⽅式
例如：⼿动、⾃动、条件、等等。
历史数据保存的细节
多数情况下，归档的历史数据并不需要保存全部细节，可以去掉部分细节，采⽤压缩归档处理的⽅法减少归档数据库的占⽤空间。
注意：如果压缩数据时，去掉了不该去掉的细节，将是⽆可挽回的。
其它需要说明的问题
1. 引⾔.... 571.1 ⽬的... 571.2 术语... 571.3 参照标准... 572. 测试⽇期安排.... 583. 测试⼩组及成员.... 584. 测试具体内容.... 584.1 合法性检查... 584.2 软件⽂档检查... 584.2.1 必须提供检查的⽂档... 584.2.2 其他可能需要检查的⽂档... 594.2.3 由业主确定必须检查的其他⽂档... 594.2.4 ⽂档质量的度量准则... 594.3 软件代码测试... 594.3.1 源代码⼀般性检查... 59
附录E 软件测试（验收）⼤纲
4.3.2 软件⼀致性检查... 604.4 软件系统测试... 604.4.1 界⾯(外观)测试... 614.4.2 可⽤性测试... 614.4.3 功能测试... 614.4.4 稳定性(强度)测试... 614.4.5 性能测试... 614.4.6 强壮性(恢复)测试... 614.4.7 逻辑性测试... 614.4.8 破坏性测试... 614.4.9 安全性测试... 625. 测试结果交付⽅式.... 62
1. 引⾔
1.1 ⽬的
为了尽可能的找出软件的不⾜，提⾼软件的质量，促进软件的成功验收，专门制定了本⼤纲。其主要⽬的在于为所要进⾏的测试⼯作制定各种必要的准则和规范，以及在有关⽅⾯协议的基础上对测试⼯作进⾏合理组织与管理。
1.2 术语
本⼤纲所提及的术语，其定义遵照GB/T 11457标准。
1.3 参照标准
GB/T 11457—1995软件⼯程术语
GB 8566—1995；信息技术软件⽣存期过程
OGB 8567—1988*
计算机软件产品开发⽂件编制指南
GB 9385*
计算机软件需求说明编制指南
GB 9386—1988*计算机软件测试⽂件编制指南
GB/T 12504—1990计算机软件质量保证计划规范
OGB/T 12505—1990计算机软件配置管理计划规范
OGB/T 14079—1993软件维护指南
OGB/T 14394—1993计算机软件可靠性和可维护性管理
GB/T 16680⼀1996软件⽂档管理指南
开发者企业规范
软件开发者有关软件⼯程的规范
其它⽂件
例如：合同书等，法律⽂件中的有关规定。
说明：（1）应该遵循⾃顶⽽下、就严不就宽的原则，除⾮合同书等法律⽂件中另有规定。
（2）标记（*）号的标准为推荐标准。
2. 测试⽇期安排
开发⽅如期交付软件的基础上，由业主审核确定具体⽇期安排。
3. 测试⼩组及成员
由业主聘请具有⼀定的分析、设计、编程和软件测试经验的测试组长和其他专业⼈员组成。测试组设组长⼀名(可设有副组长)，负责整个测试的计划、组织⼯作。
或委托具有国家认可测试资质的第三⽅进⾏测试。
4. 测试具体内容
测试内容应该包括：合法性检查、⽂档检查、软件⼀致性检查、软件系统测试与测试结果评审等⼏项⼯作。
4.1 合法性检查
检查开发者在开发本软件时，使⽤的开发⼯具是否合法。对在编程中使⽤的⼀些⾮本单位⾃⼰开发的，也不是由开发⼯具提供的控件、组件、函数库等，检查其是否有合法的发布许可。
4.2 软件⽂档检查
4.2.1 必须提供检查的⽂档
项⽬实施计划；
详细技术⽅案；
软件需求规格说明书(STP)(含数据字典)；概要设计说明书(PDD)；
详细设计说明书(DDD)(含数据库设计说明书)；软件测试计划(STP)(含测试⽤例)；软件测试报告(STR)；
⽤户⼿册(SUM)(含操作、使⽤、维护、应急处理⼿册)；源程序(SCL)(不可修改的电⼦⽂档)；项⽬实施计划(PIP)；项⽬开发总结(PDS)；
软件质量保证计划(SQAP)；软件配置计划(SCMPP)；项⽬进展报表(PPR)；阶段评审报表(PRR)；
4.2.2 其他可能需要检查的⽂档4.2.3 由业主确定必须检查的其他⽂档
说明：如果业主认为4.1.1节和4.1.2节所列⽂档之外，还需要检查其它⽂档，则在此列出⽂档名称；如果业主认为不需要进⾏额外的⽂档检查，则本部分⽆内容。
4.2.4 ⽂档质量的度量准则
⽂档是软件的重要组成都分，是软件⽣存周期各个不同阶段的产品描述。⽂档质量的度量准则就是要评审各阶段⽂档的合适性。主要有以下六条：
完备性
开发⽅必须按照GB 8567(计算机软件产品开发⽂件编制指南)的规定编制相应的⽂档，以保证在开发阶段结束时其⽂档是齐全的。
正确性
在软件开发各个阶段所编写的⽂档的内容，必须真实的反映阶段的⼯作且与该阶段的需求相⼀致。
简明性
在软件开发各个阶段所编写的各种⽂档的语⾔表达应该清晰、准确简练，适合各种⽂档的特定读者。
可追踪性
在软件开发各个阶段所编写的各种⽂档应该具有良好的可追踪性。⽂档的可追踪性包括横向可追踪性和纵向可追踪性两个⽅⾯。前者是指在不同的⽂档的相关内容之间相互检索的难易程序；后者是指确定同⼀⽂档某⼀内容在本⽂档范围中检索的难易程度。
⾃说明性
在软件开发各个阶段所编写的各种⽂档应该具有较好的⾃说明性。⽂档的⾃说明性是指在软件开发各个阶段中，不同⽂档能够独⽴表达，该软件在其相应阶段的阶段成果的能⼒。
规范性
在软件开发各个阶段所编写的各种⽂档应该具有良好的规范性。⽂档的规范性是指⽂档的封⾯、⼤纲、术语的含义以及图⽰符号等符合有关规范的规定。
4.3 软件代码测试
4.3.1 源代码⼀般性检查
仅对系统关键模块的源代码进⾏抽查，检查模块代码编写的规范性，批注的准确性，是否存在潜在性错误，以及代码的可维护性。
命名规范检查
检查源代码中的变量、函数、对象、过程等的命名是否符合约定规范，该规范可以由开发⽅在软件⼯程⽂档规范中单⽅⾯约定。
注释检查
检查程序中的注释是否规范，注释量是否达到约定要求，例如：要求注释量达到30％左右。
接⼝检查
检查数据库接⼝等外部接⼝是否符合要求，各程序模块使⽤的接⼝⽅式是否⼀致，特定的外部接⼝协议是否符合。
数据类型检查
源代码中涉及的⾦额的常量、变量及数据集和数据库中涉及⾦额的数据类型是否采⽤货币类型，以防⽌在特定条件下产⽣较⼤的误差⽽影响统计结果。
性检查
对⼀些程序中使⽤到的、具有使⽤的命令、事件、⽅法、过程、函数、对象、控件等进⾏检查。检查在长时间运⾏时，有⽆可能接近或者达到条件，这⾥考虑的系统运⾏时间可能长达数年。
4.3.2 软件⼀致性检查
编译检查
要求提交的源代码在其规定的编译环境中，能够重新编译⽆错误，并且能够完成相应的功能，从⽽确定移交的确实是正确的源代码。
安装／卸载检查
在新系统上⽤交付的软件安装盘重新安装各个模块，并且通过运⾏这些软件模块，能否完成相应的功能，从⽽确定移交的确实是正确的软件安装盘。在安装后⽴即卸载所安装的模块，并且检查是否能够做到彻底卸载。
运⾏模块检查
将新安装的软件模块与现场运⾏模块⽤软件⼯具抽样⽐较，确认交付的软件安装盘与现场运⾏软件⼀致。
抽查数处现场运⾏模块⽤软件⼯具⽐较，确认现场运⾏软件⼀致。
4.4 软件系统测试
软件系统测试不仅是检测软件的整体⾏为表现，从另⼀个侧⾯看，也是对软件开发设计的再确认。
进⾏软件系统测试⼯作时，具体的测试⽤例是由开发⽅提供，并由测试⽅和⽤户共同补充制定的。在开发⽅做完功能演⽰后，可以进⾏下列测试：
界⾯(外观)测试；可⽤性测试；功能测试；
稳定性(强度)测试；性能测试；
强壮性(恢复)测试；逻辑性测试；破坏性测试；安全性测试。
说明：实际进⾏的测试内容有测试⽅法和业主根据具体情况共同确定，并⾮⽂中所列测试内容都必须进⾏测试。
4.4.1 界⾯(外观)测试
对照界⾯规范(在软件需求规格说明书中规定，或者由软件⼯程规范中给出)和界⾯表(在概要设计中给出)，检查各界⾯设计是否规范，包括：界⾯风格、表现形式、组件⽤法、字体选择、字号选择、⾊彩搭配、⽇期表现、计时⽅法、时间格式、对齐⽅式等等，是否符合规范、是否协调⼀致、是否便于操作。
4.4.2 可⽤性测试
测试操作是否⽅便，⽤户界⾯是否友好等。测试系统是否有影响操作流程的界⾯Bug和功能Bug，纪录具体Bug的数量、出现频率和严重程度。
4.4.3 功能测试
检查数据在流程中各个阶段的准确性。对系统中每⼀模块利⽤实际数据运⾏，将其结果与同样数据环境下应该得出的结果相⽐较，或与软件需求规格说明书中要求的结果进⾏⽐较，如有偏差，则功能测试不能通过。
检查软件需求规格说明书中描述的需求是否都得到满⾜；系统是否缺乏软件需求规格说明书中规定的重要功能；以及系统实际使⽤中不可缺少⽽软件需求规格说明书中没有规定的功能。
如果存在遗产数据，应该检查遗产数据转换是否正确。
4.4.4 稳定性(强度)测试
测试系统的能⼒最⾼实际限度，即检查软件在⼀些超负荷情况下，功能实现的情况。例如：要求软件进⾏某⼀⾏为的⼤量重复、输⼊⼤量的数据或⼤数值数据、对数据库进⾏⼤量复杂的查询等。
利⽤边界测试(最⼤值、最⼩值、N次循环)对系统进⾏模拟运⾏测试，观察其是否处于稳定状态。
4.4.5 性能测试
根据系统设计指标，或者对被测软件提出的性能指标，测试软件的运⾏性能，例如：传输连接最长时限、传输错误率、计算精度、记录精度、响应时限和恢复时限等。
4.4.6 强壮性(恢复)测试
采⽤⼈⼯的⼲扰使应⽤软件、平台软件或者系统硬件出错，中断正常使⽤，检测系统的恢复能⼒。进⾏强壮性测试时，应该参考性能测试相
关的测试指标。
4.4.7 逻辑性测试
根据系统的功能逻辑图，测试软件是否按规定的逻辑路径运⾏，选择⼀些极限数据判断软件运⾏是否存在错误或⾮法路径，从⽽发现系统的逻辑错误或⾮法后门。
4.4.8 破坏性测试
输⼊错误的或⾮法的数据(类型)，检查系统的报错纠错的能⼒及稳定性。并测试可连续使⽤多长时间⽽系统不崩溃。
4.4.9 安全性测试
验证安装在系统内的保护机构确实能够对系统进⾏保护，使之不受各种⾮常的⼲扰，安全测试时需要设计⼀些测试⽤例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。
说明：进⾏安全测试时，必须遵循相关的安全规定，并且有业主派员参加。
5. 测试结果交付⽅式
测试结束后，由测试组填写软件测试报告，并将测试报告与全部测试材料⼀并交给业主。具体交付⽅式，由业主和测试⽅双⽅协商确定。测试报告包括下列内容：
软件测试计划软件测试⽇志
软件⽂档检查报告软件代码测试报告软件系统测试报告测试总结报告
测试⼈员签字登记表
因篇幅问题不能全部显示，请点此查看更多更全内容