系统测试阶段之需求规格说明书参考幻灯片

1、系统测试阶段之需求文档评审,课程内容,软件需求规格说明书介绍 软件需求规格说明书写作要点 需求规格说明书评审流程介绍 软件需求规格说明书评审要点 需求评审实践,SRS的定义,是对在特定环境下要完成一定功能的软件产品、程序或 一组程序的说明 应该从以下方面去描述需求： 功能：软件要做什么 外部接口：如何与人、系统硬件、外部的硬件和软件交互 性能：速度、响应时间、恢复时间等 属性：可移植性、可靠性、可维护性、可用性等 实现的设计约束：标准、实现语言、资源限制、操作环境等,软件需求规格说明书的目的,在客户和开发者之间达成一致 为编制计划和成本计划提供基础 为设计提供了基础 为确认和验证提供一个基础

2、提高开发效率 便于移植,软件需求规格说明书的特点,软件需求的正确性 软件需求无歧义性 软件需求完整性 软件需求一致性 软件需求可验证性 软件需求可追踪性,实例一,需求一：系统应在不少于10秒的正常周期内提供状态信 息： 系统应该以误差上下部超过1秒的10秒间隔，在用户界面的指定位置显 示状态信息 显示状态信息。 如果显示状态信息有错误，应提示错误信息“系统错误。”,实例二,需求2：HTML分析器可以产生HTML标记错误报告，帮 助HTML入门者快速解决错误 HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中 出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生 错误报

3、告,需求分类,需求分类： 需求分类是对很多的需求按照可以管理的方式分组。如： 原始需求 产品需求 软件需求 测试需求,需求的属性,每个需求类型都有多个属性： 优先级 工作量 风险 可用于界定项目的范围，估计工作量，计划和平衡资源等,需求的表达,表达需求的方法： 通过输入、输出来说明 使用规范化的模型方法（UML） 使用电子表格 使用代表性的例子 。,需求表达应避免的问题,需求描述过多涉及到具体的设计和实现 超出规格：对需求描述大大超出用户要求 过度限制：对需求进行不必要的限制 不确定性 以相对的方式描述需求 没有结束的需求 主观或含糊的描述需求 需求描述基于未经确认的假设,课程内容,软件需求规

4、格说明书介绍 软件需求规格说明书写作要点 需求规格说明书评审流程介绍 软件需求规格说明书评审要点 需求评审实践,项目介绍,项目介绍： 描述本软件需求所描述的项目的背景。例如：本项目是一系列版本中的一 个，或者是替代某个已经存在的系统，还是一个新的独立的项目。,产品环境介绍,产品环境介绍： 描述的是当前产品与其它产品或项目所组成的整体环境。 如果本产品是独立的并完全自我包含，在此说明这一点。 如果SRS定义的产品是更大的系统或项目的组件那么应： 描述此大系统或项目每个组件的功能，并且标识接口。 确定本软件产品主要外部接口。 描述相关产品硬件和所使用的外部设备。 通过方块图来描述大系统或项目的主要

5、组件、互连性以及外部接口是非常 有帮助的。,软件功能,软件功能： 概述软件必须实现的和通过用户操作实现的主要功能。这里只需要进行简 要描述（例如目录列表），详细描述在详细需求部分描述，对需求功能进 行组织，以便于读者理解，并能指导后续的设计和测试。可以用图表来表 示主要需求群组之间的关系，例如：高层的数据流图，面向对象的分析等 。 有时此部分所要求的功能概述可以从分配具体功能给此软件产品的更高层 规格（如果存在的话）直接引用。 本节不应描述具体需求，但本节内容是具体需求章节的基础。,用户特征,用户特征： 列出对用户或系统操作者的要求，如：经验，能力，角色等 列出用户属性：如教育程度、国籍、年龄

