用户需求规格说明书

XXXX项目用户需求规格说明书［填写说明：模板中用方括号括起来并以蓝色斜体显示的文本，用于向作者提供指导，在文档编辑完成后应该将其删除。文档正文应使用常规、黑色、五号字体即系统设置的“正文”样式文档页眉处的〃赵赵系统〃和“版本号”仅为示例，请注意更新封页与页眉符合实际情况。此处的版本号指的是产品版本号封页简要表中的产品名，如无可以不填写。当某一章/节没有内容时，必须注明N/4,同时标注理由。例如：本章/节内容无需考虑。特别说明：当某章节内容参见其它文档时，不能注明N〃，而应该写明参见某文档的具体章节。］项目名称项目编号项目经理文档编号文档版本V1.0编制审批EPG郑州******公司版权所有内部资料注意保密修订记录：版本号修订人修订日期修订描述V1.0创建目录TOC\o"1-5"\h\z\o"CurrentDocument"1.引言 1\o"CurrentDocument"1.1 目的 1\o"CurrentDocument"1.2 背景 1\o"CurrentDocument"1.3 参考资料 1\o"CurrentDocument"1.4 缩略语和术语 1\o"CurrentDocument"2.任务概述 1\o"CurrentDocument"2.1 目标 1\o"CurrentDocument"系统（或用户）的特点 2\o"CurrentDocument"3.假定和约束 2\o"CurrentDocument"需求规定 2\o"CurrentDocument"4.1 概述 2\o"CurrentDocument"功能需求 2\o"CurrentDocument"业务用例1 3\o"CurrentDocument"业务用例2 4\o"CurrentDocument"业务用例n 5\o"CurrentDocument"非功能需求 6\o"CurrentDocument"系统/产品的外观需求 6\o"CurrentDocument"易用性需求 6\o"CurrentDocument"执行需求 6\o"CurrentDocument"操作和环境需求 7\o"CurrentDocument"可维护性 7\o"CurrentDocument"4.3.6 安全性与保密性 7\o"CurrentDocument"4.3.7 安全审计 7\o"CurrentDocument"4.3.8 产品应执行的标准和/或政策: 7\o"CurrentDocument"4.3.9 其他 7\o"CurrentDocument"接口 8\o"CurrentDocument"文档需求 8\o"CurrentDocument"用户手册 8\o"CurrentDocument"联机帮助 8\o"CurrentDocument"5.3安装指南、配置文件、自述文件 8\o"CurrentDocument"尚需解决的问题 8\o"CurrentDocument"附录 91.引言1.1目的［说明编写本文档的目的，指出预期的读者。］1.2背景［指出待开发的软件系统的名称；行业情况；本项目的任务提出者、开发者、用户；该软件系统同其他系统或其他机构的基本的相互来往关系。］1.3参考资料［列出编写本报告时参考的文件（如经核准的任务书或合同、上级机关的批文等）、资料、技术标准等。］1.4缩略语和术语［提供与此文档相关的术语及缩略语的定义。］缩略语/术语全称说明2.任务概述2.1目标［叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中的其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。］2.2系统（或用户）的特点［列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件预期使用频度。这些是软件设计工作的重要约束。如果是对现有系统的优化、升级和/或增强开发，还应列出本软件与老版本软件的比较和不同之处。另外，还要说明本软件被预期使用频度。］3.假定和约束［列出进行本软件开发工作的假定和约束，例如必须采取的系统架构、必须使用的技术/工具/方法论等。如果项目有特殊的关于进度、资金等方面的限制条件，也请一并列出。］4.需求规定4.1概述［系统整体的业务的描述，和/或各个业务流程、业务模型的描述。可以使用UseCase图、泳道图、数据流图等任意一种工具或者工具组合来描述。］4.2功能需求［逐项定量和定性地叙述对系统所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明产品的容量，包括系统应支持的终端数和应支持的并行操作的用户数等指标。可以以更细的章节划分来分组描述需求集合，例如：按照用户的角色。建议采用业务用例描述。对于简单的功能需求，如简单的查询功能，一般

