系统需求规格说明书模板结构化标准版docWord下载.docx

1、例如：本文档是项目名称需求规格说明书，该文档为系统设计及系统测试提供依据。项目验收标准之一软件维护的参考资料】1.2 预期读者【说明该文档都有哪些读者，如：需求人员、设计人员、系统测试人员、用户、QA、PM。】1.3 背景（可选）【说明在做该项目之前所处的时期及为什么要做该项目。1.4 参考资料【说明该文档所用到的所有参考资料。1.5 标准（可选）【说明开发此系统时应当遵循的所有内部和外部的标准以及法律法规要求，还应标识出哪些外部标准是用户制定的。对有相应的内部标准而未使用时，应当略述不使用该内部标准的理由。1.6 术语定义【描述在文中出现的缩写和略语的说明定义。术语定义解释SPP精简并行过程

2、，Simplified Parallel ProcessRD需求开发 Require Development1.7 图例说明【对该需求说明书中所用到的图例进行简要说明。2 系统描述2.1 现状综述1） 画出目前系统或当前业务流程图。2） 描述此系统目前的运行状况/或业务状况进行描述。3） 说明目前面临的问题。2.2 系统目标【说明系统将要实现的目标。2.3 目标系统概述【说明系统的系统结构，并用图表的方式描绘出该系统的计算机体系结构。同时，在体系结构图中应明确标明此系统在整体结构中的位置。为清晰起见，可用多个图表来表示。在功能追加的场合，要指明该追加部分在整体结构中的位置。并简要介绍目标系统的

3、功能和作用。在此图表上应加一些简洁的注释，突出重要部分，并说明此系统在系统整体结构中的位置。2.4 范围【定义工作范围。明确定义哪些工作是要做的，哪些工作是不做的，以确定项目的边界。如:我方主要负责哪些开发阶段，负责的业务范围等。2.5 系统假设/约定【在此对描述系统实现的约束和假设条件。列举出在对软件需求规格说明中影响需求陈述的假设因素（与已知因素相对立）。这可能包括你打算要用的商业组件或有关开发或运行环境的问题。你可能认为产品将符合一个特殊的用户界面设计约定。如果这些假设不正确、不一致或被更改，就会使项目受到影响。此外，确定项目对外部因素存在的依赖。例如，如果你打算把其它项目开发的组件集成

4、到系统中，那么你就要依赖那个项目按时提供正确的操作组件。如果这些依赖已经记录到其它文档（例如项目计划）中了，那么在此就可以参考其它文档。2.6 接口与界面2.6.1 外部接口（可选）【描述目标系统和用户其他相关系统之间的接口关系和依赖型，包括硬件之间的接口和软件之间的数据接口等。2.6.2 硬件接口【描述系统中软件和硬件每一接口的特征。这种描述可能包括支持的硬件类型、软硬件之间交流的数据和控制信息的性质以及所使用的通信协议。2.6.3 软件接口【描述该产品与其它组件（由名字和版本识别）的连接，包括数据库、操作系统、工具、库和集成的商业组件。明确并描述在软件组件之间交换数据或消息的目的。描述所需

5、要的服务以及内部组件通信的性质。确定将在组件之间共享的数据。2.6.4 通信接口（可选）【描述与产品所使用的通信功能相关的需求，包括电子邮件、We b 浏览器、网络通信标准或协议及电子表格等等。定义了相关的消息格式。规定通信安全或加密问题、数据传输速率和同步通信机制。2.6.5 用户界面【陈述所需要的用户界面的软件组件。描述每个用户界面的逻辑特征。而对于用户界面的细节，例如特定对话框的布局，应该写入一个独立的用户界面规格说明中，而不能写入软件需求规格说明中。3 功能需求3.1 系统流程图【画出系统整体流程图。系统模块比较多时可以对复杂的模块画单独的流程图，但要在主流程图中标示出来。3.2 功能

6、一览表【显示出业务和系统功能的关系，以及优先级（高、中、低）。功能编号功能对应业务优先级3.3 功能描述3.3.1 功能1【对功能进行简要描述。3.3.1.1 流程图【画出此功能流程图。3.3.1.2 前提条件【描述进入此功能的前提条件。如必须完成某项操作后。3.3.1.3 输入【描述此功能的输入要求。登陆功能，输入：用户名、密码。3.3.1.4 处理【描述此功能处理步骤。3.3.1.5 输出【描述此功能的输出。登录功能输出用户名、密码正确，进行主界面；用户名、密码错误，返回错误信息。】 3.3.1.6 规约【描述此功能在业务或数据上的约束条件。用户名必须是8位字母或数字组成。3.3.2 功能