6、等,假设和依赖关系,假设和依赖关系： 列出可能影响SRS中需求的所有的假设因素，包括准备使用的第三方或商 业组件，操作和开发环境的问题约束等。 如果上述假设不正确、没有被告知或者改变了都将对项目产生影响。 列出项目对外部条件的依赖，例如重用其他项目的模块等。如果在其他文 档（例如项目计划或范围文档等）里已经描述了，在这里可以不用描述。,功能需求,功能需求： 本子章节应描述软件产品的输入怎样被转换成输出。它描述了软件必须执 行的基本动作。 对每一类功能或有时对每一个单独的功能，必须描述输入、处理、输出方 面的需求。这些通常以下面四个子段落来组织： 1、简要介绍 2、输入 3、处理 4、输出 用需

7、求编号加上简短词汇做为功能需求名。不要用“功能需求（1）”作为 功能名。 例如：CALC.R.INTF.001计算表达式 CALC.R.INTF.002打印,功能需求-简要介绍,功能需求 简要介绍： 对本条功能需求进行简单介绍，包括项目如何响应预期的错误输入，非法 条件和无效输入。需求应该简明，完整，不含糊，必要时当需要的信息不 确定的时候使用“待定”。,功能需求 输入,功能需求 输入： 对该功能所有输入数据的详细描述，包括： 输入来源 数量 度量单位 时间要求 包含精度和容忍度的有效输入范围 B. 在适当的地方提供对接口规格或接口控制文件的参考。,功能需求 处理,功能需求 处理： 描述对输入

8、数据所执行的所有操作和如何获得输出的过程。这 包括下列规格： 输入数据的有效性检测。 操作的确切次序，包括各事件的时序。 对异常情况的回应，例如： 溢出 通信失败 错误处理 D. 用于把系统输入转换到相应输出的任何方法（诸如方程式，数学算法， 逻辑操作）。例如： 对工资单里代扣所得税的计算公式。 用于气象预报的气象模型。 E. 对输出数据的有效性检测。,功能需求 输出,功能需求 输出： 本字段落应包含： 对该功能所有输出数据的详细描述，这个描述包括： 输出到何处（如打印机，文件） 数量 度量单位 时序 包含精确度和容忍度的有效输出范围 对非法值的处理 错误消息 B. 在适当的地方提供对接口规格

9、或接口控制文档的参考。,性能需求,本子段落描述对软件的静态的和动态的量化需求 静态量化需求可能包含 支持的终端数目； 支持的同时使用的用户数； 处理的文件和记录的数目； 表和文件的大小； 动态量化需求可能包含： 在正常或峰值工作量情况下一个特定时间段处理事务或任务的数目及 数据量； 在正常或峰值工作量情况下处理某个事务或任务所占用系统资源的数 量；,用户接口,用户接口： 对每种人机界面，软件所必须支持的特性。例如，如果系统用户通过一 个显示终端进行操作，那么应包含下述内容： 要求的屏幕格式 页面规划及报告或菜单的内容 输入和输出的相关时序 一些组合功能键的用法 与系统用户接口使用相关的所有方面

10、。这可能只是一个简单的关于系统 怎样展示给用户，该做什么和不该做什么的列表。,软件接口,软件接口： 此应描述如何使用其它（必须的）软件产品（例如，数据管理系统、操作 系统，或算法工具包），以及与其它应用系统的接口（例如，逻辑处理系 统和数据库管理系统之间的接口）。 对每个必须的软件产品，应提供下列信息： 名字 助记符 版本号 接口 如果接口已在其它文档中很清楚地描述，就没有必要再这儿进行详细描述， 但需说明应参考的文档。,硬件接口,硬件接口： 在此描述软件产品和系统硬件组件之间接口的逻辑特征， 也包括支持哪些设备、怎样支持这些设备和协议等。 按软/硬件协议内容和格式定义接口。如果接口已在其它

