ISO 26262软件安全需求怎么拆分，ISO 26262软件安全需求怎么做到可追溯，很多团队卡住的原因不是不懂标准条款，而是输入口径不一导致需求写不下去。上游安全目标和技术安全需求偏抽象，下游软件实现又偏细，拆分时如果没有固定模板与链接规则，就会出现同一条需求被多人重复改写，最后测试证据也对不上编号。下面按可直接照做的步骤，把拆分与追溯两件事一次做成闭环。

　　一、ISO 26262软件安全需求怎么拆分

　　1、先把输入源统一成可引用的清单

　　在需求工具中新建一个输入汇总模块，点击【新建】逐条录入安全目标、功能安全需求、技术安全需求、系统接口约束与诊断相关条目，并在【属性】里至少补齐来源编号、ASIL、触发条件、期望安全状态、反应时间口径。录入时不要把同一条内容同时写在两个层级里，先保证每条上游输入只有一个主位置，后面拆分只做链接不做复制。

　　2、把软件安全需求的句式模板固定下来再写内容

　　在软件安全需求模块里先创建模板条目，要求每条需求都能回答四件事，何时触发、做什么动作、多久完成、如何恢复。落地写法可以统一为当满足某触发条件时，软件必须在某时间内输出某动作并进入某安全状态，恢复条件满足后才允许回到正常控制。把这个模板作为评审门槛，写不出触发与观察点的条目先退回重写。

　　3、按端到端功能链拆分到软件可控点

　　以输入采集、状态计算、决策、执行输出、反馈监测这条链为主线，把上游安全要求分解到软件能直接控制的节点。实际操作时先在工具里选中上游条目，点击【创建链接】将其链接到一条待拆分的草稿软件需求，再在草稿里写清对应的输入信号、判定条件、输出接口与状态机切换点，确保每条需求都能对应到具体接口或变量域，而不是停留在抽象表述。

　　4、围绕失效机制补齐检测与处置两类条目

　　把常见失效按传感器异常、通信超时、数据越界、计算溢出、任务阻塞、资源耗尽、存储校验失败分类，每类至少拆两条需求，一条写检测判据，一条写处置动作。写检测时明确阈值、连续次数与去抖逻辑，写处置时明确进入安全状态的优先级、降级路径、锁止条件与告警记录。这样拆出来的条目更容易被单元测试与集成测试直接验证。

　　5、把安全机制拆成可分配到组件的责任清单

　　将故障检测、故障隔离、状态机约束、互斥与资源保护、启动自检、看门狗配合、通信完整性检查等机制拆成独立软件需求，并在【属性】里填写组件归属与责任接口。执行时在需求工具中打开【分配】或类似功能，将条目分配到具体软件组件或任务，分配完成后用视图筛选出未分配条目，确保责任边界清晰可审计。

　　6、拆分完成后用验证反推做一次快速体检

　　对每条软件安全需求，在评审前先补齐验证方式字段，在【属性】里选择分析、评审、单元测试、集成测试或系统测试之一，并写出最小可观察证据，例如日志关键字、输出信号、状态机状态值、故障码。若无法写出证据，就把需求改写到可观察的程度再进入基线。

　　二、ISO 26262软件安全需求怎么做到可追溯

　　1、先把编号规则与链接类型固化为团队共识

　　在需求工具里建立软件安全需求的编号规则，例如SSR加四位流水，并在模块设置里启用自动编号。再定义固定链接类型，例如分解自、满足、验证于、实现于，要求所有人只能从下拉列表选择，不允许自由输入。这样后续导出矩阵时链接语义不会混乱。

　　2、建立上游追溯链，先追到技术安全需求再追到安全目标

　　在软件安全需求模块选中条目，点击【创建链接】选择分解自，将其链接到对应的技术安全需求或功能安全需求。完成后打开【追溯视图】按上游展开，检查每条软件需求是否至少有一条上游链接，缺链条目直接标记为不通过并退回补齐。

