微可追踪性——不同项的要素之间关联的证据

可追踪性是DO-178B/C中的一个重要概念，其定义如下：

不同项之间关联的证据。如过程输出之间关联，输出及其过程之间关联，或需求及其实现之间关联。

DO-178B中关于可追踪性指南包括：

a. 应提供系统需求和软件需求之间的可追踪性，以便能验证系统需求实现的完整性。通过可追踪性还能直观地看出派生需求。

b. 应提供低层需求和高层需求之间的可追踪性，以便能直观地看出派生需求和软件设计过程中设计的体系结构。通过可追踪性还能验证高层需求实现的完整性。

c. 应提供源代码和低层需求之间的可追踪性，以便能验证不存在无需求的源代码。通过可追踪性还能验证低层需求实现的完整性。

在工程实践中，通常用追踪矩阵表达不同项之间的追踪关联。例如，系统需求中的每一条需求与软件需求中的每一条需求都建立了关联，则认为这两层需求之间具备了可追踪性。

建立可追踪性的工具有office软件、需求管理工具和应用生命周期管理工具等。这些工具一般不能自动地建立追踪关联，还是要由使用者来判定项与项之间确有关联，然后操作工具建立关联。

但是，关联的准则是什么？我查阅了很多资料，没有找到相关的论述。

由于没有明确的、统一的准则，开发人员各自为政地凭自己的技术知识和经验建立追踪关联，验证人 员也是相似地进行验证，这就导致有些关联比较勉强，甚至是错的。

需要建立追踪关联的项一般使用自然语言或建模语言描述。这些项包含一些要素，如名称、属性、条件、参数等。可关联的两个项必定有可关联的要素。因此，我们可以把项与项之间的可追踪性细化为项与项的要素之间的可追踪性，即称之为微可追踪性。

以下是一条系统需求：

System Requirement 1.a.b: “The FDAC shall detect and accommodate the NL signal for open and short circuit failures, and range failures per hardware dependent software requirements specification limitations.”

以下是对应的软件高层需求：

Software High-Level Requirements 2.b.c: “If the NL rotor speed is outside the range of 5% and 95% or if the NL rate of change is greater than 10% per second, then a fault shall be declared.”

上述两条需求中的以下要素是关联的：

系统需求要素	软件高层需求要素
NL signal	NL rotor speed，NL rate of change
failure	fault
detect and accommodate	declared

如果在需求管理工具中增加针对微可追踪性的编辑、高亮、链接、统计等辅助手段，将有利于可追踪性的建立和验证。

（本文写于2016年）