11、文档中很清楚地描述，就没有必要这儿进行详细描述， 但需说明参考的文档。,标准符合度,标准符合度： 说明需求所采用的标准或规范的来源。如果项目采用了 国际标准，应该说明国际标准及项目与标准的偏离情况,硬件约束,硬件约束： 包括软件在不同的硬件平台运行的需求，如时间相关的 约束，内存方面的约束等。,技术限制和本地化,技术限制： 包括对使用特定技术的限制，包括接口，数据库，并行 操作，通讯协议，设计约定，编程规范等 本地化： 描述支持多种语言的需求,需求分级,需求分级： 必须的：绝对基本的特性；如果不包含，产品就会被取消。 重要的：不是基本的特性，但这些特性会影响产品的生存能力。 最好有的：期望的特

12、性；但省略一个或多个这样的特性不会影响产 品的生存能力。,课程内容,软件需求规格说明书介绍 软件需求规格说明书写作要点 需求规格说明书评审流程介绍 软件需求规格说明书评审要点 需求评审实践,需求阶段的角色和职责（1）,软件开发项目经理,软件开发工程师,A、带领项目组分析审核工作任务书 B、带领项目组与系统工程师进行需求交流并 进行分析和文档化 C、组织SRS文档评审 D、组织需求跟踪,A、完场SRS文档 B、完成需求跟踪 C、参加SRS review D、根据SRS评审专家意见，修改SRS文档 E、参加系统测试计划的评审,需求阶段的角色和职责（2）,软件经理,QA,A、在SRS评审结束后，批准

13、SRS文档,A、监督项目组遵循需求管理流程 B、参加相关文档review C、保证相关组参加文档review,CCB负责人,A、控制需求的变更,需求阶段的角色和职责（3）,软件测试项目经理,软件测试工程师,A、参加开发人员的软件需求分析，提出可测 试性需求 B、组织人员参加SRS的评审工作 C、软件系统测试计划写作 D、组织系统测试计划的评审 E、组织本阶段测试需求跟踪,A、参加SRS评审工作 B、协助软件测试项目经理完成软件系统测试 计划写作 C、参加系统测试计划的评审 D、完成本阶段测试需求跟踪,软件需求评审的输入,1、软件需求规格说明书； 2、项目工作任务书； 3、软件需求规格说明书Ch

14、ecklist；,软件需求评审专家,接受过关于Review的目标、原则和方法培训的人员 主要的候选Review人员来自Review人员资源池种涉及 该工作产品所处生命周期上一阶段、当前阶段和后一 阶段的Review人员 受影响组的成员（如测试工程师） 与Review工作产品有关的同行,软件需求评审组织者,接受过关于Review的目标、原则和方法培训的人员 接受过如何领导Review团队培训的人员,软件需求评审过程基本原则,任何一次Review最少需要3人（1个作者和2个Review人员） 任何一次Review最多需要7人（1个作者和6个Review人员） 需求规格说明书的Review规模不超过

15、40页 作者在提交检视对象前，首先进行自检 组织者可以根据Review工作产品的Checklist来定制本次Review 的Checklist，保证Review质量,软件需求评审过程基本原则（续）,组织者应当根据被Review对象的规模及复杂程度为检视者留出 足够的准备时间（对Review规模不超过40页的工程文档，建议 准备时间为23天） Review会议时间一般为两小时，但组织者也可根据被Review对 象的类型及规模来调整 在Review会议上组织者根据返工带来的影响程度（如修改量的 大小、是否影响到关键的功能和算法）等来决定是否需要再 Review。同时还可以参考本次Review的效果（如果是否达到质 量目标）来决定是否需要再Review,软件需求评审输出,根据评审专家意见修改后的软件需求规格说明书 软件需求规格说明书评审表格（评审记录表单）,课程内容,软件需求规格说明书介绍 软件需求规格说明书写作要点 需求规格说明书评审流程介绍 软件需求规格说明书评审要点 需求评审实践,软件需求规格说明书评审要点,1、是否所有的分配需求都在SRS中体现？ 2、在SRS中定义需求时，是否避免使用那些会引起歧义的术语， 诸如也许、可能等，每条需求都清晰无歧义？ 3、是否