文件编号: QMS—PROC-RD02
版本:1.0
受控签章
| 编写人 | 日期 | 2012-9-10 | |
| 评审 | 评审号/日期 | ||
| 批准 | 状态 | ||
| 发布范围 | 全公司 | ||
| 日期 | 版本 | 作者 | 修改内容 |
| 2012-9-10 | 1.0 | 新建 | |
1.1 目的
说明编写这份软件需求规格说明书的目的,如:通过本文档定义XXX产品的需求,以求在项目组员与相关成员之间达成一致的需求描述。
1.2 背景
描述系统产生的背景,包括:
a.需开发的软件系统的名称,和英文缩写(可选),项目编号(可选);
b.列出此项目的任务提出者、开发者
c.软件系统应用范围、用户。
d.产生该系统需求的原因或起源,如社会背景、市场发展、趋势、原有系统局限性
1.3 术语
列出本文件中用到的专门术语、术语定义、外文首字母组词的原词组。也可用附件说明。或放到本文件的最后。
1.4 预期读者与阅读建议
描述本文档的主要读者,以及这些读者在阅读时的阅读重点与建议。可用列表的方式列出。如:
| 预期读者 | 阅读建议 |
| XX领导层 | 仔细阅读概述,编写目的,文档约定,系统功能介绍和维度指标说明。 |
| XX公司的业务部门、决策部门、具体的使用部门、业务员、系统管理员 | 仔细阅读文档约定,系统功能介绍和维度指标说明。 各个部门可重点阅读与本部门相关的内容。 |
| 参加需求评审的人员 | 仔细阅读全部内容。 |
| 系统设计人员 | 仔细阅读全部内容。 |
| 系统测试人员 | 仔细阅读文档约定,系统功能介绍和维度指标说明。 |
| …… | …… |
列出有关的参考资料,如:
a.本项目经核准的计划任务书或合同、上级机关的批文;
b.属于本项目的其他已发表的文件;
c.本文件中各处引用的文件、资料、包括所要用到的软件开发标准。
d.行业标准和规范。
列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。
| 文档名 | 版本号 | 发表日期 | 来源 | 文档简称 |
在此说明本文描述需求的约定。这些约定可以包括:
●需求标识方法,如序列化编号、层次化编号、层次化文本标签等方法。应确保需求标识在整个项目中的唯一性,且不受需求变更的影响,不得使用WORD自带的序列号作为需求标识
●需求的跟踪颗粒度
●优先级与重要性(本文档中设定的级别,及其含义)
●功能描述的方法。(若引用了参考资料,应指明参考资料的简称与章节号或页码,以便复核与评审。)
●界面描述规则,如:用图形描绘DEMO界面
●等等
根据不同类型、不同规模的项目,项目组可以做出增减。以一个大项目举例如下:
1)本系统的需求标识方法:层次化编号方法
模块缩写+序列号,如SZAG01、SZAG01.01、SZAG01.01.02
模块缩写参照表:
| 模块名 | 模块缩写 | 模块名 | 模块缩写 |
| 深圳A股 | SZAG | 上海A股 | SHAG |
| 深圳B股 | SZBG | 上海B股 | SHBG |
| 电子划拨 | DZHB | 资金清算 | ZJQS |
2)本系统的需求跟踪粒度
跟踪到第二层功能需求。
3)本文档的需求级别定义:
●本文档统一规定对需求层次为二级以上(功能模板、主功能点)的定义优先级,三层需求依据二层需求的优先级执行。
●本文档的优先级别分为:紧急、正常、缓
●同时对于主功能点还描述实现的周期:一期、二期、三期
4)功能描述方法:
本文档从以下几个方面对功能需求进行描述:
a.业务定义/描述。
b.适用的用户类型
c.业务规则/业务要素。
d.输入:提供所有与本功能有关的输入描述,包括:输入数据类型、媒体、格式、数值范围、精度、单位等。
e.输出-提供与本功能有关所有输出的描述,包括:输出数据类型、方式、格式、精度、单位等,以及图形或显示报告的描述。
f.业务操作流程
g.描述正常业务流程,列举异常情况和处理流程。建议使用图示,并配合必要的文字说明
h.约束条件/特殊考虑
列出在各个工作领域不需计算机化的功能并提供其原因以及特殊条件。
5)界面描述规则
界面描述使用VISIO的界面模型进行描述。
2.项目概述
2.1 系统功能
概述了产品所具有的主要功能。其详细内容将在系统功能需求和特性中描述,所以在此只需要概略地总结。很好地组织产品的功能,使每个读者都易于理解。
a.建议以图表形式列出功能结构图,并加入必要文字说明。
b.建议以列表形式列出功能分类,以及优先级,并加入必要文字说明。
2.2 业务描述
用文字或图形方式描述系统的主要业务流程,若引用了参考资料,应指明参考资料的简称与章节号或页码,以便复核与评审。
2.3 数据流程描述 (可选)
用文字或图形方式描述系统的数据流程,若引用了参考资料,应指明参考资料的简称与章节号或页码,以便复核与评审。
2.4 用户的特点
列出本软件的最终用户的特点,以及本软件的预期使用频度,确定可能使用该产品的不同用户类并描述它们相关的特征。有一些需求可能只与特定的用户类相关。一般来说至少有以下几类:
一般操作者:
系统管理者:
最终用户
2.5 运行环境要求
描述了软件的运行环境,包括硬件平台、操作系统和版本,还有其它的软件组件或与其共存的应用程序。
2.6 设计和实现上的
列举出在对软件需求规格说明中影响需求陈述的假设因素(与已知因素相对立)。这可能包括你打算要用的商业组件或有关开发或运行环境的问题对需求实现的影响,也可能是需求或业务规则对设计与实现方法的影响。可能还来自于经费、投资方面的,法律或方面的,或者可利用的资源和信息的。
3.功能需求的描述
〔为每个确定的商业功能(需实现的功能)描述其定义、业务规则,详细叙述如何从输入转变到输出并且如何获得、处理和产生这些信息。这些内容在下列标题中有条理的阐述。
a.业务定义/描述。
b.适用的用户类型,指操作本功能所需的授权
c.业务规则/业务要素。
d.功能项的主要页面或是样式
e.输入:提供所有与本功能有关的输入描述,包括:输入数据类型、媒体、格式、数值范围、精度、单位等。
f.输出-提供与本功能有关所有输出的描述,包括:输出数据类型、方式、格式、精度、单位等,以及图形或显示报告的描述。
g.业务操作流程
描述正常业务流程,列举异常情况和处理流程。建议使用图示,并配合必要的文字说明
h.约束条件/特殊考虑
列出在各个工作领域不需计算机化的功能并提供其原因以及特殊条件。
4.非功能需求
4.1 系统性能要求
a.时间特性
说明对于该软件的时间特性要求,时间测量单位的选择:
●高峰期的环境假设、负载假设;
●高峰期的处理时间。
b.精度要求
说明对该软件的输入、输出数据精度的要求。
c.系统有效性
为取得系统有效性,应考虑标准工作日、周末和公共假期的操作时间。例如:系统每天需要连续运行24小时,每周运行七天,包括公共假期和周末
d.容错性
e.可扩充性
4.2 系统安全及保密要求
指定可以访问各自功能的用户群,如需要可指定用户访问权和安全包(如有),以便有效控制系统访问和数据访问。
确认审核记录和所有有关报告及接受人。阐述是否任何违反系统访问的内容都需要监控,以及以什么方式监控。
列明所有安全需求,例如数据加密,信息验证等。
4.3 系统备份与恢复要求
a.指定每种信息类型的保存期;
b.阐述在保存期过后需要实施的行为,例如:转移到计算机外部的介质中,或删除它们。
c.如转移到计算机外的介质中,叙述存储期及贮存介质的类型。例如:磁带、磁盘、报告等。
d.环境异常时,系统恢复策略描述。
4.4 系统日志
a.日志内容、记录策略
b.日志的保存时长、保存策略
c.日志内容的访问控制
5.外部接口说明
外部接口包括:硬件接口、软件接口、通信接口,每个接口需考虑以下内容:
a.接口描述,包括接口类型、接口特点(如版本、名称、来源等)
b.接口与本系系统的输入输出关系
c.技术方面的约束
d.转换的安全考虑
6.其他需求
[对其它需要描述但未在本模板中列出的需求,在此进行说明,如果某个这样的需求比较重要,可以单独用新的一节来描述。
这样的需求可能包括,数据库需求、法律需求、国际准则、重用目标等。]
7 需求变更识别
识别并定义在将来可能会变化的需求
8.功能列表
罗列本需求中的功能点、需求编号、需求内容、优先级与内容描述。必要时成立做为本需求的附件。
| 功能点 | 子功能 | 需求编号 | 优先级 | 内容描述 |
附件可能包括各个模块的具体的功能需求描述、需求跟踪表,或者系统的词汇表、待确定问题列表,以及其它所有能够成为需求基线内容的正式文档。下载本文