处理步骤在三步以内，使用输入输出方式描述，如业务用例2；］4.2.1业务用例1用例编号用例标题参与者（用例的使用者，可以是人，也可以是其他系统用例描述（用例所完成基本功能的概要描述前置条件（完成功能所需要的基本保证。例如：本用例能够成功执行前第XX号用例的成功事件流已经执行完毕。］后置条件（完成功能后所需要的基本保证、执行完毕后达到的目的。例如：系统初始化完毕。］正常事件流（按照正常条件下的执行顺序，系统的行为以及与使用者之间的交互，描述的格式为：1.2.3.4.…］可选事件流可能岀现的行为或反馈的步骤，描述的格式为：5.异常事件流在某步骤岀现异常条件时的执行顺序，在描述的格式上与正常事件流有关联关系，例如：正常事件流的第2个步骤岀现异常分支，则描述的格式为：2a1.2a2.使用/触发业务用例（与其他用例之间的关联关系，其中：使用：该用例的完整执行需要调用其它用例；触发：该用例的执行结果会触发其它用例的执行优先级［必须/可选/便利恂使用频度［如：大约400个用户，平均每天使用次业务规则特殊的业务规则，必须要遵循的，例如：“查询结果的输岀，人名排列顺序缺省的按照姓氏英文字母排列顺序；部门排列顺序缺省的按照公司通讯录所标注的顺序。”

业务规则可以作为文档单列为附录，或者作为本章的一个独立章节，采用唯 的编号区别不同的业务规则，例如：BR-1,BR-2,BR-3,BR-4,BR-8,BR-11,BR-12,BR-33］特别要求特别的要求，必须要满足的，例如：“输入日期时必须采用日历控件，由用户选择输入，而不是文本输入”未决问题没有得到用户确认、或者在需求调研时缺失的问题，需要补充调研活动4.2.2业务用例2用例编号用例标题参与者（用例的使用者，可以是人，也可以是其他系统用例描述（用例所完成基本功能的概要描述输入（对该功能所有输入数据的描述。包括数据字段，格式要求处理（对输入数据所执行的所有操作和如何获得输岀的过程。包括正常分支和异常分支］输出（对该功能所有输岀数据的描述。包括输岀到何处（如界面，文件或打印机），数据字段和格式要求使用/触发业务用例（与其他用例之间的关联关系，其中：使用：该用例的完整执行需要调用其它用例；触发：该用例的执行结果会触发其它用例的执行优先级［必须/可选/便利恂使用频度［如：大约400个用户，平均每天使用次业务规则特殊的业务规则，必须要遵循的，例如：“查询结果的输岀，人名排列顺序缺省的按照姓氏英文字母排列顺序；部门排列顺序缺省的按照公司通讯录所标注的顺序。”业务规则可以作为文档单列为附录，或者作为本章的一个独立章节，采用唯的编号区别不同的业务规则，例如：BR-1,BR-2,BR-3,BR-4,BR-8,BR-11,BR-12,BR-33］特别要求特别的要求，必须要满足的，例如：“输入日期时必须采用日历控件，由用户选择输入，而不是文本输入”未决问题没有得到用户确认、或者在需求调研时缺失的问题，需要补充调研活动

