为什么需求可追溯性对于当今的嵌入式系统仍然很重要

俗话说，“未能构建正确的产品或构建正确的产品”的成本会影响收入和声誉。构建“正确产品”的唯一方法是开发既有效又可追溯到软件的需求。这使开发团队、质量保证 （QA） 和认证机构能够检查软件中的任何功能，通过将其追溯到需求来确定其用途。

挑战在于了解如何在当今动态市场条件和更短的发布时间驱动的快速变化的软件面前保持需求可追溯性。了解双向可追溯性并知道如何维护它可确保产品功能是合理的，反之，没有理由地构建任何东西。

失败的代价

如果客户认为产品功能受到损害，并且如果出现召回或安全漏洞，则不可避免地会造成灾难性的收入或声誉损失。例如，特斯拉今年早些时候因与挡风玻璃除霜相关的软件错误而召回了汽车[1]。在特斯拉的其他召回中，许多与自动驾驶有关，这说明了管理所有可能场景的复杂性，以及快速识别、修复和更新软件以最大限度地降低成本和声誉损害的需求。

Deepanshu Natani 在 Atlassian 社区发表的一篇文章“需求管理中的挑战”写道[2]：

“分析师报告说，多达71%的软件项目失败是因为需求管理不善，使其成为项目失败的最大原因 - 比糟糕的技术，错过最后期限或变更管理惨败更大。

从编写良好的要求开始

每个软件项目的基础都是它的需求。它们应该是精确和明确的，引导软件开发朝着清晰、可测试且可追溯到特定目的的方向发展。

编写要求有几种方法，其中文本规范是最流行的方法。文本可以非常有效，包括使用通俗语言，以便更广泛地理解更接近具体实施计划的技术术语。

由于人类语言本质上是不精确的，容易产生歧义，因此需要高度的严谨性来克服可能的陷阱。将经过验证的规则应用于需求有助于避免问题 - MISRA 编码标准提供了这些规则的示例[3]：

使用段落格式将要求文本与非要求文本区分开来

每个段落仅列出一个要求

使用动词“应”

避免在需求中使用“and”，并将重构视为多个需求

避免使用“除非”或“仅当”等条件，因为它们可能会导致模棱两可的解释

图 1 列出了有效需求的十个属性。

[图1.有效要求的十个属性。（资料来源：LDRA）]

确保适当的需求可追溯性

必须实施所有要求。同样，反之亦然——所有源代码（和所有测试）都应该可以追溯到设计，并最终追溯到需求（功能性或非功能性）。

当需求开始发生变化时，挑战就来了。若要快速有效地管理更改的影响，需要修改相关要求或添加新要求，请务必了解如何在代码中反映更改以及验证更新所需的测试中。

图 2 说明了需求和测试之间的典型关系[4]。在这里，系统级需求 （SLR） 应该可追溯到高级需求 （HLR），而高级需求又可追溯到低级需求 （LLR）。HLR 可追溯到高级测试 （HLT），LLR 可追溯到低级别测试 （LLT）。

这种双向可追溯性使团队能够看到从需求规范到构建、测试、更改和返回的可见性（图 2）。

[图2.不同类型需求之间的典型可追溯性结构。（资料来源：LDRA）]

在不失去可追溯性的情况下管理变更意味着需求和测试的耦合必须自动化 - 这也使得了解测试和需求变更的上游和下游影响变得简单。

验证需求满足情况

证明系统满足要求有助于量化“构建了正确的系统”。这有两种风格：

使用单元测试来证明应用程序组件单独满足其各自的目的

使用集成测试来显示应用程序的各个部分作为一个整体协同工作

自动化和自动化工具通过将单元和集成测试与其适当的要求联系起来并报告履行情况，而无需耗时的手动工作，从而提供帮助。图 3 说明了需求管理平台中的两个场景[5]：

HLR_100 –绿点表示满足要求，反映了已验证关联的高级测试 （TCI_HLT_100） 和低级别要求（LLR_104 到 LLR_109）的事实。

HLR_101 –红点表示需求未满足，反映低级别需求LLR_103由于低级别测试TCI_LLT_103失败而未满足的事实。

[图3.使用自动化工具报告需求履行情况。（资料来源：LDRA）]

在后一种情况下，失败的测试具有关联的测试用例文件，可以使用单元测试工具和关联的回归报告进行回归，以帮助了解测试失败的原因。

确定结构覆盖率

结构覆盖率是嵌入式软件中的一个重要概念，因为它保证了整个代码库已得到一致和充分的执行。作为 ISO 26262、DO-178B 和 IEC 62304 等标准的关键准则，结构覆盖可帮助开发人员检测和删除死代码，而质量保证 （QA） 则使用它来确定缺失的测试用例。在这两种情况下，将此覆盖范围追溯到需求有助于确保每个已实现的组件都有一个原因，并确定尚未实现的要求。

自动化有助于确定结构覆盖率，显示随着基于需求的测试完成而执行代码的哪些部分[6]。图 4 展示了一个测试验证报告，其中显示了不同类型的覆盖指标的结果：

[图4.使用自动化工具报告结构覆盖率（来源：LDRA）]

陈述–在执行应用程序时执行的语句数，占该应用程序中语句总数的百分比。100% 覆盖率意味着所有语句在测试期间至少执行过一次。

分支/决策 –在执行应用程序时执行的分支数占该应用程序中语句总数的百分比。

单声道/直流 –修改条件/决策覆盖率 （MC/DC） 衡量决策陈述中的所有条件是否至少对所有可能的结果进行一次评估，以及所有这些条件是否独立地影响决策的结果。

图 5 显示了这些测试与其相关的低级需求之间的映射，以形成可追溯性矩阵。在此示例中，所有要求 （LLR_*） 均已使用测试 （TCI_LLT_*） 进行验证。这种类型的报告只能通过应用此处讨论的可追溯性原则来实现。

[图5.一个可追溯性矩阵，显示映射到测试用例的需求验证。（资料来源：LDRA）]

可追溯性确保制造出“正确”的产品

团队绝不能将系统和软件要求降级到货架软件中。随着产品变得越来越复杂，软件更新的频率越来越高，需求可追溯性对于最大限度地降低风险仍然是相关性和必要的。

了解需求实施和测试的方式和位置可确保软件适合用途。在软件更改中保持这种意识可确保开发人员了解对代码和测试的影响，而无需花时间搜索它们。

自动化是动态保持双向需求可追溯性并确保产品“正确构建”的唯一现实方法。没有它，团队将花费太多时间试图手动解决，从而导致成本增加和下游的潜在问题。

审核编辑：郭婷