软件需求规格说明书模板
文档编号：FHI_CMMI_RD_TEM_RSPEC 文档信息：软件需求规格说明书模版 文档名称：软件需求规格说明书模版 文档类别：CMMI模板 密 级：内部秘密 版本信息：1.1 建立日期：2016-1-5
创 建 人：EPG 批 准 人：李庆林 批准日期：2016.2.25
存放位置：集成公司组织资产库/组织标准过程 编辑软件：Microsoft Office 2003 中文版
1/24
文档修订记录（引用时请修改为实际项目的信息）
版本编号或者更改记录编号 V1.0 V1.1 变化状态 C M 简要说明（变更内容和变更范围） 修改日期 2016-1-5 2016-4-17 变更人 张娜娜 邓沛沛 批准日期 批准人 创建 文档编号去掉版本号 2016-2-25 李庆林 2016-4-17 李庆林 *变化状态：C――创建，A——增加，M——修改，D——删除
2/24
目 录
1 引言 ....................................................................................................................................................... 5
1.1 1.2 1.3 1.4 1.5 2
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3
3.1 3.2 3.3 4
4.1 4.2
编写目的............................................................................................................................ 5 产品的范围........................................................................................................................ 5 预期的读者和阅读建议 .................................................................................................... 5 术语、定义、符号及缩略语 ............................................................................................ 5 参考资料............................................................................................................................ 5 产品的背景........................................................................................................................ 6 用户类和特征 .................................................................................................................... 6 产品的功能........................................................................................................................ 6 遵循的标准和规范 ............................................................................................................ 6 应用模型............................................................................................................................ 6 运行环境............................................................................................................................ 6 设计和实现上的 ........................................................................................................ 6 假设和依赖........................................................................................................................ 7 功能需求关系模型 ............................................................................................................ 8 功能1 ................................................................................................................................. 8 功能n ................................................................................................................................. 8 包结构模型/模块关系模型 ................................................................ 错误!未定义书签。 综合描述 ........................................................................................................................................... 5 功能需求 ........................................................................................................................................... 7 功能需求 ........................................................................................................................................... 9 < Feature B > 概述 .................................................................... 错误!未定义书签。 <需求N> ..................................................................................... 错误!未定义书签。 5 非功能需求 ..................................................................................................................................... 12 5.1 性能需求.......................................................................................................................... 12 3/24 5.1.1 5.2 <性能需求M>.......................................................................................................... 12 可靠性需求...................................................................................................................... 13 5.2.1 <可靠性需求M> ...................................................................................................... 13 5.3 安全设施需求 .................................................................................................................. 14 5.3.1 <安全设施需求M> .................................................................................................. 14 5.4 安全性需求...................................................................................................................... 15 5.4.1 <安全性需求M> ...................................................................................................... 15 5.5 质量属性.......................................................................................................................... 16 5.5.1 <质量属性需求M> .................................................................................................. 16 5.6 用户文档与帮助系统 ...................................................................................................... 17 5.6.1 <用户文档与帮助系统需求M> .............................................................................. 17 5.7 其它需求.......................................................................................................................... 18 5.7.1 <其它需求M>.......................................................................................................... 18 6 接口需求 ......................................................................................................................................... 19 6.1 用户接口.......................................................................................................................... 19 6.1.1 6.2 <用户接口需求M> .................................................................................................. 19 硬件接口.......................................................................................................................... 20 6.2.1 <硬件接口需求M> .................................................................................................. 20 6.3 软件接口.......................................................................................................................... 21 6.3.1 <软件接口需求M> .................................................................................................. 21 6.4 通信接口.......................................................................................................................... 22 6.4.1 <通信接口需求M> .................................................................................................. 22 7 8 验收标准 ......................................................................................................................................... 23 附录 ................................................................................................................................................. 23 8.1 8.2 8.3 附录A：分析模型 ........................................................................................................... 23 附录B：待确定问题的列表 ........................................................................................... 23 附录C：编写需求文档的原则 ....................................................................................... 23 4/24 1 引言 [提出对《软件需求规格说明书》的纵览，帮助读者理解文档如何编写并且如何阅读和解释。] 1.1 编写目的 [对产品（也可能是项目，但是我们统称为产品）进行定义，在该文档中详尽说明这个产品的需求，包括修正或发行版本号。如果这个《软件需求规格说明书》只与整个系统的一部分有关，那么只定义文档中说明的部分或子系统。举例：本文的目的是为了清晰地说明产品要实现的所有功能，产品的设计、编码和测试都要以本文的内容为基础。同时，本文确定的内容还作为产品验收的基准。客户、项目组要共同协商本文内容。] 1.2 产品的范围 [提供对指定的产品及其目的的简短描述，解释产品要做什么，不做什么，产品适用的领域和不适用的领域，应当包含的内容和不包含的内容，说明产品将如何被使用，以及相关的利益和目标。可以参考《产品概述》文档，但不是将其内容复制到这里。] 1.3 预期的读者和阅读建议 [列举本文档所针对的不同读者，例如开发人员、市场人员、测试人员、客户等。描述文档中剩余部分的内容及其组织结构，提出最适合每一类型读者阅读文档的建议。] 1.4 术语、定义、符号及缩略语 [按字母或拼音顺序列出所有的定义和缩略语，以便读者可以正确地理解《软件需求规格说明书》，包括词头和缩写。注意：只需要列出对理解本文有用的术语。] 1.5 参考资料 [列举编写《软件需求规格说明书》时所参考的资料或其它来源。可能包括用户界面风格指导、合同、标准、系统需求规格说明书、用户需求、相关产品的软件需求规格说明书。这里应该给出参考资料详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅这些文献。] 2 综合描述 [这一部分概述了正在定义的产品以及它所运行的环境、使用产品的用户和已知的、假设和依赖。] 5/24 2.1 产品的背景 [描述软件需求规格说明书中所定义的产品的背景和起源。说明该产品是否是产品系列中的下一个成员，是否是成熟产品所改进的下一代产品、是否是现有应用程序的替代品，或者是否是一个全新的产品。] [如果软件需求规格说明书定义了大系统的一个组成部分，那么就要说明这部分子系统是怎样与整个系统相关联的，并且要定义出两者之间的接口。建议使用系统结构图或者实体关系图表示。] 2.2 用户类和特征 [将可能使用本产品的用户进行分类。由于用户在使用产品的频率、使用的功能集、技术水平、权限级别、工作经验等方面的不同，会形成各种类型的用户群。对每类用户，描述其特点、期望的需求、如何使用产品、产品满足的优先级等。有一些需求可能只与特定的用户类相关。将该产品的重要用户类与那些不太重要的用户类区分开。] 2.3 产品的功能 [概述产品必须具备的主要功能，本文档在第三章对产品功能进行详细描述，在此仅作概括总结，重点在系统层次上描述产品的功能需求和功能分类，还可能包括保证产品与外部组件正确连接的需求。可以使用列表的方法给出，也可使用图形表示主要的需求分组以及它们之间的联系，例如数据流程图的顶层图或类图。以使描述更加有效。] 2.4 遵循的标准和规范 [阐述本产品应当遵循什么标准、规范、业务规则。] 2.5 应用模型 [运用场合、环境、组网、应用举例。绘制产品的结构图示、与系统相交互的外部对象之间的关系。] 2.6 运行环境 [描述产品的运行环境，包括为支持产品工作所需的其它的组件或者与其共存的产品；对于软件产品还应包括硬件平台、操作系统和版本、必须安装的软件部件和其他应用软件等。] 2.7 设计和实现上的 [确定影响开发人员自由选择的问题，并说明这些问题为什么成为一种。可能的包括： 6/24 ➢ 必须使用或者避免的特定技术、工具、编程语言、数据库； ➢ 经费、进度、资源等方面的； ➢ 所要求的开发规范或标准； ➢ 企业策略、法规或工业标准； ➢ 硬件，例如定时需求或存储器； ➢ 数据转换格式标准。 ➢ 其它。] 2.8 假设和依赖 [列出所有会影响需求实现的假设因素（相对于已知的事实而言），可能包括打算要用的商业组件或有关开发或运行环境的问题。例如，本项目产品计划要使用某些第三方软件产品或商业软件产品，虽然目前还未得到这些软件，但我们可以假设这些软件一定能够得到。如果这些假设不正确、或发生改变，会影响项目的开发，因此，这些假设往往又是一种风险。 此外，确定项目对外部因素存在的依赖。例如，如果项目的开发或项目产品的使用要依靠其它外部因素，比如与其它产品共用的软件包、准备重用的软件构件等，也要在此说明。] [3章和4章编写功能需求的方式可以根据项目情况任意选择一个。] 3 功能需求 [需求编号规则： 一级功能1，二级功能1.1，三级功能1.1.1，顺序向下排。 下表中只填写到二级模块，详细模块见下面的明细说明。需求跟踪时跟踪到叶子节点，在需求跟踪矩阵上只填写叶子节点。如果某功能是复用公司平台或其他项目组组件，在描述中标识“复用”，说明复用的组件。] 需求编号 1 1.1 1.2 详细列出与该特性相关的功能需求。这些是必须提交给用户的软件功能，使用户可以使用所提 模块名称 功能1 功能1.1 功能1.2 优先级 高 高 描述 复用 7/24 供的特性执行服务或者使用所指定的用例执行任务。描述产品如何响应可预知的出错条件或非法输入或动作。 3.1 功能需求关系模型 3.2 功能1 （1）编号和名称 本功能的编号和名称。 （2）输入 描述本功能的输入信息（包括需要访问的存储信息）。（3）过程 对本功能将做什么进行详细的描述。 （4）输出 描述本功能的输出信息（包括需要访问的存储信息）。（5）候选可重用软件 说明识别出的候选可重用软件。 （6）验收准则 说明用于验证满足需求的验收准则。 3.3 功能n （1）编号和名称 本功能的编号和名称。 （2）输入 描述本功能的输入信息（包括需要访问的存储信息）。（3）过程 对本功能将做什么进行详细的描述。 （4）输出 描述本功能的输出信息（包括需要访问的存储信息）。（5）候选可重用软件 说明识别出的候选可重用软件。 8/24 （6）验收准则 说明用于验证满足需求的验收准则。 4 功能需求 [本章将详细解释产品所有的功能需求。功能需求是根据系统特性即产品所提供的主要服务来组织的。你可能更喜欢通过用例、运行模式、用户类、对象类或功能等级来组织这部分内容，你还可以使用它们的组合。总之，你必须选择一种使读者易于理解预期产出的组织方案。 如果使用传统的需求分析方法，本章的每一节描述一个功能需求，每个功能需求又从编号、名称、优先级、输入、处理、输出、验收准则7项来说明。如果使用UML模型描述需求分析结果，本章的每一节采用“使用用例”描述一个功能需求，并在此说明参考的“使用用例”文件名；如果你采用模型工具绘制用例视图，你应在此注明所用工具的名称、版本等信息。 本章中所列出的需求，要求细化到如下程度：（1）设计人员可以依据该需求设计并实现系统；（2）系统测试人员可以依据该需求编写测案并对系统进行验证。] 4.1 包结构模型/模块关系模型 [使用UML模型描述需求分析结果时，在本节划分出系统的包结构，用图表示出用户机构与本系统各个包之间的关系和本系统各包部分之间的关系。 使用传统的需求分析方法时，在本节划分出系统的各功能模块结构，用图表示出用户机构与本系统各个功能模块之间的关系和本系统各功能模块之间的关系。] 4.2 [本节示范使用UML模型描述需求分析结果时的文档结构。本节详细描述 4.2.1 [在此对 4.2.2 用例目录 [在此列出 一级功能1，二级功能1.1，三级功能1.1.1，顺序向下排。 9/24 下表中可只填写到二级模块，详细模块见下面的明细说明。需求跟踪时跟踪到叶子节点，在需求跟踪矩阵上只填写叶子节点。如果某功能是复用公司平台或其他项目组组件，在描述中标识“复用”，说明复用的组件。] 模块编号 1 1.1 n 其中该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 模块名称 功能1 功能1.1 功能n 优先级 中 高 中 描述 4.2.3 用例模型 [用例之间的关系的图示，例如： 10/24 Security(from ucv prepaid appserver)appmanager client(from ucv appserver)Enhanced securityraidus client(from ucv appserver)(from ucv prepaid appserver)Abbre Dial Num Modification(from tmpucv_lwb)Prepaid ManagerPrepaid AppMuti-Card Registration(from tmpucv_lwb)PIN modificationASB SDK Client API(from ucv appserver)Prompt and collect user information(from ucv prepaid appserver)(from ucv prepaid appserver)Current creditCaller BindingDestination restricted calling(from ucv prepaid appserver)Abbreviated dialling(from ucv prepaid appserver)(from ucv prepaid appserver)Balance Transfer(from tmpucv_liye)Basic Call Flow(from tmpucv_liye) ] 4.2.4 业务对象模型 4.2.5 用例描述 4.2.5.1 <用例M> [用例M的详细描述，例如下表： 用例名称 主参与者 状态 简述 主流 辅助流/ 候补流/ 场景 特殊需求 假设 前置条件 后置条件 1、 1、 1、 编写日志 修改人 修改时间 版本 简述 1、 辅助参与者 11/24 ] 5 非功能需求 [编号规则： 一级功能NF1，二级功能NF1.1，三级功能NF1.1.1，顺序向下排。如果某功能是复用公司平台或其他项目组组件，在描述中标识“复用”，说明复用的组件。 下表模块列表只写到一级模块，需求跟踪时跟踪到叶子节点，详细模块见下面的详细说明。] 表二：非功能需求分类表 需求类别 编号 需求名称 优先级 描述 5.1 性能需求 [说明本软件产品要满足的量化性能需求，以体现不同的应用领域对产品性能的要求，包括：支持的终端数、并行操作的用户数、相互合作的用户数或者所支持的操作、要处理的信息的数量和类型、响应时间以及与实时系统的时间关系、相同负载情况下的持续处理时间等。还可以在这里定义容量需求，例如存储器和磁盘空间的需求或者存储在数据库中表的最大行数。 所有这些需求必须以量化或可度量的方式尽可能详细地描述，解释它们的原理并说明每项需求的理由，以帮助开发人员做出合理的设计选择。可能需要针对每个功能需求或特性分别陈述其性能需求，而不是把它们都集中在一起陈述。例如，“在运行微软Window 2000的450 MHzPentiumⅡ的计算机上，当系统至少有50%的空闲资源时，95%的目录数据库查询必须在两秒内完成”。] 5.1.1 <性能需求M> [本节的标题需以实际的需求名代替。] 5.1.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 12/24 5.1.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 5.1.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 对高、中、低的解释如下： 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 5.1.1.4 验收准则 [说明用于验证满足需求的验收准则。] 5.2 可靠性需求 [说明本软件产品要满足的量化可靠性需求，以体现不同的应用领域对产品可靠性的要求，例如：满配置情况下，连续无故障工作时间不小于5000小时。 所有这些需求必须以量化或可度量的方式尽可能详细地描述，解释它们的原理并说明每项需求的理由，以帮助开发人员做出合理的设计选择。可能需要针对每个功能需求或特性分别陈述其可靠性需求，而不是把它们都集中在一起陈述。] 5.2.1 <可靠性需求M> [本节的标题需以实际的需求名代替。] 5.2.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 13/24 5.2.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 5.2.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 对高、中、低的解释如下： 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 5.2.1.4 验收准则 [说明用于验证满足需求的验收准则。] 5.3 安全设施需求 [详尽陈述与产品使用过程中可能发生的损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或规则。一个安全设施需求的范例如下：“如果设备的温度超过了规定的最大工作温度，那么必须在1秒钟内终止操作”。] 5.3.1 <安全设施需求M> [本节的标题需以实际的需求名代替。] 5.3.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 5.3.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 14/24 5.3.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 5.3.1.4 验收准则 [说明用于验证满足需求的验收准则。] 5.4 安全性需求 [陈述与系统安全性、完整性或私人问题相关的需求，说明软件产品防止由于意外或恶意的访问、不正确的使用或修改所带来的破坏的要求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。这些要求可能包括，密码系统、身份认证、数据加密、备份机制等。一个安全需求的范例如下：“每个用户在第一次登录后，必须更改他的最初登录密码。最初的登录密码不能重用。”] 5.4.1 <安全性需求M> [本节的标题需以实际的需求名代替。] 5.4.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 5.4.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 5.4.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 15/24 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 5.4.1.4 验收准则 [说明用于验证满足需求的验收准则。] 5.5 质量属性 [详尽陈述与客户或开发人员至关重要的质量特性，指明产品在可靠性、可移植性、实用性、可维护性等方面的目标。应尽量以明确的、量化的、可检验的方式来描述。至少应指明不同属性的相对侧重点，例如易用程度优于易学程度，或者可移植性优于有效性。 如果某个这样的质量属性比较重要（例如：可移植性），可以单独用新的一节来描述。] 5.5.1 <质量属性需求M> [本节的标题需以实际的需求名代替。] 5.5.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 5.5.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 5.5.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 16/24 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 5.5.1.4 验收准则 [说明用于验证满足需求的验收准则。] 5.6 用户文档与帮助系统 [列举出将与产品一同发行的用户文档部分，例如，用户手册、在线帮助和教程。明确所有已知的用户文档的交付格式或标准。] 5.6.1 <用户文档与帮助系统需求M> [本节的标题需以实际的需求名代替。] 5.6.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 5.6.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 5.6.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 17/24 ] 5.6.1.4 验收准则 [说明用于验证满足需求的验收准则。] 5.7 其它需求 [对其它需要描述但未在本模板中列出的需求，在此进行说明。例如国际化需求、法律上的需求，有关操作、管理和维护部分来完善产品安装、配置、启动和关闭、修复和容错，以及登录和监控操作等方面的需求等。如果某个这样的需求比较重要，可以单独用新的一节来描述。如果不需要增加其它需求，就标记为“无”。] 5.7.1 <其它需求M> [本节的标题需以实际的需求名代替。] 5.7.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 5.7.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 5.7.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 5.7.1.4 验收准则 [说明用于验证满足需求的验收准则。] 18/24 6 接口需求 [编号规则： 一级功能IF1，二级功能IF1.1，三级功能IF1.1.1，顺序向下排。如果某功能是复用公司平台或其他项目组组件，在描述中标识“复用”，说明复用的组件。 下表模块列表可只写到一级模块，需求跟踪时跟踪到叶子节点，详细模块见下面的详细说明。] 表三：接口需求分类表 需求类别 编号 需求名称 优先级 描述 6.1 用户接口 [陈述产品中所需要的用户界面。描述每个用户界面的逻辑特征。以下是可能要包括的一些特征： 将要采用的图形用户界面标准或整个产品系列的风格； 屏幕布局； 将出现在每个屏幕的标准按钮（如帮助）、功能或导航链接； 键盘快捷键； 错误信息显示标准。 如果必要，用户接口需求的细节可在的用户接口规格文件中描述。] 6.1.1 <用户接口需求M> [本节的标题需以实际的需求名代替。] 6.1.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 6.1.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 19/24 6.1.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 6.1.1.4 验收准则 [说明用于验证满足需求的验收准则。] 6.2 硬件接口 [描述系统中软件和硬件每一接口的特征，可能包括软件所支持的设备类型、软硬件之间交流的数据和控制信息的性质、通讯协议等。] 6.2.1 <硬件接口需求M> [本节的标题需以实际的需求名代替。] 6.2.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 6.2.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 6.2.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 20/24 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 6.2.1.4 验收准则 [说明用于验证满足需求的验收准则。] 6.3 软件接口 [说明本产品与产品组件间的接口需求，本产品与其它外部组件（包括数据库、操作系统、工具、运行库、集成的商业部件等，要指明它们的名字和版本）的连接。明确并描述在软件组件之间交换数据或消息的目的。描述所需要的服务以及内部组件通信的性质。确定将在组件之间共享的数据。如果必须用一种特殊的方法来实现数据共享机制，例如在多任务操作系统中的一个全局数据区，那么就必须把它定义为一种实现上的。] 6.3.1 <外部接口需求M> [本节的标题需以实际的需求名代替。] 6.3.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 6.3.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 6.3.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个 21/24 版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 6.3.1.4 验收准则 [说明用于验证满足需求的验收准则。] 6.3.2 <内部接口需求M> [内部接口是指系统内部模块与模块之间消息（或数据）传递的测试。] 接口名称 编号 需求描述 发送方模块编号 接收方模块编号 验收准则 6.4 通信接口 [描述与产品所使用的通信功能相关的需求，例如电子邮件、WEB浏览器、网络通信标准或协议及电子表格等。定义相关的信息格式，指明要遵守的通讯标准，如FTP，HTTP等。说明在通讯中的安全和加密问题、数据传输速率、同步机制等。] 6.4.1 <通信接口需求M> [本节的标题需以实际的需求名代替。] 6.4.1.1 编号 [为需求定义一个唯一的编号，便于需求跟踪。] 6.4.1.2 名称及说明 [需求名称，如果需要可以在此对需求的内容作简要的描述。] 6.4.1.3 优先级 [该需求的优先级，按高、中、低的优先级分类。 对高、中、低的解释如下： 22/24 高：关键的功能特性，必选，不能实现意味着无法满足客户的需求。所有“高”优先级的 需求必须在本次项目开发中实现。 中：重要的功能，必选，不能实现可能会影响产品的销售和客户满意度。所有“中”优先 级的需求都应该作为产品的功能点，但在时间、资源的压力下，可以考虑在产品的下一个版本中实现。 低：有用的功能或性能的提高，可选，不能实现不会对产品产生实质性影响，但可能会在 特定的应用场合增加产品的卖点，在时间、资源允许的情况下，可以考虑在产品的某一版本中实现。 ] 6.4.1.4 验收准则 [说明用于验证满足需求的验收准则。] 7 验收标准 明确规定产品验收依据的各种标准或条件的具体内容。 8 附录 8.1 附录A：分析模型 [如果在需求分析过程中用到了分析模型，可在此描述对模型文件的参考，或直接描述用到的分析模型，例如数据流图、类图、状态转换图或实体关系图等] 8.2 附录B：待确定问题的列表 [将本次需求分析过程不清楚或需要进一步确认的信息以编号方式在此列表，以便跟踪。] 8.3 附录C：编写需求文档的原则 [本附录用于建议编写《软件需求规格说明书》应遵循的一些原则，实际的《软件需求规格说明书》不应该包括本附录。] 编写文档时，要求具有本规范规定的所有条目，如果某条目无内容，则填写“无”，并在可能的情况下说明理由。必要时，可增加适当的条目。 编写优秀的需求文档没有现成固定的方法，最好是根据经验进行。许多需求文档可以通过使用有效的技术编写风格和使用用户术语而不是技术术语的方式得以改进。你在编写需求文档时，应牢记以下几点建议： 23/24 保持语句和段落的简短； 采用主动语态的表达方式； 语法正确，句子完整； 使用的术语与词汇表中所定义的术语一致； 避免模糊的、主观的术语如用户友好、容易、简单、迅速、有效、许多、最新技术、优越 的、可接受的、健壮的等等； 避免使用比较性的词汇如提高、最大化、最小化、最佳化等。定量说明所需要提高的程度 或者说清一些参数可以接受的最大值和最小值。含糊的语句表达将引起需求的不可验证。 由于需求的编写是层次化的，因此，可以把顶层不明确的需求向低层详细分解，直到消除 不明确性为止。编写详细的需求文档，所带来的益处是如果需求得到满足，那么客户的目的也就达到了，但是不要让过于详细的需求影响了设计。如果你能用不同的方法来满足需求，并且这种方法是可接受的，那么需求的详细程度也就足够了。然而，如果评审需求规格说明书的设计人员对客户的意图还不甚了解，那么就需要增加额外的说明，以减少由于误解而产生返工的风险。 需求文档的编写人员总是力求寻找到恰如其分的需求详细程度。一个有益的原则就是编写 单个的可测试需求文档。如果你想出一些相关的测试用例可以验证这个需求，那么就达到了合理的详细程度。如果你预想的测试很多并且很分散，那么就要将一些集合在一起的需求分离开。 必须以相同的详细程度编写每个需求文档。 不应该把多个需求集中在一个冗长的叙述段落中。在需求中，诸如“和”，“或”之类的连 词就表明了该部分集中了多个需求。不要在需求说明中使用“和/或”，“等等”之类的连词。 不应该出现需求的冗余。 24/24
因篇幅问题不能全部显示，请点此查看更多更全内容
Copyright © 2019- huatuo0.cn 版权所有 湘ICP备2023017654号-2
违法及侵权请联系：TEL:199 18 7713 E-MAIL:2724546146@qq.com
本站由北京市万商天勤律师事务所王兴未律师提供法律服务