您将学到什么：
- 如何弥合需求，体系结构，设计，验证和验证之间的差距。
- 如何使用需求管理来支持ISO 26262标准。
ISO 26262标准规定，功能安全评估者应考虑是否有足够的要求管理（包括双向可追溯性）实施。该标准未指定评估者应如何完成此任务。但是，可以合理地假设需求和实施之间的连接子集有限，这可能不会引起预期。
客户的一个显然简单要求，例如“设备的软件接口在各个方面都应符合规范ABCD-123，除非在这些要求中明确指出，”。
建筑师和设计团队如何在一系列规格和要求列表中有效地管理这种可追溯性？他们如何确保在开发周期的每个步骤中建立和测试的内容都与原始要求联系起来（图。1）？这尤其具有挑战性，因为需求，架构，设计，验证和验证之间的交接取决于人类的解释，以弥合这些步骤之间的差距。
可追溯性的默认方法
实现可追溯性的最明显方法是通过矩阵，无论是在Jama Connect等专用工具还是Excel电子表格中实施。每行的一项要求，也许是层次结构的，拥有所有权，来源参考，实施参考，状态等。该矩阵是双向参考。
矩阵相对较小时可以很好地工作。也许建筑师将它们分为子团队，并分配对集成符检查子矩阵和系统矩阵之间对应的责任。
但是，当需求数量转移到数千个时，矩阵变得难以管理。矩阵提供了一种组织数据的纪律方法，但不能提供自动化。确保要求和实施之间的对应仍然是一项手动任务。
自动化的第一步
核心问题是在域之间连接截然不同的语言：需求管理，文档，芯片组件，验证以及硬件/软件接口（HSI）描述。软件和机械系统中常见的一种方法是通过应用程序处理（ALM）或产品 - 弗里克斯 - 管理（PLM）解决方案，其中所有开发工具均由单个提供商在共同的保护伞下提供。有了该控制水平，ALM或PLM可以管理这些域之间数据中的可追溯性。
但是，很难看到这种集成如何与电子设计自动化（EDA）工具流相处，在这种情况下，重优先级是在领先的技术和复杂性中保持最新。片上的系统开发团队需要一流的流量，并且不太可能为提供可追溯性的解决方案而定，但以较低的能力为代价。
第二种方法通过连接到实现文件中的数据资产来扩展需求管理工具的范围。需求工具自然没有对这些异物的语义理解，因此捕获，检查和维护这些链接的所有责任仍然完全取决于SOC开发团队。在公共接口下简化了跟踪，但是该方法并不能大大减少手动努力或创建或维护错误的机会。
语义意识的可追溯性链接
有效的自动化需要每个域中的语义理解水平：需求，组装，文档和HSI。没有必要理解所有可能的对象，只有可能通过要求引用的对象。标准有助于“一流的”兼容性：REQIF的要求，用于文档的DITA和用于组装的IP-XACT（XML格式）和HSI。类似的工具大动脉的和谐痕迹可以将所有这些都绑在一起（图2）。
跟踪链接应连接到有意义的对象 - 需求对象，端口宽度，IP版本和配置或寄存器偏移量。这些可以随着需求，实现和验证而发展并保持有效，而不是文件和行号链接。一开始就需要一些努力来建立链接，但是在此之后检查更改的影响是自动的。
此外，有机会从数据中得出许多链接。在IP-XACT中，此类对象很容易找到。有了更多的智能，也可以在文档和需求描述中找到它们。
语义连通性简化了检查问题和诊断问题的完整性。随着开发从概念到建筑师的发展，然后通过单元测试，系统测试和V开发流中的完整系统验证，浮动或不完整的链接立即变得明显，无论是从需求，实施或文档中来看。该问题的根源也很明显。此外，客户或审计师可以立即看到证据表明合规实施符合要求。
