测试管理:需求开发与管理过程(2)

发表于:2022-3-02 09:47

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:孟小梦    来源:CSDN

分享:
  3.3. 编写《需求规格说明书》
  需求分析师在需求分析过程中根据分析步骤逐步编制形成《需求规格说明书》。编写需求规格说明书应遵循以下规则:
  · 相关的需求都得到了识别与描述,以确保需求的完整性;
  ·  各个需求之间不冲突,算法之间不相互矛盾,以确保需求的一致性;
  ·  正确描述系统需求,引用的资料有正规的出处,以确保需求的正确性;
  ·  定义必要的术语,适当结合图形、结构图等方式进行描述,以确保需求无二义性;
  ·  使用较好的文档结构与需求标识,使需求能够方便地与其它工作产品相对应,以确保需求易于追溯;
  ·  确保所描述的需求可以通过适当的手段得到验证,即需求的可测试性;
  ·  考虑了各个层次的需求,确定了需求的优先级,以确保需求的可行性。
  《需求规格说明书》可以包括但不局限于:
  ·  需求描述约定
  ·  系统概述,如系统功能、业务描述、数据流程描述、用户的特点、运行环境要求、设计与实现上的限制等
  ·  功能需求描述
  ·  非功能性需求,如系统性能要求、数据备份与恢复要求、系统日志等。
  ·  外部接口说明,如软硬接口、通信接口等
  ·  其它需求描述
  ·  功能列表等
  4. 需求确认
  需求确认是指项目组和客户(或客户代表)共同对《需求规格说明书》进行评审,双方对需求达成共识后做出承诺。需求确认包含两个重要工作:“需求评审”和“需求承诺”。
  4.1. 需求评审
  应对所形成的需求文档进行评审,以便作为下一阶段工作的基础。需求评审的方式分为“技术评审会议”。
  项目组根据需求分析的进展情况,采用“组内评审”的方式分阶段对需求分析的阶段成果进行评审,分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审,降低了需求返工的风险,提高了评审的质量。组内评审要求:
  ·  评审组长:项目经理
  ·  评审组成员:需求分析师、系统分析师、测试工程师,适当邀请组外专家参与
  ·  输入:《需求规格说明书》初稿
  ·  输出:会议纪要
  ·  检查单:需求评审检查单
  项目组只有在完成组内评审、并完成问题修改与验证后,方可向公司提出技术评审会议申请。当需要召开技术评审会议时,由项目组向项目管理部门提出需求技术评审申请和组内评审会议纪要,项目管理部门完成文档规范性、完整性检查,并确认已经通过内部评审后,提交评审管理部门,由评审管理部门组织按“技术评审会议”的方式实施需求评审。技术评审会议要求如下:
  ·  评审组织部门:评审管理部门
  ·  评审组成员:
  a)  项目组代表
  b)  测试组代表
  c)  公司的技术专家与业务专家
  d)  实施组代表
  e)  客户或客户代表
  f)   系统关联组代表
  g)  QA工程师
  ·  输入:需求规格说明书以及相关文档
  ·  输出:评审报告
  ·  检查单:需求评审检查单
  关于“技术评审会议”的要求详见《评审规程》。
  4.2. 需求承诺
  项目经理将评审通过的《需求规格说明书》提交给客户(或客户代表)、系统关联项目组进行确认,确认的方式可以是以下方式之一:
  ·  直接签字:由承诺方在评审报告上直接签字或盖章确认
  ·  邮件方式:由项目经理将《需求规格说明书》与评审报告通过邮件发送给接收方,并明确确认通过的准则(如:如果在一周内未予以回复则默认为确认通过)
  ·  发送会议纪要函:如果承诺方参加了评审会议并在会上达成了共识,则可以编制会议纪要在纪要中描述参加评审的人员、评审的结论等,并通过纪要函的方式发送给承诺方
  4.3. 建立需求基线
  项目的需求规格说明书经过评审与确认后,应根据《配置管理过程》的要求建立需求基线。
  5. 需求变更
  对一个软件项目来说,无论最初的需求分析有多么明确,开发过程中的需求变化也还是不可避免的。这主要有以下几种原因:
  1)软件所应用的外部环境发生变化;
  2)随着用户对软件的熟悉和应用,又提出新的需求;
  3)项目组进行需求分析时未能彻底分析用户的需求,或分析错误;
  4)用户在开始时不能很全面的知道所需软件的功能。
  5.1. 需求变更申请
  需求变更由变更申请人通过填写《软件变更申请表》向项目组提出进行。
  当项目组接收到项目管理部门的《软件变更申请表》时,应先根据要求进行需求的评估,判断需求的类型、分析需求变更影响到的范围、估算需求实现的工作量(含需求、设计、编码、测试、用户文档编写)、预计可以完成的时间等内容。若估算的开发工作量大于10人月时,项目组可以根据《项目立项过程》的要求向项目管理部提出项目立项申请;若小于10人月,且评估结果与申请部门达成共识,则开发项目组根据《计划变更规程》实施变更,若无法达成共识,则提交研发部进行最终裁定。
  5.2. 需求变更的实施
  项目组根据《计划变更规程》中的要求实施变更。
  在变更完成后,若需要发布新的需求基线,项目组应根据《配置管理过程》中“基线发布”的要求重新建立需求基线,并通知相关的人员。
  6. 需求跟踪
  对一个软件项目来说,当需求确定下来以后,应该保证在软件设计过程中每个需求都被实现,且项目的其它工作产品与需求保持一致。因此,一个比较好的方法就是建立一种需求双向跟踪机制。双向跟踪即:
  ·  正向跟踪:当发生需求变更时,通过从需求向后追溯到下游相关工作产品,可分析出这些关联项是否需要变更,从而达到追溯的目的;
  ·  逆向跟踪。通过从下游工作产品回溯到需求,可分析需求是否得到满足,从而达到回溯的目的。
  进行需求双向跟踪的一个简单的方法是建立一个映射,从需求到设计,从设计到编码,以及从编码到测试用例,把每个需求都映射到对应的位置。这个映射可以用需求跟踪矩阵来实现。
  6.1. 建立需求跟踪矩阵
  当《需求规格说明书》通过评审之后,项目经理应组织根据确定的需求跟踪的粒度编制《需求跟踪矩阵》。项目经理指定人员对需求跟踪矩阵进行个人复查,确保跟踪粒度合理、跟踪项适用。
  6.2. 需求跟踪矩阵的维护与使用
  随着软件设计、编码、以及测试开发的不断推进,项目经理应指定专人在项目的各个阶段产品形成时,将相关的信息填入需求跟踪矩阵,建立阶段工作产品与需求的对应关系,并由项目经理指定人员对其完整、正确、一致性进行确认。对于已纳入需求跟踪矩阵的相关工作产品产生的变更,则由项目经理在每次变更完成后根据变更修改需求跟踪矩阵的对应关系,在每个里程碑时由项目经理指定人员负责对跟踪矩阵的完整、正确、一致性进行确认。
  在项目实施过程中,项目组可以利用需求跟踪矩阵实施相关的控制,如:
  ·  利用需求跟踪矩阵,审核所有定义的需求是否已经在相关产品中得到实现;
  ·  当发生需求变更时,可以利用需求跟踪矩阵受需求变更影响的其它工作产品,确保不忽略每个受到影响的系统元素;
  ·  当相关的工作产品产生变更时,可以向前追溯到与其相关的需求与其它工作产品,从而判断是否需要对这些关联产品进行变更。
  在开发过程中,可以对所有定义的需求的当前开发状态进行跟踪。 

  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号