2.1系统测试阶段之需求规格说明书ppt课件.ppt

系统测试阶段之需求文档评审系统测试阶段之需求文档评审课程内容l软件需求规格说明书介绍软件需求规格说明书介绍l软件需求规格说明书写作要点软件需求规格说明书写作要点l需求规格说明书评审流程介绍需求规格说明书评审流程介绍l软件需求规格说明书评审要点软件需求规格说明书评审要点l需求评审实践需求评审实践SRS的定义是对在特定环境下要完成一定功能的软件产品、程序或一组程序的说明应该从以下方面去描述需求：功能：软件要做什么外部接口：如何与人、系统硬件、外部的硬件和软件交互性能：速度、响应时间、恢复时间等属性：可移植性、可靠性、可维护性、可用性等实现的设计约束：规范、实现语言、资源限制、操作环境等软件需求规格说明书的目的l在客户和开发者之间达成一致l为编制计划和成本计划提供基础l为设计提供了基础l为确认和验证提供一个基础l提高开发效率l便于移植软件需求规格说明书的特点l软件需求的正确性l软件需求无歧义性l软件需求完整性l软件需求一致性l软件需求可验证性l软件需求可追踪性实例一需求一：系统应在不少于10秒的正常周期内提供状态信息：系统应该以误差上下部超过1秒的10秒间隔，在用户界面的指定位置显 示状态信息显示状态信息。

如果显示状态信息有错误，应提示错误信息“系统错误实例二需求2：HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中 出错的HTML文本和行号以及错误的描述如果没有错误，就不会产生 错误报告需求分类需求分类：需求分类是对很多的需求按照可以管理的方式分组如：原始需求产品需求软件需求测试需求需求的属性每个需求类型都有多个属性：优先级工作量风险可用于界定项目的范围，估计工作量，计划和平衡资源等需求的表达表达需求的方法：通过输入、输出来说明使用规范化的模型方法〔UML）使用电子表格使用代表性的例子需求表达应避免的问题l需求描述过多涉及到具体的设计和实现l超出规格：对需求描述大大超出用户要求l过度限制：对需求进行不必要的限制l不确定性l 以相对的方式描述需求l 没有结束的需求l 主观或含糊的描述需求 l需求描述基于未经确认的假设课程内容l软件需求规格说明书介绍l软件需求规格说明书写作要点l需求规格说明书评审流程介绍l软件需求规格说明书评审要点l需求评审实践项目介绍项目介绍：描述本软件需求所描述的项目的背景。

例如：本项目是一系列版本中的一个，或者是替代某个已经存在的系统，还是一个新的独立的项目产品环境介绍产品环境介绍：描述的是当前产品与其它产品或项目所组成的整体环境如果本产品是独立的并完全自我包含，在此说明这一点如果SRS定义的产品是更大的系统或项目的组件那么应： 描述此大系统或项目每个组件的功能，并且标识接口 确定本软件产品主要外部接口 描述相关产品硬件和所使用的外部设备通过方块图来描述大系统或项目的主要组件、互连性以及外部接口是非常有帮助的软件功能软件功能：概述软件必须实现的和通过用户操作实现的主要功能这里只需要进行简要描述〔例如目录列表），详细描述在详细需求部分描述，对需求功能进行组织，以便于读者理解，并能指导后续的设计和测试可以用图表来表示主要需求群组之间的关系，例如：高层的数据流图，面向对象的分析等有时此部分所要求的功能概述可以从分配具体功能给此软件产品的更高层规格〔如果存在的话〕直接引用本节不应描述具体需求，但本节内容是具体需求章节的基础用户特征用户特征：列出对用户或系统操作者的要求，如：经历，才干，角色等列出用户属性：如教育程度、国籍、年龄等假设和依赖关系假设和依赖关系：列出可能影响SRS中需求的所有的假设因素，包括准备使用的第三方或商业组件，操作和开发环境的问题约束等。

