系统需求规格说明书(UC).doc

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