完成系统级安全需求定义之后，按照 GB 44721‑2026 的开发管控逻辑，需要将系统安全需求进一步分解、分配，转化为软件安全需求。很多项目容易出现系统安全需求无法下传到软件层，软件模块缺少对应的安全约束，导致安全设计缺失。借助 ASPICE SWE.2 软件需求过程域，可以标准化完成安全需求分层落地，保障安全约束贯穿软件研发全流程。

ASPICE SWE.2 要求基于系统需求导出软件需求，明确软件功能、接口、性能、安全约束，该流程正好承接 SYS.2 输出的系统安全需求。在进行需求分配时，依据系统架构划分，把系统安全需求分配到对应的软件组件，形成软件安全需求条目。

编制软件安全需求时，需要区分通用软件模块与机器学习模型模块。普通软件组件遵循 SWE.2 常规要求；涉及 AI 模型的组件，需要结合 ASPICE MLE 过程域，增加模型推理异常处理、模型输入校验、模型输出超限保护等软件安全需求，管控 AI 带来的特有安全风险。

软件安全需求同样需要满足可测试、无歧义的编写原则，不可以直接复用高层系统安全目标作为软件需求。每一条软件安全需求，都要维护向上追溯至系统安全需求、风险项的追溯链路，出现问题时可以反向溯源，定位源头安全目标。

软件需求定稿后执行正式评审，重点核查安全约束是否完整、分配是否合理。评审通过后纳入配置管理基线。当上游系统安全需求发生变更，触发 SUP.10 变更管理流程，同步更新软件安全需求，防止系统层与软件层安全需求不一致。

软件安全需求是后续软件设计、编码、单元测试的直接输入。只有做好安全需求分层转化，才能够让 GB 44721‑2026 的安全要求真正落到软件代码层面，而不是停留在顶层文档，同时积累 ASPICE 评估所需全套需求证据。