需求跟踪是什么意思?什么是向前追溯,什么是向后追溯?

需求跟踪的内容
    跟踪能力(联系)链(Traceability Link)使你能跟踪一个需求使用期限的全过程,即从需求源到实现的前后生存期。跟踪能力是优秀需求规格说明书的一个特征。跟踪能力联系链记录了单个需求之间的父层、互连、依赖的关系。

    1. 需求跟踪目的
        审核(Certification) 跟踪能力信息可以帮助审核确保所有需求被应用。
        变更影响分析跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。
        维护可靠的跟踪能力信息使得维护时能正确、完整地实施变更,从而提高生产率。
        项目跟踪在开发中认真记录跟踪能力数据,就可以获得计划功能当前实现状态的记录。
        再设计(重新建造)。可以列出传统系统中将要替换的功能,记录它们在新系统的需求和软件组件中的位置。
        重新利用跟踪信息可以帮助你在新系统中对相同的功能利用旧系统相关资源。
        减小风险 使部件互连关系文档化可减少由于一名关键成员离开项目带来的风险。
        测试 测试模块、需求、代码段之间的联系链可以在测试出错时指出最可能有问题的代码段。
    2. 需求跟踪能力矩阵
    3. 需求跟踪能力工具
    4. 需求跟踪能力过程
    5. 需求跟踪能力的可行性

    变更需求代价:影响分析
    “变更是免费的”这种误解是造成项目范围延伸的一个原因。在职业生涯中,绝大多数开发人员会遇到要求添加“没有代价且不影响进度的变更”的要求。对这样奇怪的要求的正确回答是“不行”,变更只能在项目时间、预算、资源的限制内进行协商。

    1. 影响分析过程
        建议的变更涉及的问题核对表
            基准(线)中是否已有需求与建议的变更相冲突?
            是否有待解决的需求变更与已建议的变更相冲突?
            不采纳变更会有什么业务或技术上的后果?
            进行建议的变更会有什么样的负面效应或风险?
            建议的变更是否会不利于需求实现或其他质量属性?
            从技术条件和员工技能的角度看该变更是否可行?
            若执行变更是否会在开发、测试和许多其他环境方面提出不合理要求?
            实现或测试变更是否有额外的工具要求?
            在项目计划中,建议的变更如何影响任务的执行顺序、依赖性、工作质量或进度?
            评审变更是否要求原型法或别的用户提供意见?
            采纳变更要求后,浪费了多少以前曾做的工作?
            建议的变更是否导致产品单元成本增加?如增加了第三方产品使用许可证的费用。
            变更是否影响任何市场营销、制造、培训或用户支持计划?
        变更影响的软件元素核对表
            确认任何用户接口要求的变更、添加或删除。
            确认报告、数据库或文件中任何要求的变更,添加或删除。
            确认必须创建、修改或删除的设计部件。
            确认源代码文件中任何要求的变更。
            确认文件或过程中任何要求的变更。
            确认必须修改或删除的已有的单元、集成或系统测试用例。
            评估要求的新单元、综合和系统测试实例个数。
            确认任何必须创建或修改的帮助文件、培训素材或用户文档。
            确认变更影响的应用、库或硬件部件。
            确认须购买的第三方软件。
            确认在软件项目管理计划、质量保证计划和配置管理计划等中变更将产生的影响。
            确认在修改后必须再次检查的工作产品。
2. 影响分析报告模板 

软件测试需求是开发测试用例的依据,测试需求分解的越详细精准,表明对所测软件的了解越深,对所要进行的任务内容就越清晰,对测试用例的设计质量的帮助越大。详细的测试需求还是衡量测试覆盖率的重要指标,测试需求是计算测试覆盖的分母,没有详细的测试需求就无法有效的进行测试覆盖计算。 软件测试执行阶段是由一系列不同的测试类型的执行过程组成的,每种测试类型都有其具体的测试目标和支持技术,每种测试类型都只侧重于对测试目标的一个或多个特征或属性进行测试,准确的测试类型可以给软件测试带事半功倍的效果。 现有的软件测试分析技术不太成熟,对测试需求和测试类型的分析,所采用的方法主要是根据经验进行收集、整理,该方法依赖于测试设计人员的测试经验,由此方法得出的测试需求、测试类型往往导致测试用例设计不充分,测试覆盖度低,测试目的性不强,容易遗漏等缺陷。 可见,如何对测试需求进行细致的整理分析,明确测试执行时的测试类型,是一个亟待解决的问题。 有鉴于此,本方法的主要目的在于提供一种软件测试需求的分析方法,可以方便、详尽的获取测试需求,明确测试执行时需要实施的测试类型。 为实现上述目的,本方法提供了一种软件测试需求分析的方法,包括以下步骤: a)列出软件开发需求中具有可测试性的开发需求; b)对步骤a)列出的每一条开发需求,形成可测试的分层描述的测试需求; c)对步骤b)形成的每一条测试需求,从GB/T 16260.1-2006《软件工程 产品质量 第1部分:质量模型》中定义的软件内部/外部质量模型来确定软件产品的质量需求; d)对步骤c)所确定的质量需求,分析测试执行时需要实施的测试类型; e)建立测试需求跟踪矩阵,对测试需求进行管理。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值