模板系统需求规格说明书UC.docx
《模板系统需求规格说明书UC.docx》由会员分享，可在线阅读，更多相关《模板系统需求规格说明书UC.docx（28页珍藏版）》请在冰点文库上搜索。
模板系统需求规格说明书UC
广州天河软件园短信平台
需求说明书
广州市中智软件开发有限公司
二〇一〇年八月
文档信息
参与人员
编写：
审核：
文档历史记录
版本号
发布日期
更改人
更改章节及条款
更改内容说明
V1.0
2012.08.18
1引言
[软件需求规格说明书记录对系统或系统的一部分的完整软件需求。
以下是一个典型的软件需求规格说明书概述，用于涉及用例建模的项目。
此工件由一个包组成，该包包含用例模型的用例、非功能性需求、接口需求以及其他支持信息。
本文档模板适合采用用例建模技术的项目需求描述。
]---- 在正式编写文档时，请删除内容要求部分。
编写目的
本文档作为***与XXXXXXXXXX公司之间就***建立XXXX司（局或单位）XXXXXXXXXX系统需求理解达成一致共识的基础文件，作为双方界定项目范围、签定合同的主要基础，也作为本项目验收的主要依据。
同时，本文档也作为***后继工作开展的基础，供双方项目主管负责人、项目经理、技术开发人员、测试人员等理解需求之用。
适用范围
本文档适用于所有与本项目有关的软件开发阶段及其相关人员，其中：
***方面的项目负责人、公司方项目经理、技术开发人员（包括分析人员、设计人员、程序人员）、测试人员应重点阅读本文档各部分，其他人员可选择性阅读本文档。
文档概述
本文档主要描述了XXXXXXXXXX系统项目的软件需求。
本文档首先从业务背景、系统功能、运行环境等方面概要描述系统，其次从用户界面、软件接口等方面描述系统的外部接口需求，然后进一步详细描述功能性需求和非功能性需求以及待确定的问题。
参考资料
[列出本文的参考文件清单，包括出版单位、作者、版本、日期等信息。
]
示范：
―――仅供参考，不具备任何实质性的内容。
《XXX总体需求书》 （XXX单位XXX提供）
《XXX需求调研报告》 作者：
XXX
《设计模式》 XXXXX出版社
《UML用户指南》 XXXXX出版社
术语、定义和缩写
[列出本文档所涉及的专业术语、缩写词及相关定义。
定义所有必要的术语，以便读者可以正确地解释软件需求规格说明，包括词头和缩写。
你可能希望为整个公司创建一张跨越多项项目的词汇表，并且只包括特定于单一项目的软件需求规格说明中的术语。
]
示范：
―――仅供参考，不具备任何实质性的内容。
1） OLTP：
On-lineTransactionProcessing，联机事务处理。
2） OLAP：
On-LineAnalyticalProcessing，联机分析处理；是使分析人员、管理人员或执行人员能够从多角度对信息进行快速、一致、交互地存取,从而获得对数据的更深入了解的一类软件技术。
Use-Case图形规范
[对文档中使用的Use-Case图的图符作简介，同时说明所应用UML规范的版本，以便理解和统一。
如果使用的是UMLV1.3标准规范，则可以直接将下列内容作为文档内容。
]
一个Use-Case图显示的是Actor与Use-Case之间的某种关系。
表1-1列出了本文档的Use-Case图中用到的图符、名称及其功能简介。
表1-1UMLV1.3UseCase图符
图符
名称
描述
UseCase
UseCase
用于表示Use-case图中的Use-Case，每个UseCase用于表示所建模系统的一项外部功能需求，即从用户的角度分析所得的需求。
Actor
Actor
用于描述与系统功能有关的外部实体，它可以是用户，也可以是外部系统。
关联
用于连接Actor和UseCase，表示该Actor所代表的系统外部与该UseCase所描述的系统需求有关。
这也是Actor和UseCase之间唯一合法的连接。
<>
扩展
由UseCaseA指向UseCaseB（被扩展），表示UseCaseB描述了一项基本需求，而UseCaseA则描述了该基本需求的特殊情况，即用例A扩展了用例B的需求。
泛化
由UseCaseA（子用例）指向UseCaseB（父用例），表示UseCaseA继承了UseCaseB的特性，并增加了新的特性。
<>
包含
由UseCaseA指向UseCaseB（被包含），表示UseCaseA中包含了UseCaseB中的行为或功能。
2系统概述
业务背景
[概要描述本系统的业务背景和起源。
若用图表更能清楚描述业务背景，则建议在用自然文字描述业务的同时，辅以图形、表格来更精确地描述业务。
]
示范：
―――仅供参考，不具备任何实质性的内容。
为切实推进国家助学贷款管理工作，落实《关于切实推进国家助学贷款工作有关问题的通知》（银发[2002]38号）、《关于下达2002年度国家助学贷款指导性贷款计划的通知》（银发[2002]253号）和《关于加强国家助学贷款‘三考核’工作的通知》（银办发[2002]239号）文件精神及肖钢副行长关于在我司建立银行系统的助学贷款专项统计制度的批示，满足“要按月考核经办银行国家助学贷款的申请人数和申请金额、考核已审批贷款人数和贷款合同金额、考核实际发放贷款人数和发放金额。
”“按月编报分省‘四定’的国家助学贷款进度明细表”和“增报《国家助学贷款‘三考核’指标分地区、分银行统计表》”的工作要求，解决目前统计中存在的指标口径难于统一（银行与学校、教育管理部门），数据采集不准、不细，校名不规范，手工统计劳动量大、效率不高等问题。
满足对贷款学生基本信息、信用记录的查询；对学校进度明细的统计；对分地区、分行别的汇总统计以及相关分析等新的管理需求，必须有相应的计算机软件系统支持，以解决数据的采集录入、统计汇总、上报传输的需要。
系统功能
[以图形、表格等形式简要说明本软件系统的主要功能，易于读者理解。
对于采用用例建模时，此节将概述适用于该子系统或特性的用例模型或用例模型的子集，其中包括所有用例名称列表及简要说明，以及适用的各种图和关系。
详细内容描述将在第4部分说明。
]
示范：
―――仅供参考，不具备任何实质性的内容。
银行业务通用网上统计暨助学贷款统计系统通过定制不同的业务类别，定制统计业务的项目、指标及其汇总关系等，快速满足不同银行业务的统计要求，形成从各级金融机构到***各分支机构，从下级机构到上级机构的业务定制、数据采集、分析、统计和信息发布的统计体系。
主要任务和目标是：
遵循***统一数据采集、统一信息发布建设原则，促进信息整合和应用整合。
作为“***信息系统平台“的一部分，为“***信息系统平台”提供部分公用化模块组件，避免业务模块的重复开发。
最终实现一个银行业务通用网上统计系统平台；并能方便地定制新的统计业务，并能灵活适应业务发展需要。
利用银行业务通用网上统计系统平台部署助学贷款专项网上统计系统，满足对国家助学贷款的“三考核”要求，满足***全面掌握助学贷款业务信息的需要，并配合建立银行系统的助学贷款专项统计制度。
助学贷款统计分析系统可为***全辖各机构和相关部门提供统一的数据采集、分析、报表、信息发布等多方面的功能，并可为商业银行、教育部门以及社会公众提供相关信息查询和统计分析结果。
并作为个人征信系统初期应用模型，为促进个人征信系统打下基础。
系统功能关系图如下：
用户类别及特征
[确定你觉得可能使用该产品的不同用户类并描述它们相关的特征。
有一些需求可能只与特定的用户类相关。
提供参与系统的主角的名称列表及简要说明，即简要描述系统的Actor。
]
示范：
―――仅供参考，不具备任何实质性的内容。
例子一：
参与本系统操作的所有用户角色（Actor），如下图所示：
下表是对上图关键用户角色（Actor）的简要说明：
Actor名称
简要说明
权限
系统管理者
一般由总部的人员来担任，用户数量比较少。
负责系统的配置、备份与恢复，以及任务管理等工作。
全部权限（读、写、删除、创建）
XXX岗位
系统时钟
工作流引擎
打印机系统
例子二：
在整个金融快报的业务处理过程中存在以下几种用户：
业务司局人员：
主要是***各业务司局和相关单位，如货币金银局、上海黄金交易所、中国外汇交易中心、中央国债登记结算公司、外汇管理局国际收支司、国际司等，该类用户主要负责向***调查统计司综合处提供基础数据。
金融快报管理员：
主要是***调查统计司综合处，该用户主要负责对报送的数据进行审核，加工并最终生成金融快报的制式文本，并转交行长、国办、中办；配置金融快报系统的基本工作参数以及各种模版。
运行环境
[列出所需的运行环境内容。
]
用户文档
[列出所需的用户文档，例如：
用户手册、联机用户文档、联机帮助系统、关于声明的帮助等的需求。
]
示范：
―――仅供参考，不具备任何实质性的内容。
本软件应提供实时在线帮助（即联机帮助系统）、用户操作手册、系统管理员手册、系统安装手册以及培训文档。
设计和实现上的限制
[确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种限制。
描述在进行设计和实现时需要注意的问题，比如，必须使用或者避免的特定技术、工具、编程语言和数据库；所要求的开发规范或标准；企业策略、政府法规或工业标准；数据转换格式标准等等。
]
示范：
―――仅供参考，不具备任何实质性的内容。
本系统应具备良好的可扩展性、复杂操作环境的可适应性、灵活可配置的权限控制、大容量数据操作的快速响应及高可靠性以及与现有系统的兼容性，同时，具备在线提醒和短信息提示，能够实现多种数据格式的转换，以多种图形格式展示分析结果。
本系统应支持J2EE架构，符合国际、国内标准规范，能够与其它系统无缝衔接。
假设和依赖
[列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立）。
这可能包括你打算要用的商业组件或有关开发或运行环境的问题。
你可能认为产品将符合一个特殊的用户界面设计约定，但是另一个SRS 读者却可能不这样认为。
如果这些假设不正确、不一致或被更改，就会使项目受到影响。
此外，确定项目对外部因素存在的依赖。
例如，如果你打算把其它项目开发的组件集成到系统中，那么你就要依赖那个项目按时提供正确的操作组件。
如果这些依赖已经记录到其它文档（例如项目计划）中了，那么在此就可以参考其它文档。
]
示范：
―――仅供参考，不具备任何实质性的内容。
本系统需要集成其他软件开发商提供的组件或应用系统，假定需要集成的组件能够按时提供并满足需求。
假定这些组件的运行环境与本系统运行环境不发生冲突，能与本系统兼容。
另外，假定本文档所描述的软件需求均获得了项目双方所有客户的认可且稳定不变。
如果项目后期，客户提出的需求变更超出了本需求规格范围，则将严重影响本系统的设计、开发和程序的稳定。
在本软件需求规格说明书定版之后，客户需求发生了较大变更，变更后的需求规格说明将不在本文档中补充，而以新的版本文档给出。
3功能需求
[本章应包括所有的软件需求，其详细程度应使设计人员能够设计出可以满足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求。
当利用用例建模时，这些需求在用例说明和适用的补充规约中记录。
如果没有利用用例建模，则可以将补充规约的概要直接插入本节。
详细列出与该特性相关的详细功能需求。
这些是必须提交给用户的软件功能，使用户可以使用所提供的特性执行服务或者使用所指定的使用实例执行任务。
描述产品如何响应可预知的出错条件或者非法输入或动作。
必须唯一地标识每个需求，并标识出优先级。
]
系统用例图
[以用例图的形式展示整个软件系统的功能结构，该用例图包括所有用例和角色，如果用例数量非常大无法一一展示，先以用例包的形式提供，然后在各章节中详细展开。
应分层次展示整个系统的功能，先从系统――>子系统――>模块逐层展示，并说明各子系统和模块之间的功能关系。
同时，应注意与外部系统的接口。
]
以下图示仅作为示范，不具备任何实例性质，供需求分析人员参考而已。
注：
此图仅表示整个系统内的所有用例及其之间的关系。
如果用例太多无法全部展示，可采用用例包的形式。
本系统用例图以薪水支付系统为例，仅供参考。
或者以用例包的形式展现整个系统的功能：
系统用例清单
[以表格的形式列出本软件系统所有的用例清单，具体格式如下：
示范：
―――仅供参考，不具备任何实质性的内容。
需求章节
用例数
用例编号
用例名称
简要描述
优先级
4.3课程注册管理
8
LDAP-UC-101
登录系统
描述用户如何登录课程注册系统
高
LDAP-UC-102
查看成绩单
允许学生在学期结束前查看成绩单
高
LDAP-UC-103
注册课程
允许学生向课程目录中注册课程，也包括更新、删除课程等
高
LDAP-UC-104
选择讲授课程
允许教授在下学期到来之前，从课程目录中选择符合自己的课程
高
……
……
……
……
LDAP-UC-201
注：
以上表格所示内容是以课程注册管理子系统为例。
流水号第一位表示子系统的编号。
<课程注册管理> ――示例
3.1.1功能简述――示例
[简要描述本子系统的主要功能，并以用例图展示子系统。
]
示范：
―――仅供参考，不具备任何实质性的内容。
业务定制功能组将提供数据库结构定义、数据采集接口规范自定义以及基础数据管理功能，具有灵活易用、功能强大的特点，是用户创建数据库资源并对采集业务进行定制集成管理工具。
以下图示仅作为示范，不具备任何实例性质，供需求分析人员参考而已。
此图仅表示子系统内的所有用例及其之间的关系。
如果用例太多无法全部展示，可采用用例包的形式。
3.1.2用例清单――示例
[以表格的形式列出<章节名称>所有的用例清单，具体格式如下：
用例编号
用例名称
简要描述
优先级
LDAP-UC-101
登录系统
描述用户（学生、教授、注册员）如何登录课程注册系统
高
LDAP-UC-102
查看成绩单
允许学生在学期结束前查看成绩单
高
LDAP-UC-103
注册课程
允许学生向课程目录中注册课程，也包括更新、删除课程等
高
LDAP-UC-104
选择讲授课程
允许教授在下学期到来之前，从课程目录中选择符合自己的课程
高
……
……
3.1.3<登录系统>――示例
[在用例建模过程中，用例通常会定义系统的大部分功能性需求，以及一些非功能性需求。
注意：
如果用例作为单独文件保存，则应按照《用例说明》模板编写；如果在这里引用或附加，则应按照以下用例描述格式进行编写。
]――编写时，直接删除此处内容。
[说明中应简要表述用例的作用和目的，并列出本用例的参与者。
]
示范：
―――仅供参考，不具备任何实质性的内容。
本用例描述一个参与者（学生、教授、注册员）如何成功登录课程注册系统。
3.1.3.1参与者
[简要列出本用例的参与者。
]
示范：
―――仅供参考，不具备任何实质性的内容。
学生、教授、注册员
3.1.3.2前置条件
[用例的前置条件是执行用例之前必须存在的系统状态。
一般指执行本用例的前提条件。
]
示范：
―――仅供参考，不具备任何实质性的内容。
无。
3.1.3.3事件流程
[以流程图的形式提供事件流程。
]
以下图示仅作为示范，不具备任何实例性质，供需求分析人员参考而已。
此图是用RationalRose工具画的事件流程图，当然也可以用Visio来画事件流程图，只要能说明事件流程即可。
对于简单的事件流程图，也可以省略不画。
3.1.3.3.1基本流程
[当主角有所行动时，此用例随即开始。
总是由主角来带动用例。
用例应说明主角的行为及系统的响应。
应按照主角与系统进行对话的形式来逐步引入用例。
用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。
如果进行了信息交换，则需指出来回传递的具体信息。
例如，只表述主角输入了客户信息就不够明确。
最好明确地说主角输入了客户姓名和地址。
通常可以利用词汇表让用例的复杂性保持在可控范围内。
您最好在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。
简单的分支流程可以在用例文本中提供。
如果只需几句话就可说明存在分支流程时将发生的事件，则可以直接在事件流程一节中说明。
如果分支流程较为复杂，则需要用另外一节来单独说明。
例如，分支流程小节解释如何说明较复杂的分支流程。
虽然清晰明了的叙述性文字是无可替代的，但有时一幅图要比千言短文更具说明性。
只要表达得简洁明了，您就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。
如果流程图有助于描述复杂的决策流程，那么一定要充分利用它！
同样，对于与状态相关的行为，状态转移图通常比数页文字更能清晰地描述系统的行为。
根据问题来选用妥当的表示方法，但应慎用您的读者可能不太明了的术语、符号或图形。
请切记，您的目的是要阐明问题，而不是混淆问题。
]
示范：
―――仅供参考，不具备任何实质性的内容。
当该actor想要登录进入课程注册系统时，本用例开始。
1. 系统请求该actor输入他或她的用户名和口令；
2. 该actor输入他或她的用户名和口令；
3. 系统验证该actor输入的用户名和口令，并将该actor登录信息记入系统日志中。
3.1.3.3.2分支流程
[较复杂的分支流程应单独说明，这已在事件流程一节的基本流小节中提及。
将分支流程小节当作备选行为在许多情况下，由于主事件流程中发生异常事件，这时每个分支流程都可代表备选行为。
这些分支流程的长度可以是说明与备选行为相关的事件所需的长度。
当分支流程结束时，除非另外说明，主事件流程的事件将重新开始。
]
示范：
―――仅供参考，不具备任何实质性的内容。
1. 无效用户名和或口令
在基本流程中，如果该actor输入一个无效的用户名和或口令，系统应显示一个错误消息。
该actor能够选择重新恢复到基本流程开始（第1步）或取消登录，直到本用例结束。
3.1.3.4特殊需求
[特殊需求通常是非功能性需求，它为一个用例所专有，但很难或很自然的在用例的事件流程文本中表述。
特殊需求的示例包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求）。
此外，其他需求如操作系统及环境、兼容性需求和设计约束也应在此节中记录。
]
示范：
―――仅供参考，不具备任何实质性的内容。
无。
3.1.3.5后置条件
[用例的后置条件是用例一执行完毕系统可能处于的一组状态。
一般指本用例执行后的结果。
]
示范：
―――仅供参考，不具备任何实质性的内容。
如果该actor成功登录进入课程注册系统，本用例结束；如果登录不成功，则系统状态不发生变化。
3.1.3.6扩展点
[扩展点在事件流程中所处位置的定义。
扩展点主要是界定本用例与其它用例的接口，说明在本用例事件流程的哪一步扩展到其它用例。
]
示范：
―――仅供参考，不具备任何实质性的内容。
无。
3.1.3.7补充说明
[对基本流程、分支流程中的一些关键数据信息作进一步的补充性说明。
]
示范：
―――仅供参考，不具备任何实质性的内容。
无。
3.1.4<注册课程>――示例
本用例描述允许某个学生在当前学期为课程表注册课程。
在新学期开始之初，允许学生能更新和删除已选的课程，只要在增加或减少课程的期间。
课程目录系统为本学期所有课程表提供一个清单列表。
3.1.4.1参与者
已注册的本校学生。
3.1.4.2前置条件
在开始本用例前，学生必须成功登录到系统。
3.1.4.3事件流程
[以流程图的形式提供事件流程。
]
以下图示仅作为示范，不具备任何实例性质，供需求分析人员参考而已。
此图是用RationalRose工具画的事件流程图，当然也可以用Visio来画事件流程图，只要能说明事件流程即可。
对于简单的事件流程图，可以省略不画。
3.1.4.3.1 基本流程
当某个学生想要注册课程或改变他/她现有课程时间表时，本用例开始。
1. 系统要求学生指定他/她意欲执行的功能（创建一个课程、更新一个课程、删除一个课程）。
2. 一旦学生向系统提供了被请求的信息，系统将执行以下某个子流程：
1） 如果注册者选择“创建一个课程”，则系统执行“创建一个课程表”子流程；
2） 如果注册者选择“更新一个课程”，则系统执行“更新一个课程表”子流程；
3） 如果注册者选择“删除一个课程”，则系统执行“删除一个课程表”子流程；
创建一个课程表
1. 系统从课程目录系统重新得到一个可用的课程列表，并显示给学生；
2. 学生从当前可用的课程列表中选择“提交课程表”形成初步的课程表，选择“更新一个课程表”改变课程表；
3. 一旦学生改变他/她的选择，系统就为学生创建一个定制的选修课课程表；
4. 执行“提交课程表”子流程。
更新一个课程表
1. 系统重新得到并显示学生当前课程表（例如，当前学期的课程表）；
2. 系统从课程目录系统重新得到一个可用的课程列表，并显示给学生；
3. 学生通过删除和添加新课程来更新当前已经选择的课程。
学生从可用的课程列表中选择添加课程，也可以从现有课程表中删除任何课程。
4. 一旦学生改变他/她的选择，系统就为学生更新正在使用的选修课的课程表；
5. 执行“提交课程表”子流程。
删除一个课程表
1. 系统重新得到并显示学生当前课程表（例如，当前学期的课程表）；
2. 系统提示学生以确定删除课程表；
3. 学生核实删除；
4. 系统删除课程表，如果课程表包含在“已登记”课程列表中，学生必须从课程列表中删除。
提交课程表
对于每个选修课列表中还没有标记“已登记”的课程，系统首先必须验证（必须的先决条件）课程列表对该学生是开放的，并没有课程冲突。
然后，系统添加学生已选择的课程列表。
课程列表中的课程被标记为“已登记”。
同时，该课程被保存在系统中。
3.1.4.3.2分支流程
保存课程
在任何时候，学生能够保存课程而不是提交。
如果这种情况出现，提交课程表步骤被后继步骤替换。
课程列表中的课程不被标记“已登记”，而被标记为“已选择”。
课程被保存在系统中。
无法履行先决条件、课程排满、课程表冲突
如果在“提交课程表”子流程中，系统判定学生不符合必要的先决条件，或者选修课已经排满，或者课程表冲突，系统应显示一个错误消息。
学生能够选择一个不同的课程列表，并继续本用例。
保存课程表，进入“保存课程表”分支流程，或者取消操作，从基本流程重新开始。
没有发现课程表
如果在“更新一个课程表”或“删除一个课程表”子流程中，系统不能重新得到学生的课程表，系统应显示一个错误消息。
学生确认错误信息并重新开始基本流程。
课程目录系统失效
如果系统不能与课程目录系统通信，系统将显示一个错误信息给学生。
学生确认错误信息并结束本用例。
课程注册已关闭
当本用例开始时，如果本学期课程注册已经被关闭了，应给学生提示信息并结束本用例。
本学期课程注册被关
升级会员 