　　3、建立下游三线追溯，设计线实现线验证线分开做

　　设计线把软件安全需求链接到软件架构元素与接口规格，操作上在架构条目中点击【创建链接】选择满足并指向软件需求。实现线把需求链接到代码模块或配置项，可用代码管理系统的需求编号标签，或在工具中维护到文件与模块的关联。验证线把需求链接到测试用例与测试结果，在测试管理中创建用例时把需求编号写入字段，并在用例条目中点击【链接需求】建立反向链接，保证需求到用例与结果都能一键下钻。

　　4、用追溯矩阵做例行核对，优先抓断链与错链

　　每个迭代节点在工具里打开【Traceability Matrix】或【追溯矩阵】，选择从安全目标到软件需求到测试结果的链路，点击【生成】后导出为文件。检查三类问题，上游缺链、下游缺链、链接类型不一致。对多对多过度绑定的情况，按ASIL与组件视图分组收敛，确保每条测试失败能明确影响哪些软件安全需求。

　　5、把需求状态与证据状态联动，避免追溯只停在文档

　　在软件安全需求的【属性】里增加验证状态字段，常用值可设为未开始、进行中、已验证、阻塞。每次测试执行完成后在测试结果条目里点击【生成报告】或【导出结果】，并把结果链接回对应需求，再将需求状态更新为已验证。这样追溯链不仅有链接，还能体现证据是否真实存在。

　　6、用基线锁住版本维度的可追溯

　　在里程碑节点对需求模块点击【建立基线】，同时对架构与测试集建立同一版本标签。后续如果发生缺陷复盘或审计抽查，可以用基线号直接还原当时的需求内容、链接关系与测试证据，避免只在最新版本上看起来可追溯但历史版本不可复盘。

　　三、ISO 26262软件安全需求变更怎么管控

　　1、把变更入口统一到一张变更单再动需求

　　任何阈值调整、反应时间调整、接口变化、责任组件变化，都先提交变更单并在变更单中写清影响假设。执行时在工具里点击【新建变更】或在变更模块点击【新建】，把涉及的需求编号与ASIL一并录入，未获批准不直接改需求正文。

　　2、用影响分析清单把要改的对象一次列全

　　在需求条目上打开【追溯视图】点击【展开】逐层展开到架构与测试，导出受影响列表，形成设计、实现、验证三类待更新清单。先改链接与引用关系，再改需求正文与参数值，最后再跑一遍追溯矩阵确认断链没有新增。

　　3、变更后按ASIL与机制类型切回归范围

　　将回归范围按故障检测、故障反应、状态机切换、降级与恢复、通信完整性分组，并在测试管理中对用例集点击【筛选】按需求编号批量拉取回归集。把回归选择理由写入变更单，便于审核时说明为什么不是全量回归。

　　4、把交付证据清单固定成模板，发布前逐项生成

　　发布前至少生成需求基线、追溯矩阵、评审记录、测试用例清单、测试结果报告与异常处置记录。执行时在工具里分别点击【导出】或【生成报告】输出对应文件，并以基线号命名目录归档，保证任何一次交付都能被复核。

　　5、把现场问题回填到需求与追溯链里，形成闭环

　　现场缺陷定位到某条软件安全需求或某条测试用例后，在对应条目上点击【新建链接】把缺陷单与需求、用例关联，并在需求条目中补充限制条件或边界假设。回填完成后重新建立一条增量基线，确保下一次审计看到的是修复后的完整证据链。

　　总结

　　ISO 26262软件安全需求怎么拆分，关键是先统一输入清单与句式模板，再按端到端链路与失效机制把需求拆到可观察可验证的程度，并用【分配】把责任落到组件。ISO 26262软件安全需求怎么做到可追溯，需要固化编号与链接类型，用【创建链接】把上游安全目标与下游架构、实现、测试结果三线贯通，再用【追溯矩阵】与【建立基线】把版本维度的证据链长期稳定住。