今天给各位分享需求可跟踪性的知识，其中也会对需求可跟踪性进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
需求可跟踪性的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于需求可跟踪性、需求可跟踪性的信息别忘了在本站进行查找喔。
本文导读目录：
1、需求跟踪
2、需求可跟踪性
需求跟踪概述 需求跟踪需求跟踪是指跟踪一个需求使用期限的全过程，需求跟踪包括编制每个需求同系统元素之间的联系文档，这些元素包括其他类型的需求，体系结构，其他设计部件，源代码模块，测试，帮助文件等。需求跟踪为我们提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。 需求跟踪的方式 需求跟踪有两种方式： （1）正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。 （2）逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。 正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。 需求跟踪的内容 跟踪能力（联系）链（traceability link）使你能跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。跟踪能力是优秀需求规格说明书的一个特征。为了实现可跟踪能力，必须统一地标识出每一个需求，以便能明确地进行查阅。 图1：四类需求可跟踪能力 图1说明了四类需求跟踪能力链。客户需求可向前追溯到需求，这样就能区分出开发过程中或开发结束后由于需求变更受到影响的需求。这也确保了需求规格说明书包括所有客户需求。同样，可以从需求回溯相应的客户需求，确 认每个软件需求的源头。如果用使用实例的形式 来描述客户需求，图的上半部分就是使用实 例和功能性需求之间的跟踪情况。图的下半 部分指出：由于开发过程中系统需求转变为软件 需求、设计、编写等，所以通过定义单个需求和 特定的产品元素之间的（联系）链可从需求向前 追溯。这种联系链使你知道每个需求对应的产品 部件，从而确保产品部件满足每个需求。第四类 联系链是从产品部件回溯到需求，使你知道每个 部件存在的原因。绝大多数项目不包括与用户需 求直接相关的代码，但对于开发者却要知道为什 么写这一行代码。如果不能把设计元素、代码段 或测试回溯到一个需求，你可能有一个“画蛇添 足的程序”。然而，若这些孤立的元素表明了一 个正当的功能，则说明需求规格说明书漏掉了一项需求。 跟踪能力联系链记录了单个需求之间的父层、互连、依赖的关系。当某个需求变更（被删除或修改）后，这种信息能够确保正确的变更传播，并将相应的任务作出正确的调整。下图2说明了许多能在项目中定义的直接跟踪能力联系链。一个项目不必拥有所有种类的跟踪能力联系链，要根据具体的情况调整。 需求跟踪目的 在某种程度上，需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用。 图2：一些可能的需求跟踪能力联系链 需求跟踪是个要求手工操作且劳动强度很大的任务，要求组织提供支持。随着系统开发的进行和维护的执行，要保持关联链信息与实际一致。跟踪能力信息一旦过时，可能再也不会重建它了。由于这些原因，应该正确使用需求跟踪能力。 下面是在项目中使用需求跟踪能力的一些好处： 审核（certification） 跟踪能力信息可以帮助审核确保所有需求被应用。 变更影响分析跟踪能力信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。 维护可靠的跟踪能力信息使得维护时能正确、完整地实施变更，从而提高生产率。要是一下子不能为整个系统建立跟踪能力信息，一次可以只建立一部分，再逐渐增加。从系统的一部分着手建立，先列表需求，然后记录跟踪能力链，再逐渐拓展。 项目跟踪在开发中，认真记录跟踪能力数据，就可以获得计划功能当前实现状态的记录。还未出现的联系链意味着没有相应的产品部件。 再设计（重新建造） 你可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。通过定义跟踪能力信息链提供一种方法收集从一个现成系统的反向工程中所学到的方法。 重复利用跟踪信息可以帮助你在新系统中对相同的功能利用旧系统相关资源。例如：功能设计、相关需求、代码、测试等。 减小风险使部件互连关系文档化可减少由于一名关键成员离开项目带来的风险。 测试测试模块、需求、代码段之间的联系链可以在测试出错时指出最可能有问题的代码段。 以上所述许多是长期利益，减少了整个产品生存期费用，但同时要注意到由于积累和管理跟踪能力信息增加了开发成本。这个问题应该这样来看，把增加的费用当作一项投资，这笔投资可以使你发布令人满意同时更容易维护的产品。尽管很难计算，但这笔投资在每一次修改、扩展或代替产品时都会有所体现。如果在开发工程中收集信息，定义跟踪能力联系链一点也不难，但要在整个系统完成后再实施代价确实很大。 CMMI要求具备需求跟踪能力。软件产品工程活动的关键过程域有关于它的陈述，“在软件工作产品之间，维护一致性。工作产品包括软件计划，过程描述，分配需求，软件需求，软件设计，代码，测试计划，以及测试过程。”需求跟踪过程中还定义了一些关于一个组织如何处理需求跟踪能力的期望。 需求跟踪能力矩阵 表示需求和别的系统元素之间的联系链的最普遍方式是使用需求跟踪能力矩阵。下表展示了这种矩阵，这是一个“化学制品跟踪系统”实例的跟踪能力矩阵的一部分。这个表说明了每个功能性需求向后连接一个特定的使用实例，向前连接一个或多个设计、代码和测试元素。设计元素可以是模型中的对象，例如数据流图、关系数据模型中的表单、或对象类。代码参考可以是类中的方法，源代码文件名、过程或函数。加上更多的列项就可以拓展到与其它工作产品的关联，例如在线帮助文档。包括越多的细节就越花时间，但同时很容易得到相关联的软件元素，在做变更影响分析和维护时就可以节省时间。 跟踪能力联系链可以定义各种系统元素类型间的一对一，一对多，多对多关系。表1中允许在一个表单元中填入几个元素来实现这些特征。这里是一些可能的分类： 一对一一个代码模块应用一个设计元素。 一对多多个测试实例验证一个功能需求。 多对多每个使用实例导致多个功能性需求，而一些功能性需求常拥有几个使用实例。 手工创建需求跟踪能力矩阵是一个应该养成的习惯，即使对小项目也很有效。一旦确立使用实例基准，就准备在矩阵中添加每个使用实例演化成的功能性需求。随着软件设计、构造、测试开发的进展不断更新矩阵。例如，在实现某一功能需求后，你可以更新它在矩阵中的设计和代码单元，将需求状态设置为“已完成”。表示跟踪能力信息的另一个方法是通过矩阵的集合，矩阵定义了系统元素对间的联系链。例如： 一类需求与另一类需求之间。 同类中不同的需求之间。 一类需求与测试实例之间。 可以使用这些矩阵定义需求间可能的不同联系，例如：指定/被指定、依赖于、衍生为以及限制/被限制。 下表2中说明了两维的跟踪能力矩阵。矩阵中绝大多数的单元是空的。每个单元指示相对应行与列之间的联系，可以使用不同的符号明确表示“追溯到”和“从.. 回溯”或其他联系。表2中使用一个箭头表示一个功能性需求是从一个使用实例追溯来的。这些矩阵相对于表16-6中的单跟踪能力表更容易被机器自动支持。 跟踪能力联系链无论谁有合适的信息都可以定义。下表3定义了一些典型的知识源，即关于不同种类源和目标对象间的联系链。定义了可以为工程项目提供每种跟踪能力信息的角色和个人。 需求跟踪能力工具 由于联系链源于开发组成员的头脑中，所以需求跟踪能力不能完全自动化。然而，一旦已确定联系链，特定工具就能帮你管理巨大的跟踪能力信息。可以使用电子数据表来维护几百个需求的矩阵，但更大的系统需要更“鲁棒”的解决办法。 具有强大需求跟踪能力的商业需求管理工具均使用如表16 -7的跟踪能力矩阵。可以在工具的数据库中存储需求和其他信息，定义不同对象间的联系链，甚至包括同类需求的对等联系链。有一些工具需要区分“追溯到（跟踪进）”与“从..回溯（跟踪出）”关系，自动定义相对的联系链。这就是说，如果你指出需求R追溯到测试实例T，工具会自动定义相对的联系“ T从R回溯”。还有一些工具可以在联系链某端变更后将另一端标为“可疑”。可以让你检查确保知道变更的后续效果。 这些工具允许定义“跨项目”或“跨子系统”的联系链。一个有20个子系统的大项目，某些高层产品需求建立在多个子系统之上。有些情况下，分配给一个子系统的需求，实际上是由另一个子系统提供的服务完成的。这样的项目采用商业需求管理工具可以成功地跟踪这些复杂的跟踪能力关系。 需求跟踪能力过程 当你应用需求跟踪能力来管理工程时，可以考虑下列步骤： 决定定义哪几种联系链，可以参见图2来进行。 选择使用的跟踪能力矩阵的种类，是表1还是表2。 确定对产品哪部分维护跟踪能力信息。由关键的核心功能、高风险部分或将来维护量大的部分开始做起。 通过修订过程和核对表来提醒开发者在需求完成或变更时更新联系链。 制定标记性的规范，用以统一标识所有的系统元素，达到可以相互联系的目的。若必要，作文字记录，这样就可以分析系统文件，便于重建或更新跟踪能力矩阵。 确定提供每类联系链信息的个人。 培训项目组成员，使其接受需求跟踪能力的概念和了解重要性、这次活动的目的、跟踪能力数据存储位置、定义联系链的技术—例如，使用需求管理工具的特点。确保与会人员明白担负的责任。 一旦有人完成某项任务就要马上更新跟踪能力数据，即要立刻通知相关人员更新需求链上的联系链。 在开发过程中周期性地更新数据，以使跟踪信息与实际相符。要是发现跟踪能力数据没完成或不正确那就说明没有达到效果。 需求跟踪能力的可行性 对有很多子系统的巨大产品进行跟踪能力管理是一项巨大的工程，但这很必要。并不是所有的公司都会因为软件问题而造成严重的结果，然而应该严肃地对待需求跟踪，尤其对涉及你业务核心的信息系统。考虑了应用技术的成本和不使用的风险后，才能决定是否使用任何改进的需求工程实践。随着软件的发展，要把时间投向回报丰厚的地方。 Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018 需求可追溯性 是指能够关联和记录开发过程的两个或更多阶段，然后可以从其起源向前或向后跟踪这些阶段。 需求可追溯性可帮助团队深入了解指标，例如 要求的质量 或交付 要求的准备情况。 需求可追溯性的一个基本方面是将要求关联到测试用例、bug 和代码更改。 阅读术语表以了解测试报表术语。 敏捷团队具有以下特征，包括但不限于以下 更快的发布周期 管道中的持续测试 可忽略的手动测试占用空间;仅限于探索性测试 高度自动化 以下部分从 质量、 Bug 和 源 的角度探讨敏捷团队的可追溯性。 为了确保用户需求满足质量目标，可以将项目中的需求链接到测试结果，然后在团队的仪表板上查看这些结果。 这样就可以通过一种简单的方法来监视测试结果，实现端到端可跟踪性。 若要将自动化测试与需求链接，请访问生成或发布中的测试报表。 在生成或发布摘要的“测试”选项卡下的结果部分中，选择要链接到需求的测试，然后选择“链接”。 选择要以指定方式之一链接到所选测试的工作项： 从建议的工作项列表中选择适用的工作项。 该列表基于最近查看和更新的工作项。 指定工作项 ID。 根据标题文本搜索工作项。 该列表仅显示属于“需求”类别的工作项。 将要求链接到测试结果后，可以查看按要求分组的测试结果。 要求是提供的众多“分组依据”选项之一，用于轻松导航测试结果。 团队通常希望将需求可跟踪性的汇总视图固定到仪表板。 为此，请使用“需求质量”小组件。 使用所需的选项配置“需求质量”小组件并保存。 需求查询：选择捕获需求的工作项查询，例如当前迭代中的用户情景。 质量数据：指定应跟踪其需求质量的管道阶段。 查看团队仪表板中的小组件。 其中列出了范围中的所有需求，还有测试的通过率和失败测试的数量。 选择“失败”测试计数将打开所选生成或版本的“测试”选项卡。 小组件还有助于跟踪需求，而无需任何关联的测试。 为了确保用户需求满足质量目标，可以将项目中的需求链接到测试结果，然后在团队的仪表板上查看这些结果。 这样就可以通过一种简单的方法来监视测试结果，实现端到端可跟踪性。 若要将自动化测试与需求链接，请访问生成或发布中的测试报表。 在生成或发布摘要的“测试”选项卡下的结果部分中，选择要链接到需求的测试，然后选择“链接”。 选择要以指定方式之一链接到所选测试的工作项： 从建议的工作项列表中选择适用的工作项。 该列表基于最近查看和更新的工作项。 指定工作项 ID。 根据标题文本搜索工作项。 该列表仅显示属于“需求”类别的工作项。 团队通常希望将需求可跟踪性的汇总视图固定到仪表板。 为此，请使用“需求质量”小组件。 使用所需的选项配置“需求质量”小组件并保存。 需求查询：选择捕获需求的工作项查询，例如当前迭代中的用户情景。 质量数据：指定应跟踪其需求质量的管道阶段。 查看团队仪表板中的小组件。 其中列出了范围中的所有需求，还有测试的通过率和失败测试的数量。 选择“失败”测试计数将打开所选生成或版本的“测试”选项卡。 小组件还有助于跟踪需求，而无需任何关联的测试。 测试可衡量向用户交付更改的置信度。 测试失败表明更改出现问题。 失败的原因有很多，例如受测源出错、测试代码错误、环境问题、 测试不平等。 Bug 提供了一种可靠的方法来跟踪测试失败，并促使团队负责采取所需的补救措施。 若要将 bug 与测试结果相关联，请访问生成或发布中的 测试报告 。 在“ 测试 ”选项卡的“结果”部分中，选择应针对其创建 bug 的测试，然后选择“ Bug”。 多个测试结果可以映射到单个 bug。 当故障原因归因于单个原因（例如依赖服务不可用、数据库连接失败或类似问题）时，通常会执行此操作。 打开工作项以查看 bug。 它捕获测试结果的完整上下文，包括错误消息、堆栈跟踪、注释等关键信息。 直接在“ 测试 ”选项卡中的上下文中查看包含测试结果的 bug。“ 工作项 ”选项卡还列出了测试结果的任何链接要求。 在工作项中，直接导航到关联的测试结果。 测试用例和特定测试结果都链接到该 bug。 在工作项中，选择“ 测试用例 ”或“ 测试结果 ”，直接转到所选生成或发布的“ 测试 ”页。 你可以对故障进行故障排除，更新 bug 中的分析，并根据需要进行更改以修复问题。 虽然这两个链接均会将你带到“测试”选项卡，但显示的默认部分分别为“历史记录”和“调试”。 排查在一段时间内一直发生的测试失败时，请务必追溯到初始更改集-故障的来源。 这大大有助于缩小识别有问题的测试或受测源的范围。 若要发现测试失败的第一个实例并将其跟踪到关联的代码更改，请访问生成或发布中的 “测试”选项卡 。 在“ 测试 ”选项卡中，选择要分析的测试失败。 根据测试是内部版本还是版本，选择 “生成失败 ”或 “发布失败” 列。 这会在新窗口中打开“ 测试 ”选项卡的另一个实例，显示测试的第一个连续失败实例。 根据生成或发布管道，可以选择时间线或管道视图以查看提交的代码更改。 可以分析代码更改，以确定测试失败的潜在根本原因。 从手动测试转向连续 (自动化) 测试，并且已自动完成一部分测试的团队可以在管道中执行，也可以按需执行这些测试， (查看 测试报告) 。 自动化测试称为计划内测试，可以与测试计划中的测试用例相关联，并从Azure Test Plans执行。 关联后，这些测试将促进相应要求的质量指标。 请查看疑难解答页面 在 Stack Overflow 中获取建议，通过开发人员社区获取支持 Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020 需求跟踪汇总报表基于 需求跟踪报告 ，并演示如何聚合一级汇总的指标。 例如，如果要使用用户情景跟踪要求，则可以使用本文中提供的查询聚合功能的数据。 下图中显示了一个示例。 此报表针对它列出的每个要求显示以下信息： 已完成工时百分比：进度栏，根据与要求关联的所有任务的已完成工时汇总显示已完成工时百分比。 通过的测试：基于最新测试运行通过的测试用例数。 失败的测试：基于最近的测试运行失败的测试用例数。 运行测试：执行的测试运行数。 活动 bug：处于活动状态的链接 bug 数。 已关闭的 bug：处于“已关闭”、“已完成”或“已完成”状态的链接 bug 的数量。 需求跟踪报告可用于回答以下类型的问题。 工作进度 每个要求的剩余工时量是否符合预期？ 是否首先实现排名靠前的要求？ 为每个要求定义了多少个测试？ 有多少测试通过？ 正在实现哪些没有为其定义测试用例的要求？ 质量进度 针对每个要求运行了多少个测试用例，以及已通过多少个测试用例？ 每个要求有多少个活动 bug？ 是否针对正在测试的要求发现了 bug？ bug 是否正在解决，或者它们是否保持活动状态？ 风险评估 哪些要求存在风险？ 哪些要求不足以稳定发布？ 我们今天可以交付哪些要求？ 若要查看分析数据并查询服务，需要是具有 基本 访问权限或更高访问权限的项目的成员。 默认情况下，向所有项目成员授予查询 Analytics 和定义 Analytics 视图的权限。 若要了解有关服务和功能启用以及常规数据跟踪活动的其他先决条件，请参阅 访问 Analytics 的权限和先决条件。 要使报表生成有用数据，需要执行以下任务： 你已定义要求工作项，并将其分配给感兴趣的区域和迭代路径。 有关如何定义区域和迭代路径的信息，请参阅 定义区域路径 和 定义迭代路径。 若要获取完成小时数的百分比，需要填写“ 完成工时 ”和 “剩余工时” 字段，这些任务或 bug 链接到 子 链接类型的要求。 若要获取测试用例的执行状态，你将在与这些要求相对应的Test Plans中创建基于要求的测试套件。 通过看板添加的内联测试满足此先决条件，但链接到测试的要求则不满足。 若要了解详细信息，请参阅 创建测试计划和测试套件。 若要获取 bug 的状态，你将使用 子 链接类型创建 bug 并将其链接到要求。 若要生成报表，必须将三个 Power BI 查询添加到 Power BI Desktop，然后将其链接。 每个查询 执行 或 实体集。 为了将报表范围限定为特定的区域和迭代路径，可以使用 和 筛选查询。 有关详细信息，请参阅 使用 OData Analytics 定义基本查询。 将以下字符串替换为值。 不要在替换中包含括号 {} 。 例如，如果组织名称为“Fabrikam”，请将 替换为 ，而不是 。 - 组织名称 - 项目的名称 - 与感兴趣的 迭代路径 关联的 GUID。 若要查找 GUID，请参阅 [https://docs.microsoft.com/zh-cn/azure/devops/report/extend-analytics/wit-analytics.md#iterationsk] (返回特定迭代路径的 IterationSK) - 与相关区域路径关联的 GUID。 若要查找 GUID，请参阅 [https://docs.microsoft.com/zh-cn/azure/devops/report/extend-analytics/wit-analytics.md#areask] (返回特定区域路径) 的 AreaSK。 下表描述了查询的每个部分。 在“建模”选项卡中，选择“管理关系并按列链接三个查询结果。 在 “可视化效果”下，选择“ 表”。 从三个 Power BI 查询中添加感兴趣的列。 选择 “总和 ”作为累加列（如 “已通过的测试 ”等）的聚合。 此处， 身份验证方案 是两个用户情景的父功能。 使用 OData 查询的示例报表概述 构造用于分析的 OData 查询 使用 Power BI 和 OData 查询进行连接 Azure Boards Analytics 的元数据参考 示例报表和快速参考索引 向现有报表添加团队切片器需求可跟踪性的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于需求可跟踪性、需求可跟踪性的信息别忘了在本站进行查找喔。
未经允许不得转载！ 作者:谁是谁的谁，转载或复制请以超链接形式并注明出处。
原文地址：http://www.kpfe.org/post/9823.html发布于：2025-12-30
