软件需求规格说明书

1、软件需求规格说明书密级: 普通所属项目：日期：作者：关键字：修订记录序号章节名称修订内容简述修订日期修订后版本号修订人1创建2345678910目 录1简介11.1目的11.2范围11.3术语表11.4参考资料12整体说明22.1系统架构22.2模块22.3场景22.3.1<场景1>22.3.2<场景2>22.4假设与约束23功能性需求33.1<功能性需求分类N>33.1.1<功能性需求1>43.1.2<功能性需求2>64接口需求74.1与<其他系统N>的接口75非功能需求85.1性能需求85.2安全性需求85.3界面需求

2、85.4提交产物86环境约束96.1工具需求96.2适用的标准97附录931 简介 需求说明书 (SRS) 的简介应提供整个 SRS 的概述。它应包括此 SRS 的目的、商业价值，范围、定义、首字母缩写词、缩略语、参考资料。1.1 目的阐明此 SRS 的目的。SRS 应详细地说明所确定的应用程序或子系统的外部行为。它还要说明非功能性需求、设计约束以及提供完整、综合的软件需求说明所需的其他因素。1.2 商业价值简要说明该项目可以创造什么样的价值，对于行业/客户/公司有什么作用。1.3 范围简要说明此SRS适用的产品及版本、项目、以及受到此文档影响的任何其他事物。1.4 术语表本小节应提供正确解释

3、此SRS文档所需的全部术语的定义、首字母缩写词和缩略语。 这些信息可以通过引用项目词汇表来提供。建议建立独立的词汇表文档本文档使用的术语如下表：术语解释1.5 参考资料本小节应完整列出此SRS文档中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期（如果有）和出版单位（如果有）。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。编写此文档时参考的资料如下：文档名称文档编号作者发布日期2 整体说明SRS 的这一节应说明影响产品及其需求的一般因素。本节并不列出具体的需求，而只是提供在第 3 节中详述的各种需求的背景，以使这些需求便于理解。2.

4、1 系统架构描述软件系统内部各部分之间以及与其它系统的相互联系，交互方式，包括逻辑架构、物理部署2.2 模块作为第三章的概述，描述软件按照功能划分的模块，用简单的语句描述各个模块的功能。2.3 场景描述主要的用户应用场景，每个场景的每个步骤和发起者要清晰。一个场景要讲述完整连贯的故事，如果必要一个场景可以涉及多个模块。整个场景章节要能覆盖所有的模块2.3.1 <场景1>示例：1. 测试经理从需求文档逐条的摘录出需求，并且通过需求管理->新建需求录入到系统。2. 根据新建此测试项目时输入的开始用例设计时间，系统会在该时间后“锁定”需求。而在这之前，测试经理需要及时获取最新的需求

5、文档，并且及时更改系统中的需求。3. 到了测试用例设计的开始时间，系统会设置该项目的需求被“锁定”了。4. 开始用例设计或者开始测试之后，需求需要修改时，测试经理可以修改此需求，但修改不能立即生效，而是需要提交审核。5. 系统会为审核人添加一个任务，该任务与需求相关联。审核人通过查看“我的任务”可以打开该需求，并且查看修改内容。6. 审核人可以选择“审核通过”或者添加注释并且把任务重新指派给测试经理。7. 直到审核完成后，修改才可以被所有人看到。该需求以及与需求相关联的测试用例会被标注红色以提示相关的测试人员。2.3.2 <场景2>2.4 假设与约束列举出影响需求陈述的假设因素(与

6、己知因素相对立)。如果这些假设因素不正确、不一致或者被修改，就会使软件产品开发项目受到影响。这些假设的因素可能包括： 计划使用的商业组件，或者其它软件中的某个部件； 假定产品中某个用户界面将符合一个特殊的设计约定； 有关本软件用户的若干假定(例如：假定用户会熟练使用SQL语言。)； 有关本软件开发工作的若干假定(例如：用户承诺或上级部门给予的特殊政策和支持等。)； 有关本软件运行环境的一些问题；此外，确定本软件开发项目对外部约束因素所存在的依赖。有关的约束可能包括： 工期约束； 经费约束； 人员约束； 设备约束； 地理位置约束； 其它有关项目约束；3 功能性需求SRS 的这一节应包含所有的功能

