系统需求规格说明书

系统需求规格说明书模板（UC）Version 0.1核准签名核准人 项目经理 日期核准人 系统分析师 日期核准人 客户 日期核准人 日期核准人 日期核准人 日期系统需求规格说明书模板（UC） Version: 0.1机密 2/26修订历史日期 版本 描述 作者2010-12-9 0.1 草稿 谭勇系统需求规格说明书模板（UC） Version: 0.1机密 3/26目 录1 引言 .51.1 编写目的 .51.2 适用范围 .51.3 文档概述 .51.4 参考资料 .51.5 术语、定义和缩写 51.6 USE-CASE 图形规范 .62 系统概述 .62.1 业务背景 .62.2 系统功能 .72.3 用户类别及特征 82.4 运行环境 .82.5 用户文档 .82.6 设计和实现上的限制 82.7 假设和依赖 .93 功能需求 .93.1 系统用例图 .103.2 系统用例清单 103.3 示例 .103.3.1 功能简述 示例 .103.3.2 用例清单 示例 113.3.3 示例 .113.3.4 示例 .133.4 示例 .154 非功能需求 154.1 系统质量需求 154.1.1 性能 .164.1.2 可靠性 .164.1.3 可维护性 .164.1.4 可用性 .174.1.5 灵活性 .174.1.6 可移植性 .174.1.7 可重用性 .174.1.8 可测试性 .174.1.9 易用性 .184.2 安全性需求 .184.3 环境需求 .184.4 保密性和私密性需求 194.5 业务规则 .194.6 其它需求 .195 外部接口需求 205.1 用户界面 .205.2 硬件接口 .215.3 软件接口 .21系统需求规格说明书模板（UC） Version: 0.1机密 4/265.4 通信接口 .216 附录 .226.1 附录 1：分析模型 .226.2 附录 2：待确定问题的列表 .22系统需求规格说明书模板（UC） Version: 0.1机密 5/261 引言软件需求规格说明书记录对系统或系统的一部分的完整软件需求。 以下是一个典型的软件需求规格说明书概述，用于涉及用例建模的项目。此工件由一个包组成，该包包含用例模型的用例、非功能性需求、接口需求以及其他支持信息。本文档模板适合采用用例建模技术的项目需求描述。- 在正式编写文档时，请删除内容要求部分。1.1 编写目的本文档作为*与 XXXXXXXXXX 公司之间就*建立 XXXX 司（局或单位）XXXXXXXXXX系统需求理解达成一致共识的基础文件，作为双方界定项目范围、签定合同的主要基础，也作为本项目验收的主要依据。同时，本文档也作为*后继工作开展的基础，供双方项目主管负责人、项目经理、技术开发人员、测试人员等理解需求之用。1.2 适用范围本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：*方面的项目负责人、公司方项目经理、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。1.3 文档概述本文档主要描述了 XXXXXXXXXX 系统项目的软件需求。本文档首先从业务背景、系统功能、运行环境等方面概要描述系统，其次从用户界面、软件接口等方面描述系统的外部接口需求，然后进一步详细描述功能性需求和非功能性需求以及待确定的问题。1.4 参考资料列出本文的参考文件清单，包括出版单位、作者、版本、日期等信息。示范：仅供参考，不具备任何实质性的内容。系统需求规格说明书模板（UC） Version: 0.1机密 6/26XXX 总体需求书 （XXX 单位 XXX 提供）XXX 需求调研报告 作者：XXX设计模式 XXXXX 出版社 UML 用户指南 XXXXX 出版社 1.5 术语、定义和缩写列出本文档所涉及的专业术语、缩写词及相关定义。定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。示范：仅供参考，不具备任何实质性的内容。1) OLTP：On-line Transaction Processing，联机事务处理。2) OLAP：On-Line Analytical Processing，联机分析处理；是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。1.6 Use-Case 图形规范对文档中使用的 Use-Case 图的图符作简介，同时说明所应用 UML 规范的版本，以便理解和统一。如果使用的是 UML V1.3 标准规范，则可以直接将下列内容作为文档内容。一个 Use-Case 图显示的是 Actor 与 Use-Case 之间的某种关系。表 1-1 列出了本文档的 Use-Case 图中用到的图符、名称及其功能简介。表 1-1 UML V1.3 Use Case 图符图符 名称 描述UseCase Use Case用于表示 Use-case 图中的 Use-Case，每个 Use Case 用于表示所建模系统的一项外部功能需求，即从用户的角度分析所得的需求。Actor Actor 用于描述与系统功能有关的外部实体，它可以是用户，也可以是外部系统。系统需求规格说明书模板（UC） Version: 0.1机密 7/26关联用于连接 Actor 和 Use Case，表示该 Actor 所代表的系统外部与该 Use Case 所描述的系统需求有关。这也是 Actor 和 Use Case 之间唯一合法的连接。 扩展由 Use Case A 指向 Use Case B（被扩展），表示 Use Case B描述了一项基本需求，而 Use Case A 则描述了该基本需求的特殊情况，即用例 A 扩展了用例 B 的需求。泛化 由 Use Case A（子用例）指向 Use Case B（父用例），表示Use Case A 继承了 Use Case B 的特性，并增加了新的特性。 包含 由 Use Case A 指向 Use Case B（被包含），表示 Use Case A中包含了 Use Case B 中的行为或功能。2 系统概述2.1 业务背景概要描述本系统的业务背景和起源。若用图表更能清楚描述业务背景，则建议在用自然文字描述业务的同时，辅以图形、表格来更精确地描述业务。示范：仅供参考，不具备任何实质性的内容。为切实推进国家助学贷款管理工作，落实关于切实推进国家助学贷款工作有关问题的通知（银发200238 号）、关于下达 2002 年度国家助学贷款指导性贷款计划的通知（银发2002253 号）和关于加强国家助学贷款三考核工作的通知（银办发2002239 号）文件精神及肖钢副行长关于在我司建立银行系统的助学贷款专项统计制度的批示，满足“要按月考核经办银行国家助学贷款的申请人数和申请金额、考核已审批贷款人数和贷款合同金额、考核实际发放贷款人数和发放金额。”“按月编报分省四定的国家助学贷款进度明细表”和“增报国家助学贷款三考核指标分地区、分银行统计表”的工作要求，解决目前统计中存在的指标口径难于统一（银行与学校、教育管理部门），数据采集不准、不细，校名不规范，手工统计劳动量大、效率不高等问题。满足对贷款学生基本信息、信用记录的查询；对学校进度明细的统计；对分地区、分行别的汇总统计以及相关分析等新的管理需求，必须有相应的计算机软件系统支持，以解决数据的采集录入、统计汇总、上报传输的需要。系统需求规格说明书模板（UC） Version: 0.1机密 8/262.2 系统功能以图形、表格等形式简要说明本软件系统的主要功能，易于读者理解。对于采用用例建模时，此节将概述适用于该子系统或特性的用例模型或用例模型的子集，其中包括所有用例名称列表及简要说明，以及适用的各种图和关系。详细内容描述将在第 4 部分说明。示范：仅供参考，不具备任何实质性的内容。银行业务通用网上统计暨助学贷款统计系统通过定制不同的业务类别，定制统计业务的项目、指标及其汇总关系等，快速满足不同银行业务的统计要求，形成从各级金融机构到*各分支机构，从下级机构到上级机构的业务定制、数据采集、分析、统计和信息发布的统计体系。主要任务和目标是：遵循*统一数据采集、统一信息发布建设原则，促进信息整合和应用整合。作为“*信息系统平台“的一部分，为“*信息系统平台”提供部分公用化模块组件，避免业务模块的重复开发。最终实现一个银行业务通用网上统计系统平台；并能方便地定制新的统计业务，并能灵活适应业务发展需要。利用银行业务通用网上统计系统平台部署助学贷款专项网上统计系统，满足对国家助学贷款的“三考核”要求，满足*全面掌握助学贷款业务信息的需要，并配合建立银行系统的助学贷款专项统计制度。助学贷款统计分析系统可为*全辖各机构和相关部门提供统一的数据采集、分析、报表、信息发布等多方面的功能，并可为商业银行、教育部门以及社会公众提供相关信息查询和统计分析结果。并作为个人征信系统初期应用模型，为促进个人征信系统打下基础。系统功能关系图如下：2.3 用户类别及特征确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关。提供参与系统的主角的名称列表及简要说明，即简要描述系统的Actor。系统需求规格说明书模板（UC） Version: 0.1机密 9/26示范：仅供参考，不具备任何实质性的内容。例子一：参与本系统操作的所有用户角色（Actor），如下图所示：下表是对上图关键用户角色（Actor）的简要说明：Actor 名称 简要说明 权限系统管理者一般由总部的人员来担任，用户数量比较少。负责系统的配置、备份与恢复，以及任务管理等工作。全部权限（读、写、删除、创建）XXX 岗位 系统时钟 工作流引擎 打印机系统 例子二：在整个金融快报的业务处理过程中存在以下几种用户：业务司局人员：主要是*各业务司局和相关单位，如货币金银局、上海黄金交易所、中国外汇交易中心、中央国债登记结算公司、外汇管理局国际收支司、国际司等，该类用户主要负责向*调查统计司综合处提供基础数据。金融快报管理员：主要是*调查统计司综合处，该用户主要负责对报送的数据进行审核，加工并最终生成金融快报的制式文本，并转交行长、国办、中办；配置金融快报系统的基本工作参数以及各种模版。2.4 运行环境列出所需的运行环境内容。2.5 用户文档列出所需的用户文档，例如：用户手册、联机用户文档、联机帮助系统、关于声明的帮助等的需求。示范：仅供参考，不具备任何实质性的内容。本软件应提供实时在线帮助（即联机帮助系统）、用户操作手册、系统管理员手册、系统安装手册以及培训文档。系统需求规格说明书模板（UC） Version: 0.1机密 10/262.6 设计和实现上的限制确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。描述在进行设计和实现时需要注意的问题，比如，必须使用或者避免的特定技术、工具、编程语言和数据库；所要求的开发规范或标准；企业策略、政府法规或工业标准；数据转换格式标准等等。示范：仅供参考，不具备任何实质性的内容。本系统应具备良好的可扩展性、复杂操作环境的可适应性、灵活可配置的权限控制、大容量数据操作的快速响应及高可靠性以及与现有系统的兼容性，同时，具备在线提醒和短信息提示，能够实现多种数据格式的转换，以多种图形格式展示分析结果。本系统应支持 J2EE 架构，符合国际、国内标准规范，能够与其它系统无缝衔接。2.7 假设和依赖列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立）。这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定，但是另一个 S R S 读者却可能不这样认为。如果这些假设不正确、不一致或被更改，就会使项目受到影响。此外，确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其它文档(例如项目计划)中了，那么在此就可以参考其它文档。示范：仅供参考，不具备任何实质性的内容。本系统需要集成其他软件开发商提供的组件或应用系统，假定需要集成的组件能够按时提供并满足需求。假定这些组件的运行环境与本系统运行环境不发生冲突，能与本系统兼容。另外，假定本文档所描述的软件需求均获得了项目双方所有客户的认可且稳定不变。如果项目后期，客户提出的需求变更超出了本需求规格范围，则将严重影响本系统的设计、开发和程序的稳定。系统需求规格说明书模板（UC） Version: 0.1机密 11/26在本软件需求规格说明书定版之后，客户需求发生了较大变更，变更后的需求规格说明将不在本文档中补充，而以新的版本文档给出。3 功能需求本章应包括所有的软件需求，其详细程度应使设计人员能够设计出可以满足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求。 当利用用例建模时，这些需求在用例说明和适用的补充规约中记录。如果没有利用用例建模，则可以将补充规约的概要直接插入本节。详细列出与该特性相关的详细功能需求。这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务。描述产品如何响应可预知的出错条件或者非法输入或动作。必须唯一地标识每个需求，并标识出优先级。3.1 系统用例图以用例图的形式展示整个软件系统的功能结构，该用例图包括所有用例和角色，如果用例数量非常大无法一一展示，先以用例包的形式提供，然后在各章节中详细展开。应分层次展示整个系统的功能，先从系统子系统模块逐层展示，并说明各子系统和模块之间的功能关系。同时，应注意与外部系统的接口。以下图示仅作为示范，不具备任何实例性质，供需求分析人员参考而已。注：此图仅表示整个系统内的所有用例及其之间的关系。如果用例太多无法全部展示，可采用用例包的形式。本系统用例图以薪水支付系统为例，仅供参考。或者以用例包的形式展现整个系统的功能：3.2 系统用例清单以表格的形式列出本软件系统所有的用例清单，具体格式如下：示范：仅供参考，不具备任何实质性的内容。需求章节 用例 数 用例编号 用例名称 简要描述 优先级系统需求规格说明书模板（UC） Version: 0.1机密 12/26LDAP-UC-101 登录系统 描述用户如何登录课程注册系统 高LDAP-UC-102 查看成绩单 允许学生在学期结束前查看成绩单 高LDAP-UC-103 注册课程允许学生向课程目录中注册课程，也包括更新、删除课程等高LDAP-UC-104 选择讲授课程允许教授在下学期到来之前，从课程目录中选择符合自己的课程高4.3 课程注册管理 8 LDAP-UC-201 注：以上表格所示内容是以课程注册管理子系统为例。流水号第一位表示子系统的编号。3.3 示例3.3.1 功能简述 示例简要描述本子系统的主要功能，并以用例图展示子系统。示范：仅供参考，不具备任何实质性的内容。业务定制功能组将提供数据库结构定义、数据采集接口规范自定义以及基础数据管理功能，具有灵活易用、功能强大的特点，是用户创建数据库资源并对采集业务进行定制集成管理工具。以下图示仅作为示范，不具备任何实例性质，供需求分析人员参考而已。此图仅表示子系统内的所有用例及其之间的关系。如果用例太多无法全部展示，可采用用例包的形式。3.3.2 用例清单 示例以表格的形式列出所有的用例清单，具体格式如下：用例编号 用例名称 简要描述 优先级LDAP-UC-101 登录系统 描述用户（学生、教授、注册员）如何登录课程注册系统 高LDAP-UC-102 查看成绩单 允许学生在学期结束前查看成绩单 高系统需求规格说明书模板（UC） Version: 0.1机密 13/26LDAP-UC-103 注册课程 允许学生向课程目录中注册课程，也包括更新、删除课程等 高LDAP-UC-104 选择讲授课程 允许教授在下学期到来之前，从课程目录中选择符合自己的课程 高 3.3.3 示例在用例建模过程中，用例通常会定义系统的大部分功能性需求，以及一些非功能性需求。注意：如果用例作为单独文件保存，则应按照用例说明模板编写；如果在这里引用或附加，则应按照以下用例描述格式进行编写。编写时，直接删除此处内容。说明中应简要表述用例的作用和目的，并列出本用例的参与者。示范：仅供参考，不具备任何实质性的内容。本用例描述一个参与者（学生、教授、注册员）如何成功登录课程注册系统。 参与者简要列出本用例的参与者。示范：仅供参考，不具备任何实质性的内容。学生、教授、注册员 前置条件用例的前置条件是执行用例之前必须存在的系统状态。一般指执行本用例的前提条件。示范：仅供参考，不具备任何实质性的内容。无。 事件流程以流程图的形式提供事件流程。以下图示仅作为示范，不具备任何实例性质，供需求分析人员参考而已。系统需求规格说明书模板（UC） Version: 0.1机密 14/26此图是用 Rational Rose 工具画的事件流程图，当然也可以用 Visio 来画事件流程图，只要能说明事件流程即可。对于简单的事件流程图，也可以省略不画。.1 基本流程当主角有所行动时，此用例随即开始。总是由主角来带动用例。用例应说明主角的行为及系统的响应。应按照主角与系统进行对话的形式来逐步引入用例。用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。如果进行了信息交换，则需指出来回传递的具体信息。例如，只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内。您最好在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。简单的分支流程可以在用例文本中提供。如果只需几句话就可说明存在分支流程时将发生的事件，则可以直接在事件流程一节中说明。如果分支流程较为复杂，则需要用另外一节来单独说明。例如，分支流程小节解释如何说明较复杂的分支流程。虽然清晰明了的叙述性文字是无可替代的，但有时一幅图要比千言短文更具说明性。只要表达得简洁明了，您就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如果流程图有助于描述复杂的决策流程，那么一定要充分利用它！同样，对于与状态相关的行为，状态转移图通常比数页文字更能清晰地描述系统的行为。根据问题来选用妥当的表示方法，但应慎用您的读者可能不太明了的术语、符号或图形。请切记，您的目的是要阐明问题，而不是混淆问题。示范：仅供参考，不具备任何实质性的内容。当该 actor 想要登录进入课程注册系统时，本用例开始。1. 系统请求该 actor 输入他或她的用户名和口令；2. 该 actor 输入他或她的用户名和口令；3. 系统验证该 actor 输入的用户名和口令，并将该 actor 登录信息记入系统日志中。系统需求规格说明书模板（UC） Version: 0.1机密 15/2.2 分支流程较复杂的分支流程应单独说明，这已在事件流程一节的基本流小节中提及。将分支流程小节当作备选行为 在许多情况下，由于主事件流程中发生异常事件，这时每个分支流程都可代表备选行为。这些分支流程的长度可以是说明与备选行为相关的事件所需的长度。当分支流程结束时，除非另外说明，主事件流程的事件将重新开始。示范：仅供参考，不具备任何实质性的内容。1. 无效用户名和或口令在基本流程中，如果该 actor 输入一个无效的用户名和或口令，系统应显示一个错误消息。该 actor 能够选择重新恢复到基本流程开始（第 1 步）或取消登录，直到本用例结束。 特殊需求特殊需求通常是非功能性需求，它为一个用例所专有，但很难或很自然的在用例的事件流程文本中表述。特殊需求的示例包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求）。此外，其他需求 如操作系统及环境、兼容性需求和设计约束 也应在此节中记录。示范：仅供参考，不具备任何实质性的内容。无。 后置条件用例的后置条件是用例一执行完毕系统可能处于的一组状态。一般指本用例执行后的结果。示范：仅供参考，不具备任何实质性的内容。如果该 actor 成功登录进入课程注册系统，本用例结束；如果登录不成功，则系统状态不发生变化。系统需求规格说明书模板（UC） Version: 0.1机密 16/2 扩展点扩展点在事件流程中所处位置的定义。扩展点主要是界定本用例与其它用例的接口，说明在本用例事件流程的哪一步扩展到其它用例。示范：仅供参考，不具备任何实质性的内容。无。 补充说明对基本流程、分支流程中的一些关键数据信息作进一步的补充性说明。示范：仅供参考，不具备任何实质性的内容。无。3.3.4 示例本用例描述允许某个学生在当前学期为课程表注册课程。在新学期开始之初，允许学生能更新和删除已选的课程，只要在增加或减少课程的期间。课程目录系统为本学期所有课程表提供一个清单列表。 用例说明用例名称编号参与者使用频率业务优先级描述前置条件典型过程1基流（Basic Flow）增加删除2分支流(Exception Flow)如出错提示后置条件非功能性要求系统需求规格说明书模板（UC） Version: 0.1机密 17/26补充说明存在疑问 用例活动图 用例顺序图 用例界面设计说明3.4 示例。4 非功能需求4.1 系统质量需求本条应描述合同中标识的或从更高层次规格说明派生出来的对系统或子系统质量方面的需求,例如包括有关系统的功能性(实现全部所需功能的能力)、性能（支持的用户数、操作响应速度、资源占用约束等）、可靠性(产生正确、一致结果的能力)、可维护性(易于更正的能力)、可用性(需要时进行访问和操作的能力)、灵活性(易于适应需求变化的能力)、可移植性(易于修改以适应新环境的能力)、可重用性(可被多个应用使用的能力)、可测试性(易于充分测试的能力)、易用性（易于学习和使用的能力）以及其它属性的定量需求。需求应尽可能具体、量化和能够验证。系统需求规格说明书模板（UC） Version: 0.1机密 18/264.1.1 性能阐述不同的应用领域对产品性能的需求，并解释它们的原理以帮助开发人员作出合理的设计选择。确定相互合作的用户数或者所支持的操作、响应时间以及与实时系统的时间关系。你还可以在这里定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。尽可能详细地确定性能需求。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们都集中在一起陈述。示范：仅供参考，不具备任何实质性的内容。系统容量：支持 3 万用户，支持 GB 级数据。数据库表行数不超过 100 万行，数据库最大容量不超过 1000GB，磁盘空间至少需要 40G 以上.响应指标：运行速度取决于硬件配置和应用数据规模，在推荐配置环境下：登录响应时间在 5 秒内，刷新栏目响应时间在 5 秒内，刷新条目分页列表响应时间 5 秒内，打开信息条目响应时间 3 秒内，刷新部门、人员列表响应时间 5 秒内。4.1.2 可靠性阐述客户对系统的可靠性方面的要求。可靠性是软件无故障运行一段时间的概率。示范：仅供参考，不具备任何实质性的内容。本系统的最终用户涉及面广，因此，整体系统运行要求稳定，有很强的防错、抗错能力，保证数据报送工作正常进行。可靠性指标：在连续运行情况下，系统可靠性 99.9999%。提供应用服务器集群技术和组件技术支持高可靠性和伸缩性。4.1.3 可维护性阐述客户对系统的可维护性方面的要求。可维护性表明了自软件中纠正一个缺陷或做一次更改的简易程度。示范：仅供参考，不具备任何实质性的内容。系统需求规格说明书模板（UC） Version: 0.1机密 19/26系统从设计上尽量考虑使得*大多数统计系统的建设都能使用本软件搭建而成，量少做二次开发或者不做二次开发，直接通过系统配置搭建系统，从功能上具有通用性，易修改和扩展。软件开发使用组件技术，保证了可维护性高。系统具有开放性，是指统计、分析内容的可修改、可扩展性。例如，经过一定的授权，系统管理人员即可根据将来统计制度变动的需要对统计指标进行增、删等修改，无需经过软件开发技术人员。兼容性：系统应支持多种操作系统、数据库系统和、WEB 服务器系统。采用JAVA、JNDI 技术来保证较好的可移植性和可扩展性。4.1.4 可用性阐述客户对系统的可用性方面的要求。可用性表明了软件具备随时随地能够访问和操作的能力。示范：仅供参考，不具备任何实质性的内容。本系统采用 B/S 和 C/S 混合模式，支持脱机方式，因此能够保证用户随时随地访问系统。同时，系统采取容错技术，具备数据恢复功能，能够保证用户随时随地操作系统。4.1.5 灵活性阐述客户对系统的灵活性方面的要求。灵活性表明了软件系统能够易于适应需求的变化的能力。示范：仅供参考，不具备任何实质性的内容。适应多种数据传输方式，能够提供灵活配置以适应业务需求的变化，如可自行定义业务规则、采集机构、采集指标、处理逻辑、反馈信息等等，通过多方面的定制以适应某个具体的业务系统。4.1.6 可移植性阐述客户对系统的可移植性方面的要求。可移植性表明了软件易于修改以适应多种环境的能力。示范：仅供参考，不具备任何实质性的内容。系统需求规格说明书模板（UC） Version: 0.1机密 20/26本系统支持多种网络环境，特别是互联网，能够实现跨平台操作。4.1.7 可重用性阐述客户对系统的可重用性方面的要求。可重用性表明了软件能够被多个应用使用的能力。示范：仅供参考，不具备任何实质性的内容。本系统提供组件式服务，部分公用组件能够被其它系统所使用。同时，在将来后继升级系统时，能够使得部分组件被重用。4.1.8 可测试性阐述客户对系统的可测试性方面的要求。可测试性表明了软件能够在有限时间、人力资源限度内被充分测试的能力。示范：仅供参考，不具备任何实质性的内容。软件系统具有良好的可测试性，能够在 4 个工作周、3 个人力的情况下顺利完成所有测试项目。具体测试项目如下：代码检查：程序开发人员除了调试外，还应进行重点检查程序代码语法错误。单元测试：对组成系统的每个组件进行数据结构测试和功能性测试，重点是组件的功能和程序逻辑。集成测试：将组件组装成子系统后，应再次对组装后的子系统进行功能性测试，重点是组件与组件之间的接口测试。系统测试：经过测试后的各子系统组装成系统后，还应组织对整个系统进行全面的测试，包括功能、性能以及接口测试。性能测试：测试系统的操作相应速度以及资源占用效率。压力测试：测试系统的可靠性和伸缩性，以验证系统能承受多大的负载。鉴于本软件系统的特殊性，测试重点应放在功能和性能上，其它方面可略作测试。系统需求规格说明书模板（UC） Version: 0.1机密 21/264.1.9 易用性阐述客户对系统的易用性方面的要求，易用性包括人机界面的友好性，新用户或不常使用产品的用户在学习使用产品时的简易程度等。示范：仅供参考，不具备任何实质性的内容。系统应操作简单、易学易用、符合标准浏览器操作风格，丰富的联机帮助，人性化的操作界面，界面布局合理，节省操作时间提高生产效率。4.2 安全性需求详尽陈述与系统安全性、完整性或与私人问题相关的需求，包括用户身份确认或授权需求，数据库安全性需求，工作流程安全性需求等。这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。示范：仅供参考，不具备任何实质性的内容。网络安全：能经受来自互联网的一般性恶意攻击。如病毒（包括木马）攻击、口令猜测攻击、黑客入侵等。因此，必须配备较强的网络安全防范、响应能力，为应用系统提供安全可靠的网络统计平台。数据库安全：数据库级备份和恢复。数据库级用户进行角色和权限授权。使得在异常情况发生时，系统可以得以快速恢复，避免数据的丢失或将其影响降到最低限度。同样，要保证存储过程中数据不被非法访问和篡改。应用系统的安全：通过对用户的身份鉴别，并实施相应的访问控制策略后，使用户只能完成得到系统授权的数据访问功能操作。用户只有经授权后才可以更新程序，避免因错误程序更新而影响系统的正常运行。4.3 环境需求以列表形式或分类方式描述有关系统或子系统必须运行的环境需求，例如包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。系统需求规格说明书模板（UC） Version: 0.1机密 22/26示范：仅供参考，不具备任何实质性的内容。硬件 操作系统及其版本 应用服务器软件及其版本 应用软件及其部件IBM HTTP Server、Apache、MS IIS5.0等；DB2（7.2 EE 以上版本）服务器 IBM RS6000 AIX 4.3.3WAS（4.0 以上版本）、Web Logic(7.0 以上版本)等；Oracle EE（9i EE以上版本）浏览客户端PII 800/64M/2G Win98 及以上IE 5.0 以上或 Netscape 同等版本以上特殊客户端PII 2G/64M/2G建议配置 Win2000及以上IE 5.0 以上或 Netscape 同等版本以上MicroStrategy7i客户端4.4 保密性和私密性需求本条应指明保密性和私密性的系统需求，包括：系统运行的保密性/私密性环境、提供的保密性或私密性的类型和程度、系统必须经受的保密性/私密性的风险、减少此类危险所需的安全措施、系统必须遵循的保密性/私密性政策、必须提供的保密性/私密性审核、保密性/私密性必须遵循的确证/认可准则。示范：仅供参考，不具备任何实质性的内容。数据保密：网络传递数据经过加密。需要保证数据在采集、传输和处理过程中不被偷窥、窃取、篡改。4.5 业务规则列举出有关产品的所有操作规则，例如什么人在什么特定环境下可以进行何种操作。这些本身不是功能需求，但它们可以暗示某些功能需求执行这些规则。如果涉及非常多的业务规则，需要单独作为一章来描述。示范：仅供参考，不具备任何实质性的内容。在数据上载前，报数人员要核查数据；在数据上载后，系统应反馈数据上载成功信息。系统需求规格说明书模板（UC） Version: 0.1机密 23/264.6 其它需求阐述未在需求规格说明书模板中定义的需求，如人员培训、包装和交付、数据迁移等方面的需求。如果不需要增加其它需求，可省略这一部分。定义在软件需求规格说明的其它部分未出现的需求，例如国际化需求或法律上的需求。你还可以增加有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求。示范：仅供参考，不具备任何实质性的内容。本系统应提供数据迁移的接口，需要将原有系统的数据顺利迁移到本系统中。本系统要求在安装过程的任何步骤都应提供退出安装的操作，并能自动删除已复制的文件。在系统运行过程中，计算机突然断电，系统应具备数据备份和数据恢复功能，并提供数据修复和容错功能。5 外部接口需求利用本节来确定可以保证新产品与外部组件正确连接的需求。关联图表示了高层抽象的外部联接。需要把对接口数据和控制组件的详细描述写入数据字典中。如果产品的不同部分有不同的外部接口，那么应把这些外部接口的详细需求并入到这一部分的实例中。5.1 用户界面描述系统的界面类型以及界面的特定要求，包括界面布局、界面风格、界面规范等。指出界面采用的标准或格式，所提供的标准功能（如帮助），快捷键设置，错误显示格式，初步的 GUI 产品构件，并描述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。而对于用户界面的细节，例如特定对话框的布局，应该写入一个独立的用户界面规格说明中，而不能写入软件需求规格说明中。示范（以 B/S 为例）：以下示范仅供参考，应根据项目实际特点灵活掌握。本软件系统的用户界面总体要求：界面友好，布局合理，操作方便，美观大方。系统需求规格说明书模板（UC） Version: 0.1机密 24/26本软件系统的界面应遵循总体要求，分别从以下几个方面进行具体