如果上述假设不正确、没有被告知或者改变了都将对项目产生影响列出项目对外部条件的依赖，例如重用其他项目的模块等如果在其他文档〔例如项目计划或范围文档等〕里已经描述了，在这里可以不用描述功能需求功能需求：本子章节应描述软件产品的输入怎样被转换成输出它描述了软件必须执行的基本动作对每一类功能或有时对每一个单独的功能，必须描述输入、处置、输出方面的需求这些通常以下面四个子段落来组织：1、简要介绍2、输入3、处置4、输出用需求编号加上简短词汇做为功能需求名不要用“功能需求〔1）”作为功能名例如：CALC.R.INTF.001计算表达式 CALC.R.INTF.002打印功能需求-简要介绍功能需求 – 简要介绍：对本条功能需求进行简单介绍，包括项目如何响应预期的错误输入，非法条件和无效输入需求应该简明，完好，不含糊，必要时当需要的信息不确定的时候使用“待定”功能需求 – 输入功能需求 – 输入：对该功能所有输入数据的详细描述，包括： 输入来源数量度量单位时间要求包含精度和容忍度的有效输入范围B. 在适当的地方提供对接口规格或接口控制文件的参考功能需求 – 处置功能需求 – 处置：描述对输入数据所执行的所有操作和如何获得输出的过程。

这包括下列规格：输入数据的有效性检测操作的确切次序，包括各事件的时序对异常情况的回应，例如： 溢出 通信失败 错误处理D. 用于把系统输入转换到相应输出的任何方法〔诸如方程式，数学算法， 逻辑操作）例如： 对工资单里代扣所得税的计算公式 用于气象预报的气象模型E. 对输出数据的有效性检测功能需求 – 输出功能需求 – 输出：本字段落应包含：对该功能所有输出数据的详细描述，这个描述包括： 输出到何处〔如打印机，文件） 数量 度量单位 时序 包含精确度和容忍度的有效输出范围 对非法值的处理 错误消息B. 在适当的地方提供对接口规格或接口控制文档的参考性能需求本子段落描述对软件的静态的和动态的量化需求静态量化需求可能包含支持的终端数目；支持的同时使用的用户数；处理的文件和记录的数目；表和文件的大小；动态量化需求可能包含：在正常或峰值工作量情况下一个特定时间段处理事务或任务的数目及 数据量；在正常或峰值工作量情况下处理某个事务或任务所占用系统资源的数 量；用户接口用户接口：对每种人机界面，软件所必须支持的特性。

例如，如果系统用户通过一 个显示终端进行操作，那么应包含下述内容： 要求的屏幕格式 页面规划及报告或菜单的内容 输入和输出的相关时序 一些组合功能键的用法 ……与系统用户接口使用相关的所有方面这可能只是一个简单的关于系统 怎样展示给用户，该做什么和不该做什么的列表软件接口软件接口：此应描述如何使用其它〔必须的〕软件产品〔例如，数据管理系统、操作系统，或算法工具包），以及与其它应用系统的接口〔例如，逻辑处理系统和数据库管理系统之间的接口）对每个必须的软件产品，应提供下列信息：名字助记符版本号接口如果接口已在其它文档中很清楚地描述，就没有必要再这儿进行详细描述，但需说明应参考的文档硬件接口硬件接口：在此描述软件产品和系统硬件组件之间接口的逻辑特征，也包括支持哪些设备、怎样支持这些设备和协议等按软/硬件协议内容和格式定义接口如果接口已在其它文档中很清楚地描述，就没有必要这儿进行详细描述，但需说明参考的文档标准符合度标准符合度：说明需求所采用的标准或规范的来源如果项目采用了国际标准，应该说明国际标准及项目与标准的偏离情况硬件约束硬件约束：包括软件在不同的硬件平台运行的需求，如时间相关的约束，内存方面的约束等。

