软件需求分析说明书模板

保密级别:S 资料编号:SRS-[产品代号] -[序列号] 版本:V1.0 “知游”在线旅游指导网 [部件型号名称(可选、小二号字体)] 软件需求分析 共X页 编制: 审核: 审定: 会签: 批准: 不知道第几组 2017年3月18日 文档修改记录 目录 1引言 (4) 1.1编写目的 (4) 1.2背景 (4) 1.3项目介绍 (4) 1.4发展趋势 (4) 1.5设计目标 (5) 2项目概述 (3) 2.1产品描述 (3) 2.2产品需求 (4) 2.2.1功能需求 (4) 2.2.2性能需求 (4) 2.2.3可服务性需求 (5) 2.3用户及用户特点 (5) 2.4一般约束 (5) 2.5假设和依据 (6) 3用例描述 (6) 3.1用例1 (6) 3.2用例2 (7) 3.3用例n (7) 4外部接口需求 (7) 4.1用户接口 (7) 4.2硬件接口 (8) 4.3软件接口 (8) 4.4通信接口 (8) 5设计约束 (8) 5.1其他的约束 (8) 5.2硬件的限制 (9) 6属性 (9) 6.1可用性 (9) 6.2安全性 (9) 6.3可维护性 (9) 6.4可转移\转换性 (10) 6.5警告 (10) 7其他需求 (10) 7.1数据库 (10) 7.2操作 (10) 7.3场合适应性需求 (11) 8附录 (11) [说明:本模板中的蓝色字体与橙色字体为说明性文字,在最终提交的文档中请删除这些说明性的文字。] 1 引言 1.1 编写目的 编写此文档的目的是为进行该项目开发的相关人员提供需求分析讨论参考,进一步制定本软件开发的细节问题。并且为本软件的用户提供一个清晰的认识,它说明了本产品的各项功能需求、性能需求和数据要求,明确标识各功能的实现过程,阐述了实用背景及范围,提供客户解决问题或达到目标所需的条件或权能,提供一个度量和遵循的标准。 1.2 背景 随着国民收入水平提高,越来越多的人选择走出家门去旅游。在选择目的地的时候往往会感到困惑;担忧路线不熟悉、费用高昂和旅行社可能存在的一系列宰客行为。本软件为广大游客提供了一个在线及交流的咨询的平台,能够对游客选择旅游路线、旅行社等提供建议和进行规划。 1.3 项目介绍 “知游(zhiyou)”项目是一个能为游客提供交流和咨询旅游相关信息的平台,以网站为主能实现发帖回帖分享咨询等功能。分为“春、夏、秋、冬、国内、国际”几大板块,能为游客选择最合适的出行路线,还能解决一系列出游问题(费用规划、旅行社选择等)。 1.4 发展趋势 发展方向:以在线网站的形式为游客提供交流咨询服务、在将来逐渐加入网上虚拟游、和景区、旅行社合作等功能为用户提供多样化的细致服务。作为第三方平台,将来还可以起到监督之效用。 项目的重点:本项目重点打造成为一个为游客提供交流咨询服务的第三方平台。为了树立口碑、提高知名度,可以前期以非盈利性质进行推广,在拥有一定活跃用户之后再考虑与各行业进行合作。 市场及前景:针对目前相关软件的缺乏和现实社会中游客普遍遇到的问题,本项目有非常庞大的受众和为数不多的潜在对手,发展前景较为理想。 1.5 设计目标 本软件项目的目标是: 1、尽可能的节省开发过程中的费用。 2、提高开发效率,缩短开发时间。 3、使软件易于升级和维护。 4、软件能够长期有效运行。 5、界面美观,方便用户使用。 6、能快速高效地为用户提供帮助和指导建议。 2 项目概述 2.1 产品描述 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件,而且全部内容自含,则说明这一点。如果所定义的产品是一个更大的系统的一个组成 部分,则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 产品需求 2.2.1 功能需求 本条是为将要完成的软件功能提供一个摘要。例如,对于一个记帐程序来说,需求说明可以用这部分来描述:客房帐目维护、客房财务报表和发票制作,而不必把功能所要求的大量的细节描写出来。 有时,如果存在较高层次的规格说明时,则功能摘要可从中取得,这个较高层次的规格说明为软件产品分配了特殊的功能,为了清晰起见,请注意: a.编制功能的一种方法是制作功能表,以便客户或者第一次读这个文件的人都可以理 解; b.用方框图来表达不同的功能和它们的关系也是有帮助的。但应牢记,这样的图不是 产品设计时所需求的,而只是一种有效的解释性的工具。 c.用系统用例图可以表达系统主要功能,如果功能较多,可以按功能分组分几个小节 分别描述。 范例: 2.2.2 性能需求 从整体来说,本条应具体说明软件、或人与软件交互的静态或动态数值需求。 A.静态数值需求可能包括: 1) 支持的终端数; 2) 支持并行操作的用户数; 3) 处理的文卷和记录数; 4) 表和文卷的大小。 B.动态数值需求可能包括:欲处理的事务和任务的数量,以及在正常情况下和峰值工 作条件下一定时间周期中处理的数据总量。 所有这些需求都必须用可以度量的术语来叙述。例如,95%的事务必须在小于1s时间内处理完,不然,操作员将不等待处理的完成。 范例: 2.2.3 可服务性需求 从易于安装与调试方面提出产品的可服务性需求。 2.3 用户及用户特点 列出系统所有可能的用户,建议用UML图表示。 列出本软件的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长,以及本软件的预期使用频度。这些是软件设计工作的重要约束。 2.4 一般约束 本条对设计系统时限制开发者选择的其他一些项作一般性描述。而这些项将限定开发者在设计系统时的任选项。这些包括: a.管理方针; b.硬件的限制; c.与其他应用间的接口; d.并行操作; e.审查功能; f.控制功能; g.所需的高级语言; h.通信; i.应用的临界点; j.安全和保密方面的考虑。 2.5 假设和依据 本条列出影响需求说明中陈述的需求的每一个因素。这些因此不是软件的设计约束,但是它们的改变可能影响到需求说明中的需求。例如:假定一个特定的操作系统是在被软件产品指定的硬件上使用的,然而,事实上这个操作系统是不可能使用的,于是,需求说明就要进行相应的改变。 3 用例描述 下面各节分别描述各用例的具体流程。 3.1 用例1 给出对本用例的概括性说明,这里的说明不仅限于文字,可以给出界面草图、活动流程图等。 按下表的方式描述用例准确过程 3.2 用例2 ..... 3.3 用例n ..... 4 外部接口需求 4.1 用户接口 提供用户使用软件产品时的接口需求。例如,如果系统的用户通过显示终端进行操作,就必须指定如下要求: a.对屏幕格式的要求; b.报表或菜单的页面打印格式和内容; c.输入输出的相对时间; d.程序功能键的可用性。 4.2 硬件接口 要指出软件产品和系统硬部件之间每一个接口的逻辑特点。还可能包括如下事宜:支撑什么样的设备,如何支撑这些设备,有何约定。 4.3 软件接口 在此要指定需使用的其他软件产品(例如,数据管理系统、操作系统或数学软件包),以及同其他应用系统之间的接口。对每一个所需的软件产品,要提供如下内容: a.名字; b.助记符; c.规格说明号; d.版本号; e.来源。 对于每一个接口,这部分应说明与软件产品相关的接口软件的目的,并根据信息的内容和格式定义接口,但不必详细描述任何已有完整文件的接口,只要引用定义该接口的文件即可。 4.4 通信接口 指定各种通信接口。例如,局部网络的协议等等。 5 设计约束 设计约束受其他标准、硬件限制等方面的影响。 5.1 其他标准的约束 本项将指定由现有的标准或规则派生的要求。例如: a.报式; b.数据命名; c.财务处理; d.审计追踪,等等。 5.2 硬件的限制 本项包括在各种硬件约束下运行的软件要求,例如,应该包括: a.硬件配置的特点(接口数,指令系统等); b.内存储器和辅助存储器的容量。 6 属性 在软件的需求之中有若干个属性,以下指出其中的几个(注意:对这些决不应理解为是一个完整的清单)。 6.1 可用性 可以指定一些因素,如检查点、恢复和再启动等,以保证整个系统有一个确定的可用性级别。 6.2 安全性 指的是保护软件的要素,以防止各种非法的访问、使用、修改、破坏或者泄密。这个领域的具体需求必须包括: a.利用可靠的密码技术; b.掌握特定的记录或历史数据集; c.给不同的模块分配不同的功能; d.限定一个程序中某些区域的通信; e.计算临界值的检查和。 6.3 可维护性 规定若干需求以确保软件是可维护的。例如: a.软件模块所需要的特殊的耦合矩阵; b.为微型装置指定特殊的数据\程序分割要求。 6.4 可转移\转换性 规定把软件从一种环境移植到另一种环境所要求的用户程序,用户接口兼容方面的约束等等。 6.5 警告 指定所需属性十分重要,它使得人们能用规定的方法去进行客观的验证。 7 其他需求 根据软件和用户组织的特性等,某些需求放在下面各项中描述。 7.1 数据库 本项对作为产品的一部分进行开发的数据库规定一些需求,它们可能包括: a.在功能需求中标识的信息类别; b.使用的频率; c.存取能力; d.数据元素和文卷描述符; e.数据元素、记录和文卷的关系; f.静态和动态的组织; g.数据保存要求。 注:如果使用一个现有的数据库包,这个包应在“软件接口”中命名,并在那里详细说明其用法。 7.2 操作 这里说明用户要求的常规的和特殊的操作。 A.在用户组织之中各种方式的操作。例如,用户初始化操作; B.交互作用操作的周期和无人操作的周期; C.数据处理运行功能; D.后援和恢复操作。 注:这里的内容有时是用户接口的一部分。 7.3 场合适应性需求 这里包括: a.对给定场合或相关任务或操作方式的任何数据或初始化顺序的需求进行定义。例 如,栅值,安全界限等等。 b.指出场合或相关任务为特点,这里可以被修改以使软件适合特殊配制的要求。 8 附录 对一个实际的需求规格说明来说,若有必要应该编写附录。附录中可能包括: a.输入输出格式样本,成本分析研究的描述或用户调查结果; b.有助于理解需求说明的背景信息; c.软件所解决问题的描述; d.用户历史、背景、经历和操作特点; e.交叉访问表。按先后次序进行编排,使一些不完全的软件需求得以完善; f.特殊的装配指令用于编码和媒体,以满足安全、输出、初始装入或其他要求。 注:当包括附录时,需求说明必须明确地说明附录是不是需求要考虑的部分。