7、n3.4 公共功能描述3.4.1 功能13.4.1.1 流程图3.4.1.2 前提条件3.4.1.3 输入3.4.1.4 处理3.4.1.5 输出3.4.1.6 规约3.5 数据描述（可选）【可以以附件的形式进行描述，如果采用附件，本节可直接参见附件。3.5.1 业务数据描述 【描述各个业务相关的数据种类和属性。3.5.2 公共数据描述 【描述系统共通数据的种类和属性。3.5.3 数据存放结构 【描述数据在存储介质中的存放结构。3.6 其他需求（可选）【与系统相关的其他概要描述（系统构架等）。4 非功能需求（可选）4.1 系统性能【在此说明对系统运行性能方面的要求，用户事件的响应时间、屏幕刷新

8、时间、数据处理速度、网络传输速度等方面的要求。4.2 资源使用率【在此说明系统运行时对网络、计算机资源的使用方面的要求，如：CPU和RAM的最大使用率、存储磁盘空间、网络带宽等方面的要求。4.3 保密性【在此说明系统保护他的某些功能和数据不被访问、破坏和错用方面的要求，系统的密码设置模块只有管理员可用、客户信息数据不能被外部访问等要求。4.4 安全性【在此说明可能因为丢失数据、错误操作等原因引起系统出错或不能使用等方面的要求，一般主要针对自动控制系统。电梯控制系统，在门没关闭的情况下不能运行，最大过载等基于安全方面的要求。4.5 容量【在此说明系统事务处理能力、最大支持的数据等方面的要求。最大

9、相应的并发事件数等方面的要求。4.6 有效性【在此说明系统正常运行的有效性方面的要求。系统可全天候运行24小时处理事务等方面的要求。4.7 可靠性【在此说明系统长时间运行出错率或故障率方面的要求。系统的平均的安全运行期（系统正常运行在多长时间内不会出错）、一段时间内的平均故障率等方面的要求。4.8 精确度【在此说明系统信息处理精确度方面的要求。误差边界、数据精度等方面的要求。4.9 复用性【在此说明系统在未来业务变化时很容易并入其他系统或只作很少的修改就能被其他系统使用等能方面的要求。用户的业务合并引起旧系统的合并等。4.10 易用性【在此说明对系统操作使用方面的要求。操作简单、无需培训等。4

10、.11 互用性【在此说明系统和其他系统之间交互使用方面的要求。数据共享、事务互通等。4.12 移植性【在此说明系统由于业务变化或增加功能等原因需要一直到另一软件或硬件平台方面的要求。 WIN9X系统平台要移植到NT或UNIX平台时代码的改变率或要做多少修改等。4.13 扩展性【在此说明系统结构、数据或处理流程能被扩展方面的要求。当业务增加时数据结构也能满足未来的需要，处理流程只要很小的处理就能解决新增的业务。4.14 维护性【在此说明系统维护人员或开发人员在处理一个错误或意外时的处理速度等方面的要求系统宕机后的恢复时间等。5 验收准则和验收程序5.1 验收程序【描述最终系统的验收流程。5.2

11、质量要求【说明用户定义的“质量需求”，包含用户会用来判断和认可此系统是否符合其“质量需求”的所有要素。若用户未提供“质量需求”，则应在此向用户提出我方的“质量标准“。5.3 验收准则【在此描述系统验收时的准则，包括硬件、软件、文档等，可列表说明。6 系统集成和测试策略（可选）6.1 集成策略【在此应确定和说明集成的策略。对系统集成的顺序进行定义。此时，应考虑各种因素，如阶段性的成果、跨组的联合开发等，它们都会对集成的顺序产生影响。6.2 集成测试策略【在此对集成测试策略加以说明，该集成测试策略应基于上述的集成策略。包括测试观点，测试范围及确认手段。测试计划应直接依赖于所用的结合策略。决定是自底

12、向上还是自顶向下的顺序。6.3 系统测试策略【此部分标明所采用的系统测试策略，对特别的系统测试要求，如使用仿真软件，精确的测试步骤、以及需要从外部获得的测试组件，均应在此说明。6.4 验收测试策略【此部分描述用户对验收测试的需求。 验收的方法、步骤以及其他特殊情况的考虑和安排。7 环境要求7.1 开发环境要求（可选）7.1.1 硬件要求【此部分标明此项目的硬件平台需求，应描述以下内容的全部配置及其详细情况：1） CPU2） 内存3） 硬盘4） 外设5） 网络】7.1.2 软件要求【此部分标明需要的软件平台，应描述以下内容的详细内容：1） 操作系统2） 浏览器3） 网络环境4） 工具 （编译器, 库, 调试工具等.）5） 服务器（应用服务器、WEB服务器、DB服务器）】7.2 用户方软硬件（可选）【此部分标明用户提供的软硬件，而对开发有关键影响的应该突出标明。如果存在客户端和服务器端，分别标明。7.3 背离之处（可选）【此部分标明与所要求的开发平台不符合之处。并对不符合之处给出解决方案。7.4 运行环境要求【此部分应对运行环境的软件，硬件需求详细地叙述，在运行环境和开发环境完全相同时，简单提及即可。7.5 测试环境要求【有些产品需要使用另外的软硬件来进行详尽的测试。此处应当标明此类测试平台需求。在测试平台和目标环境或开发环境相同时，也要在此说明。8 开发特别考虑事