7、性需求，其详细程度应使设计人员能够设计出可以满足这些需求的系统，并使测试人员能够测试该系统是否满足这些需求。3.1 <功能性需求分类N>描述该分类的简要说明，以及该分类的用例图。3.1.1 <功能性需求1>先在表格中描述该功能需求的概括，再根据项目特点选择下面分类的几种方式的一种或几种描述。如果下面的几种方式都不合适，可以使用其他您认为合适的描述方式，或者用语言描述详细功能。需求编号SRS.1.1具体描述此说明应该具体该功能的作用和目的。一个段落即足以作此说明。优先级此功能需求的优先级别，分为“高/中/低”入口列出所有的进入该功能的方式，比如：用例管理模块-创建测试用例

8、，需求管理模块-创建测试用例3.1.1.1 功能需求1界面原型示例如果有的话，请绘出功能需求1的界面示例，方式不限，可以是图片、viso图、html等3.1.1.2 功能需求1时序图如果有的话，请绘出功能需求1的时序图等，说明业务流程与各系统模块的交互关系。对于各模块间交互关系简单的功能，可以忽略此节。3.1.1.3 功能需求1数据如果有的话，对系统中各个功能需求中所涉及到的数据项进行描述和定义，对于数值型数据项，说明允许的最大/小值，对于字符型数据项，说明允许的最长/短值，对于要求“唯一”的数据项，请在备注中说明，并说明是否大小写敏感。对于按钮，在备注里说明各种情况下点击按钮后的结果。编号数

9、据项名称输入方式最小长度/值最大长度/值数据格式默认值是否必填备注1工作内容文本框256字符空是若不填应提示输入（下同）2项目名称下拉列表24字符非特定项目是例如：非特定研发项目3项目阶段下拉列表24字符其它是当项目名称=“非特定研发项目”时，“项目阶段”不填；否则“项目阶段”见下表，4活动下拉列表24字符其它是显示活动名称，“活动”见下表； 5花费时间下拉列表4小数1.0是时间单位为小时，近似到0.5小时，输入如：0.5/1.0/1.5/10/10.5/11/11.5/126反馈信息文本框256字符空否由部门经理填写7开始日期文本框10YYYY-MM-DD比“结束日期”提前一星期是8结束日期

10、文本框10YYYY-MM-DD服务器的当前日期是3.1.2 <功能性需求2>描述其它功能需求。4 接口需求此节规定应用程序必须支持的接口/界面。它应非常具体，包含协议、端口和逻辑地址等，以便于按照接口/界面需求开发并检验软件。如果没有可以忽略本章4.1 与<其他系统N>的接口此节指出系统与系统N的接口，包括：Ø 支持硬件接口，其中包括逻辑结构、物理地址、预期行为等；Ø 软件接口，可以是购入的构件、取自其他应用程序重新利用的构件，也可以是为此 详细需求 范围之外的子系统开发，但该软件应用程序必须与之交互的构件编号2具体描述此说明应该具体该功能的作用和目

11、的。一个段落即足以作此说明。优先级此功能需求的优先级别，分为“高/中/低”5 非功能性需求5.1 性能需求此节应根据高级需求中的性能描述各个子系统或模块的性能特征。其中需包括具体的响应时间。如果可行，按名称引用相关用例。l 对事务的响应时间（平均、最长）l 吞吐量，例如每秒处理的事务数l 并发量，例如系统同时处理的客户或事务数l 容量，例如系统可以容纳的客户或事务数l 降级模式（当系统以某种形式降级时可接受的运行模式）l 资源利用情况，如内存、磁盘、通信等5.2 安全性需求列出各个子系统在保障安全性方面所应具备的特性或者应采取的措施。5.3 界面需求各个子系统应提供了一致的界面符合用户要求的界

12、面，这种要求体现在安装菜单、启动屏幕、帮助系统、GUI 对话框等等。此节定义这些方面的需求。5.4 兼容性需求列出各个子系统兼容以前产品版本或者其他产品的要求。如果没有,可以不填或忽略此节5.5 异常处理需求列出各个子系统对异常处理的要求。如果没有,可以不填或忽略此节.5.6 其它列举其它不适合在其它章节描述的需求，包括但不仅限于：l 完成时间l 运行环境l 软件语言l 软件流程需求l 开发工具的指定用途l 构架及设计约束l 购买的构件l 类库l 所有适用的标准以及适用于所述系统的相应标准的具体部分。例如，其中可以包括法律、质量及法规标准；业界在可用性、互操作性、国际化、操作系统相容性等方面的标准。6 验收标准6.1 内部发布需求列举各个子系统对于内部发布的特殊的与公司管理流