不少车载项目存在两套需求管理模式，一套用来做 ASPICE 过程执行，另一套单独维护 HARA、TARA 导出的安全需求。做 ASPICE 工作的时候更新 ASPICE 需求文档，做安全分析的时候修改安全需求文档，两边没有建立强关联。版本迭代之后，同一条需求在 ASPICE 需求库和安全文档当中描述出现出入。这类问题在 ASPICE 评估以及功能安全审核中经常被指出来。

ASPICE 的需求工程过程，要求做好需求的分解、追溯、变更管控；而 ISO26262、ISO/SAE21434 产出的安全目标、安全需求，需要流入正常研发链条。如果两套体系完全割裂，会衍生很多现实问题。安全需求没有录入 ASPICE 需求库，ASPICE 追溯矩阵覆盖不到安全相关条目。需求发生变更，只修改 ASPICE 侧需求，没有同步复核 HARA、TARA，或者安全需求改动之后，没有同步更新 ASPICE 当中对应的派生需求。ASPICE 评估抽取安全相关需求的时候，找不到完整的 ASPICE 追溯证据。安全审核的时候，又拿不出安全需求在 ASPICE 流程当中流转的记录。

想要同时满足 ASPICE 评估和安全审核，安全需求不能游离在 ASPICE 需求工程过程之外，要把安全目标、安全需求、网络安全需求纳入 ASPICE 统一的需求生命周期进行管理。

需求导入阶段，将 HARA、TARA 输出的安全目标、安全需求导入 ASPICE 需求库，标记 ASIL 等级、CAL 等级，作为上层利益相关方需求或者系统需求。建立安全需求往下派生系统需求、软件需求的 ASPICE 双向追溯链路，让安全需求完整参与 ASPICE 的需求评审、需求分析活动。

变更发生的时候执行双向校验。当 ASPICE 体系内的需求发生变更，需要判断本次改动会不会影响原有安全需求；如果 HARA 或者 TARA 更新产生新的安全需求或者修改旧安全需求，也要触发 ASPICE 需求变更流程，更新 ASPICE 需求库，同步更新 ASPICE 追溯关系。所有变更记录统一留存，作为 ASPICE 评估、安全审核的共用证据。

评审环节做到跨标准协同，开展 ASPICE 需求评审的同时，安全工程师参与进来，确认安全需求派生、分解工作合理，保证既符合 ASPICE 需求工程的要求，又满足 ISO26262、ISO/SAE21434 的约束。

亚远景 APMS 研发过程管理平台，支持把功能安全、网络安全需求统一纳入 ASPICE 需求管理体系。完整维护 ASPICE 双向追溯，安全需求变更会触发联动提醒，所有评审、变更记录统一归档，一套产物同时支撑 ASPICE 评估与安全审核。

亚远景 DPAI 垂类 AI 可以比对 ASPICE 需求内容和安全需求文档，提示两边描述存在差异的条目，供工程师复核修正。

亚远景 PCAT 过程能力评估工具，在内部预评估中核查安全需求在 ASPICE 流程中的落地情况，提前发现需求不同步的风险。

把安全需求纳入 ASPICE 完整的需求生命周期，不再分开两套文档独立维护，才能够同时搞定 ASPICE 评估取证和功能安全、网络安全审核。