安全需求已经评审，测试报告也已归档，检查时却发现某条软件需求找不到上级来源，或测试仍对应修改前的版本。这类问题会影响变更分析和验证证据的使用。处理ISO 26262如何建立安全需求双向追踪ISO 26262需求追踪链断裂如何补全，应同时检查关联对象、关系含义和配置版本，避免只补上一条能点击的链接。

　　一、ISO 26262如何建立安全需求双向追踪

　　双向追踪要求能从需求找到其落实位置，也能从下游对象反查来源。项目可以使用需求管理平台或受控表格，具体界面取决于所选工具。

　　1、确定追踪范围和对象标识

　　①依据项目采用的标准版本、安全计划及开发分工，列出安全目标、功能安全需求、技术安全需求，以及适用的硬件和软件安全需求。

　　②为需求、设计对象、验证规格及结果设置稳定标识，记录版本、状态和责任人。不要用可能随排版变化的页码作为唯一定位信息。

　　③明确供应商交付物的编号映射和访问方式，保证外部需求也能定位到约定版本。

　　2、连接上下层需求

　　①从安全目标开始，逐层建立需求来源关系，明确每条下层需求落实了上层需求的哪一部分。

　　②遇到一条需求分配给多个元素时，分别记录分配关系及边界条件；下层存在多条来源时，也应完整保留。

　　③反向抽查下层需求。无法解释来源的条目，应检查其是否来自架构约束、安全分析或接口假设，并补充依据及必要的评审。

　　双向可查询通常可以由同一条关系实现，无需人为复制两条相反链接。关系名称和方向应在项目内统一。

　　3、关联实现与验证证据

　　①将适用层级的需求关联到具体设计元素或实现对象，避免所有需求都只指向同一份大文档。

　　②为需求关联验证规格，写明验证方法、条件及判定准则；随后将执行结果关联到对应验证项。

　　③检查结果记录能否识别被测配置、测试环境和需求版本。已有测试通过记录，也要确认它证明的是当前要求。

　　4、保存可复核的配置基线

　　①在阶段评审前，将需求、设计、测试及追踪关系纳入一致的配置基线，保留审批和变更记录。

　　②从基线导出追踪报告，记录范围及筛选条件；再从报告中的对象反查原始记录，确认后续能够复现。

　　二、ISO 26262需求追踪链断裂如何补全

　　先判断断在访问位置、关系本身还是证据内容，再决定修复方式。不同原因不能靠批量重建链接一起解决。

　　1、区分显示缺失与对象失效

　　①选择一条断链，记录源对象、目标标识、版本及原关系类型，保留当前问题截图或检查记录。

　　②检查当前分支、基线、产品变体、筛选条件和访问权限，确认目标是否只是未显示。

　　③通过稳定标识搜索目标，再检查迁移后的地址、导入映射及连接配置；找到正确版本后，修复定位并验证反向查询。

　　若目标已经删除或被新对象替代，应查看变更记录确认替代关系，不能仅凭名称相近直接连接。

　　2、补足需求分解或实现内容

　　①对确实没有下级落实对象的需求，检查分配是否遗漏、设计是否尚未完成，或原需求已被批准撤销。

　　②以“检测异常并进入安全状态”为例，核对下层是否分别落实检测条件、响应时限及状态切换。只关联异常检测模块，无法说明其余要求已经落实。

　　③由相应责任人补充需求、设计或验证规格，完成评审后建立关系。确有不适用项时，按项目流程记录理由和审批依据。

　　④对新增或改动内容进行影响分析，将涉及的接口、相关需求及验证活动纳入变更范围。

　　3、更新失效的验证关联

　　①比较断链两端的历史版本，检查阈值、时间限制、运行模式和接口条件是否变化。

　　②根据差异更新验证规格及测试用例，执行受影响的验证活动，将新结果关联到当前配置。

　　③组织复核后关闭问题，保留修复前后的关系、变更依据和验证记录。只有旧结果足以支持当前要求且理由经过确认时，才保留沿用结论。

　　三、ISO 26262需求追踪如何持续检查

　　追踪矩阵适合查缺项，变更检查适合发现已有关系是否需要复核。以下以Requirements Toolbox为例说明操作，工具检查结果仍需结合需求内容判断。

　　1、使用矩阵定位未关联对象

　　①生成追踪矩阵时，选择需要比较的需求集、模型或测试文件，点击【Generate Matrix】，核对行列对象及版本范围。

　　②使用【Missing Links】筛选未关联项，或点击【Highlight Missing Links】高亮显示；逐项判断该对象是否应当建立关系。

　　③查看单元格中的源、目标及关系类型，并分别打开两端对象。该工具的未解析链接不显示在矩阵中，还应另查链接解析问题，避免漏掉失效目标。

　　2、复核变更后再清除提示

　　①在需求编辑器中打开需求集，通过【Information】→【Change Information】显示变更信息，点击【Refresh】运行检查。

　　②点击【Show Links】，选择有变更问题的关系，对照两端内容判断是否需要修改设计、需求或测试。

　　③完成影响处理后，再使用【Clear Issue】清除提示，并在【Comments】中记录处理依据；矩阵可通过【Update】刷新。

　　④将检查安排到需求修改、分支合并和交付基线建立等节点，指定问题责任人，跟踪到证据完成复核。

　　总结

　　解决ISO 26262如何建立安全需求双向追踪ISO 26262需求追踪链断裂如何补全，需要让来源、实现和验证证据处于可解释、可复现的关系中。链接数量齐全并不能证明需求已经落实，旧测试通过也未必支持修改后的要求。发现断链后，应查明缺失原因，补足相关工作，再完成评审和验证。希望这些方法能帮助大家检查追踪记录，把问题处理依据保留下来，方便后续变更与交付复核。如有相关需求，欢迎联系我们咨询。