4.2.3业务用例n用例编号用例标题参与者（用例的使用者，可以是人，也可以是其他系统用例描述（用例所完成基本功能的概要描述前置条件（完成功能所需要的基本保询后置条件（完成功能后所需要的基本保询正常事件流（按照正常条件下的执行顺序，系统的行为以及与使用者之间的交互，描述的格式为：1.2.3.4.…]可选事件流可能岀现的行为或反馈的步骤，描述的格式为：5.异常事件流在某步骤岀现异常条件时的执行顺序，在描述的格式上与正常事件流有关联关系，例如：正常事件流的第2个步骤岀现异常分支，则描述的格式为：2a1.2a2.使用/触发业务用例（与其他用例之间的关联关系，其中：使用：该用例的完整执行需要调用其它用例；触发：该用例的执行结果会触发其它用例的执行优先级使用频度[如：大约400个用户，平均每天使用次业务规则特殊的业务规则，必须要遵循的，例如：“查询结果的输岀，人名排列顺序缺省的按照姓氏英文字母排列顺序；部门排列顺序缺省的按照公司通讯录所标注的顺序。业务规则可以作为文档单列为附录，或者作为本章的一个独立章节，采用唯的编号区别不同的业务规则，例如：BR-1,BR-2,BR-3,BR-4,BR-8,BR-11,BR-12,BR-33]特别要求特别的要求，必须要满足的，例如：“输入日期时必须米用日历控件，由用户选择输入，而不是文本输入”未决问题没有得到用户确认、或者在需求调研时缺失的问题，需要补充调研活动4.3非功能需求［本处罗列出对系统的所有非功能需求。如果下列某一项非功能性需求没有特别的要求，请注明“无”，并说明原因］4.3.1系统/产品的外观需求［本处列举在系统/产品应满足的用户在外在感官上的要求和/或约束条件，例如：•产品应符合Vista风格。注意：如果产品/系统针对特殊的客户群体而开发，对外观上会有特殊的需求，例如：针对儿童开发的软件需要动画卡通界面以提高吸引力。］4.3.2易用性需求［本处列举在系统/产品在被应用时需要在可操作性、可用性满足的需求，例如：•系统界面提供英语和简体中文两种文字在定义易用性需求的时候，需要考虑目标用户的能力、相关知识水平与计算机使用经验。］4.3.3执行需求［产品/系统在性能、操作与使用的安全性、效率、稳定性、可靠性、容错能力和/或健壮性上应满足的需求，例如：产品的容量：系统的同时支持的最大能力是处理5000条呼叫的容量；完成任务的速度：非报表类的查询操作，应在不小于5秒钟内执行完毕；结果的速度；•资源使用的效率；（CPU、内存的使用率）允许的值的范围；可靠性：通常使用两次故障间的平均无故障时间MTBF）来度量和表述；可用性：不停机而供用户使用的时间、是否需要双机热备份等］4.3.4操作和环境需求［描述产品在操作环境（物理的或者是逻辑的）上应满足的特殊要求，例如：本产品的正常工作环境是—10°c〜〜+40°C；用户要求必须提供分别在MacOS和Windows两种操作系统下运彳丁的产品版本；产品应该提供与热像图数据库的接口］4.3.5可维护性［描述系统/产品的可移植性、可扩展性、可配置性需求。例如：未来三年之内使用本系统的用户在现有基础上会扩展2倍。］4.3.6安全性与保密性［描述系统/产品对于系统安全、数据安全、信息安全和网络安全等方面的需求，保证数据不能为被授权用户以外的任何人访问，保证被授权的用户可以不受阻止的访问数据。］4.3.7安全审计［描述系统通过日志进丁安全审计的需求，安全日志分为访问日志和操作日志，其中访问日志记录了所有对重要功能访问的详细信息，操作日志记录了对一些关键信息操作的情况。日志审计是事后安全审计的重要手段，通过安全日志可以追溯出引起安全事项的原因（包括操作人及操作的详细情况）。4.3.8产品应执丁的标准和/或政策:［产品所必须遵守的特定的法律、法规、国家产业政策、丁业标准等］4.3.9其他［其他非功能性需求，例如：由于人的习惯、宗教、语言、禁忌而可能导致的特殊的因素。系统如有其它上述未提及的非功能性需求，也请列举在此。］4.4接口［简要说明该系统同其他系统之间的公共接口、数据通信协议等。］5.文档需求［此节说明为支持成功部署应用程序而必须制作的文档。］5.1用户手册［说明用户手册的目的和内容。讨论预期长度、详细程度，是否需要索引、词汇表、教程与引用手册策略等。还应确定格式和打印约束条件。如用户要求提供电子版《用户操作手册》。］5.2联机帮助［许多应用程序提供了联机帮助系统来协助用户。这些系统的性质对于应用程序开发来说独特的，因为它们综合了编程（如超链接）和技术写作（组织、演示）的各个方面。许多人发现联机帮助系统的开发本身就是一个受益于先