需求规格说明书.docx
- 文档编号:12225908
- 上传时间:2023-04-17
- 格式:DOCX
- 页数:13
- 大小:21.52KB
需求规格说明书.docx
《需求规格说明书.docx》由会员分享,可在线阅读,更多相关《需求规格说明书.docx(13页珍藏版)》请在冰豆网上搜索。
需求规格说明书
xx项目
需求规格说明书
xx公司
xxxx年xx月xx日
版本:
变更记录
序号
版本
变更说明
修改人/日期
检查人/日期
审批人/日期
1引言
在概述部分应对整个系统进行概要描述。
通常还包括目的、适用范围、预期读者和阅读建议、术语定义和参考资料等。
1.1目的
此处描述本软件需求规格说明书的目的。
本需求说明旨在对xx平台的功能架构及子系统的功能需求、非功能需求进行逐一分析;并对各系统接口、质量需求、文档需求和约束做出可行方案。
本需求规格说明书编写目的:
(1)在需求调研阶段,通过本文档,与系统用户进行系统需求的确认。
(2)在系统设计阶段,通过本文档,指导该系统的概要设计和数据库设计。
(3)在系统开发阶段,通过本文档,帮助相关人员全面了解用户需求与系统功能。
(4)系统测试和联调阶段,通过该文档,是编写测试用例的依据。
(5)在系统实施阶段,实施人员借助本文档完成系统的实施工作。
(6)在系统使用过程中,本文档作为用户使用的辅助说明文件。
(7)在系统验收阶段,本文档将作为主要验收依据。
1.2适用范围
本文档适用于所有与本项目有关的软件开发阶段及其相关人员,其中:
客户代表、项目经理、技术开发人员(包括系统分析人员、系统设计人员、开发人员)、测试人员应重点阅读本文档各部分,其他人员可选择性阅读本文档。
1.3预期读者和阅读建议
根据读者角色的不同,给予不同的阅读建议。
预期读者
阅读建议
1.4术语和缩略语
定义所使用的术语。
对于易混淆的客户常用语要有明确规定定义。
例如,“用户”是指客户的雇员而非软件的最终购买者等。
缩略语/术语
全称
说明
1.5参考资料
列出相关的参考资料信息。
文档名
版本号
发表日期
来源
文档简称
1.6需求描述约定
本章节用于说明本文描述需求的约定,这些约定主要包括:
1)需求标识方法:
“需求编号”的格式为:
X-YYY-ZZZ,其中A代表电子商务,B为业务管理门户,YYY表示3位主功能模块码,ZZZ为3位子功能模块码。
需求层次:
分三个层次,第一层需求指主功能模块,第二层需求指功能模块的子功能,第三层次指子功能下的具体需求。
2)需求跟踪的颗粒度:
跟踪到第二层功能需求。
3)需求优先级定义:
本文档统一规定对需求层次为二级以上的定义优先级,三层需求依据二层需求的优先级执行。
需求分析师应确定每个需求的优先级并写入软件需求分析说明书,需求的优先级的评价标准如下:
级别定义
判断标准
采取的措施
高
满足以下任意一条时:
1、需求实现的紧急程度为特急或紧急
2国家或行业法律法规、标准要求的,客户明确要求的,满足正常业务必须的。
对于这些需求在项目实施过程中需重点投入资源,优先实现,只有在这些需求上达成一致意见,软件才会被接受;必须完美地实现。
通常这类需求在当前版本必须实现。
中
满足以下任意一条时:
1、客户隐含要求,对正常业务影响程度不大
2、需求实现的紧急程度为中
3、支持必要的系统操作,实现这些需求将增强产品的性能,是产品最终所要求的。
这些需求必须被实现,但如果项目实施中出现进度、资源等方面的冲突时,如果有必要,可以延迟到下一版本;需要付出努力,但不必做得太完美。
低
满足以下任意一条时:
1、功能或质量上的附加功能;
2、实现这些需求会使产品更完美,若不实现也不影响产品的功能与性能,属于锦上添花;
3、求实现的紧急程度为低。
实现或不实现均可;可以在项目组有较足够的时间时考虑这些需求的实现
2项目概述
2.1简介
简单介绍项目,包括其项目背景,定义和意义等。
2.2用户与角色
确定系统的使用用户和角色,以及其描述。
用户/角色
描述
2.3应当遵循的标准或规范
系统需要遵循的相关标准和规范。
2.4功能总体设计
2.4.1功能架构图
用图形的方式描述系统的总体的功能架构图,并适当辅以文字描述。
2.4.2功能列表
汇总xx项目的各子系统、各功能模块和子功能的需求编号和优先级。
子系统
功能模块
子功能
需求编号
优先级
高
高
高
中
高
xx子系统
高
高
高
高
高
高
高
高
中
高
高
高
2.5核心业务流程
2.5.1核心业务流程1
用基本流程图和跨职能流程图描述核心的业务流程,并辅以文字对核心流程进行详细描述。
2.5.2核心业务流程2
用基本流程图和跨职能流程图描述核心的业务流程,并辅以文字对核心流程进行详细描述。
2.5.3核心业务流程3
用基本流程图和跨职能流程图描述核心的业务流程,并辅以文字对核心流程进行详细描述。
2.6核心用例图
2.6.1用例图1
对核心用例使用用例图图形表示,并可辅以适当的文字说明。
2.6.2用例图2
对核心用例使用用例图图形表示,并可辅以适当的文字说明。
2.6.3用例图3
对核心用例使用用例图图形表示,并可辅以适当的文字说明。
3功能性需求
在这一部分应对所有的软件需求进行足够详细的描述。
详尽程度应以足够软件设计人员进行概要设计和系统测试人员进行系统测试计划和编写测试用例为准。
按系统功能的体系结构组织本章内容。
3.1xx1子系统
3.1.1功能模块A
在这一部分应对所有的软件的功能需求进行足够详细的描述。
各功能应用普通文字或图表描述。
并同时指出功能实现与业务需求的关系,即此功能实现了哪一部份的业务需求。
3.1.1.1功能1
3.1.1.1.1业务需求编号
注:
此编号指《业务需求说明书》附录一:
业务需求编号。
3.1.1.1.2功能编号
注:
此编号为功能设计的唯一编号,用于功能的唯一标识。
3.1.1.1.3业务概述
注:
可以按照STAR原则进行描述,及在什么情况下需要完成怎样的任务,进行怎样的操作达到怎样的结果。
3.1.1.1.4使用者
注:
需要说明哪些用户参与此功能活动,可以通过矩阵进行描述。
3.1.1.1.5输入要素
包括主要的页面描述。
3.1.1.1.6处理流程
注:
需要描述业务流程的入口条件、跳转条件、执行结果、规则要求。
3.1.1.1.7输出要素
包括主要的页面、报表、输出数据等的描述。
3.1.2功能模块B
3.2xx2子系统
4非功能性需求
在这一部分应对所有的软件需求进行足够详细的描述。
详尽程度应以足够软件设计人员进行概要设计和系统测试人员进行系统测试计划和编写测试用例为准。
4.1质量需求
4.1.1可用性
用户使用的方便性、易用性和易学习性,如:
1.输入的无合法性检查和值域检查
2.对于复杂的动作要有必要的提示信息
3.记忆用户的设置或操作习惯,方便用户操作
4.对系统或数据进行重大修改,要有用户确认
4.1.2可靠性和健壮性
在这一部分应对所有的影响软件的可靠性需求进行足够详细的描述。
应注意用数字说明所要求的可靠程度。
同时避免如“24x7”这样的陈述。
例如使用年度正常运行时间、月正常运行时间、维护时间、当机时间来说明系统的可靠程度;使用可允许的缺陷数量来界定系统质量,如最大缺陷数量、缺陷比例、安全操作——系统强壮性要求和操作的有效性要求,比如用户误操作的系统容错能力、操作的正常次序要求和有效性输入检查等等。
通常给出平均无故障时间或两次故障间的平均间隔时间等。
4.1.3可维护性
规定若干需求以确保软件是可维护的。
例如:
1.软件模块所需要的特殊的耦合矩阵;
2.使用行业标准、编码标准、开放式结构、可兼容语言、备份及复原和数据交换等。
3.规定把软件从一种环境移植到另一种环境所要求的用户程序,用户接口兼容方面的约束。
4.1.4可扩展性
说明该软件在需求或环境发生某些变化时,该软件对这些变化的适应能力的要求,如:
1.需求及流程变化;
2.操作方式变化;
3.机构人员变化;
4.空间地点变化(移动用户、分布式);
5.操作系统环境变化。
4.1.5性能
性能需求表示用户对系统响应速度、处理能力、数据处理精度以及可靠性等指标的要求。
一般性能需求分类如下:
处理速度——要给出关键交互界面的业务处理速度的量化时间和输入数据次数,如简单查询响应时间、动态查询响应时间、后台处理效率等,以便以后测试人员验证。
处理结果的精度要求——按照不同的业务数据要求,给出相关数据小数点保留位数和累加后数据的误差范围。
产品处理的存储空间要求以及磁盘容量要求,如系统需要保留多少年的数据量等
数据的值域要求
事务处理的吞吐量要求
资源使用的有效性要求:
比如CPU、内存、表的填充因子等
以上方面的扩展要求
4.1.6易用性
4.1.7安全性
指的是保护软件的要素,以防止各种非法的访问、使用、修改、破坏或者泄密。
这个领域的具体需求产品的安全性、保密性和完整性三方面需求。
例如:
要求对接入系统的用户进行身份验证。
对不同角色的用户设置不同的权限,通过角色定义实现不同角色个性化菜单的定制,有效控制用户的功能权限。
系统应提供日志记录和管理功能,记录所有用户访问系统的全部活动,并能够形成审计报告。
要求在传输过程中对数据进行加密处理,保证数据传输的安全性和完整性。
系统应具备病毒防范能力。
防止主机崩溃方法和数据备份方法等。
4.2约束
详细说明对系统的设计局限性。
设计局限的定义代表了对系统要求的决策,这可能出于商务运作、资金、人员、时间等多方面的综合考虑从而指导软件的设计和开发。
例如,软件的开发语言、开发环境、开发工具、第三方软件、硬件使用以及网络设备等。
4.2.1<约束要求1>
4.2.2<约束要求2>
4.2.3<约束要求2>
4.3接口需求
详细说明对系统的用户界面等的要求。
还可包括和其它系统的接口、地址、协议等。
4.3.1用户接口
提供用户使用软件产品时的接口需求。
例如,如果系统的用户通过客户端进行操作,就必须指定如下要求:
对屏幕格式的要求;
报表或菜单的页面、打印格式等用户对软件外观风格的一种要求。
如:
公司标志,界面色彩基调等。
规格的定义方式可以采用草图或静态原型的方式表示,一般描述分为两个部分:
整体描述和基于每个界面的细节描述。
输入输出的相对时间;
程序功能键的可用性。
4.3.2硬件接口
要指出软件产品和系统硬部件之间每一个接口的逻辑特点和交互方式。
还可能包括如下事宜:
支撑什么样的设备,如何支撑这些设备,有何约定。
4.3.3软件接口
在此要指定需使用的其他软件产品(例如,数据管理系统、操作系统或有关软件包),以及同其他应用系统之间的接口。
对每一个所需的软件产品,要提供如下内容:
2.名字;
3.助记符;
4.规格说明号;
5.版本号;
6.来源。
对于每一个接口,这部分应说明与软件产品相关的接口软件的目的,并根据信息的内容和格式定义接口,但不必详细描述任何已有完整文件的接口,只要引用定义该接口的文件即可。
4.3.4通讯接口
指定各种通信接口。
例如,局部网络的协议等等。
4.4技术需求
4.4.1软硬件环境需求
4.4.2运行保障需求
运行保障需求,主要从系统推广、运行后日常维护角度进行考虑,包括硬件、系统软件、应用软件、数据备份等的运行保障。
1、对硬件,特别是应用服务器和数据库服务器,要求一般故障能够在?
天之内予以解决;对于硬件重大故障,要求在?
星期之内予以解决。
另外,要对系统数据量做出正确估算,预测硬件需要升级的时间点。
2、系统软件,主要指操作系统及数据库软件,对一般问题能在?
?
分钟以内予以解决,对重大问题在?
天之内予以解决。
3、支撑软件产品。
本系统需要以下软件产品:
……旦出现使用问题,有关公司应在最短时间内到现场予以解决。
4、应用软件。
应用软件出现问题后,有关人员能及时到位,在最短时间内查找问题原因,予以解决。
5、数据备份。
对系统数据制定备份策略,定期进行数据备份与保管。
零级备份每?
做一次。
增量备份针对于一定时期内发生变化的数据。
譬如:
有重大事件发生时等。
6、系统对效率要求如何,应认真计算网上传输数据量,计算系统对网络带宽的要求。
4.5文档需求
5验收标准
详细说明对系统的验收要求。
此要求将作为验收测试计划和测试的基线。
如果所开发的产品能满足此要求,则项目可结束并由客户方按合同规定付款。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 需求 规格 说明书