技术限制和本地化技术限制：包括对使用特定技术的限制，包括接口，数据库，并行操作，通讯协议，设计约定，编程规范等本地化：描述支持多种语言的需求需求分级需求分级：必须的：绝对基本的特性；如果不包含，产品就会被取消重要的：不是基本的特性，但这些特性会影响产品的生存能力最好有的：期望的特性；但省略一个或多个这样的特性不会影响产品的生存能力需求ID需求名称需求分级课程内容l软件需求规格说明书介绍l软件需求规格说明书写作要点l需求规格说明书评审流程介绍l软件需求规格说明书评审要点l需求评审实践需求阶段的角色和职责〔1）软件开发项目经理软件开发项目经理软件开发工程师软件开发工程师A、带领项目组分析审核工作任务书B、带领项目组与系统工程师进行需求交流并 进行分析和文档化C、组织SRS文档评审D、组织需求跟踪A、完场SRS文档B、完成需求跟踪C、参加SRS reviewD、根据SRS评审专家意见，修改SRS文档E、参加系统测试计划的评审需求阶段的角色和职责〔2）软件经理软件经理QAA、在SRS评审结束后，批准SRS文档A、监督项目组遵循需求管理流程B、参加相关文档reviewC、保证相关组参加文档reviewCCB负责人负责人A、控制需求的变更需求阶段的角色和职责〔3）软件测试项目经理软件测试项目经理软件测试工程师软件测试工程师A、参加开发人员的软件需求分析，提出可测试性需求B、组织人员参加SRS的评审工作C、软件系统测试计划写作D、组织系统测试计划的评审E、组织本阶段测试需求跟踪A、参加SRS评审工作B、协助软件测试项目经理完成软件系统测试计划写作C、参加系统测试计划的评审D、完成本阶段测试需求跟踪软件需求评审的输入1、软件需求规格说明书；2、项目工作任务书；3、软件需求规格说明书Checklist；软件需求评审专家l接受过关于Review的目标、原则和方法培训的人员l主要的候选Review人员来自Review人员资源池种涉及l 该工作产品所处生命周期上一阶段、当前阶段和后一l 阶段的Review人员l受影响组的成员〔如测试工程师）l与Review工作产品有关的同行软件需求评审组织者l接受过关于Review的目标、原则和方法培训的人员l接受过如何领导Review团队培训的人员软件需求评审过程基本原则l任何一次Review最少需要3人〔1个作者和2个Review人员）l任何一次Review最多需要7人〔1个作者和6个Review人员）l需求规格说明书的Review规模不超过40页l作者在提交检视对象前，首先进行自检l组织者可以根据Review工作产品的Checklist来定制本次Reviewl 的Checklist，保证Review质量软件需求评审过程基本原则〔续）l组织者应当根据被Review对象的规模及复杂程度为检视者留出l 足够的准备时间〔对Review规模不超过40页的工程文档，建议l 准备时间为2~3天）lReview会议时间一般为两小时，但组织者也可根据被Review对l 象的类型及规模来调整l在Review会议上组织者根据返工带来的影响程度〔如修改量的l 大小、是否影响到关键的功能和算法〕等来决定是否需要再l Review。

同时还可以参考本次Review的效果〔如果是否达到质l 量目标〕来决定是否需要再Review软件需求评审输出l根据评审专家意见修改后的软件需求规格说明书l软件需求规格说明书评审表格〔评审记录表单）课程内容l软件需求规格说明书介绍l软件需求规格说明书写作要点l需求规格说明书评审流程介绍l软件需求规格说明书评审要点l需求评审实践软件需求规格说明书评审要点1、是否所有的分配需求都在SRS中体现？2、在SRS中定义需求时，是否避免使用那些会引起歧义的术语， 诸如也许、可能等，每条需求都清晰无歧义？3、是否在SRS中清楚地描述了软件要做什么及不做什么？4、是否在SRS中描述了软件使用的目标环境，指明并简短描述了 目标环境中其它相关软件产品/子系统/模块？5、是否每一个具体需求都有唯一的编号？6、每一个需求是否切实可行、可测试、前后一致、彼此不冲突？7、是否在SRS中说明了对每个输入的验证措施，并描述了每个输 入的属性如：度量单位、边界值、时序要求等等？课程内容l软件需求规格说明书介绍l软件需求规格说明书写作要点l需求规格说明书评审流程介绍l软件需求规格说明书评审要点l需求评审实践。