ASPICE SWE.1 软件需求分析是软件工程组的起始过程，承接 SYS.2 输出的系统需求，转化为面向软件实现、可编码、可测试的软件需求，是软件架构、详细设计、单元测试的输入。很多团队落地 ASPICE 时，跳过转化分析环节，直接复用系统需求作为软件需求。系统需求面向整车 / 系统层面，关注能力目标；软件需求面向代码实现，需要明确接口、时序、数据、异常处理逻辑。二者混同之后，开发人员无法精准把握实现范围，测试用例难以设计，抽样评估时经常被指出需求粒度不适配、缺少软件侧约束。

落地 SWE.1 软件需求分析，高频踩坑点集中在四类。软件需求只是系统需求的复制，没有补充软件接口、数据格式、时序约束、异常处理等软件专属要求；系统、软件两层需求粒度没有拉开，一条粗颗粒系统需求直接对应大量底层代码，中间缺少软件层承接；安全、网络安全相关需求没有同步拆解到软件条目，ASIL 等级、防篡改要求只停留在系统文档；需求变更只更新上游系统需求，软件需求、软件侧追溯链路没有同步刷新，形成追溯断点。

SWE.1 的核心不是文档搬运，而是基于系统需求，结合软硬件划分结果，完成面向软件实现的细化、约束补充、冲突检查与确认，形成独立的软件需求基线。

亚远景 APMS 研发过程管理平台支撑 SWE.1 全流程需求管理。平台支持从系统需求一键派生软件需求，自动维护上游系统需求到软件需求的追溯关系；支持标注软硬件分配结果，明确哪些约束由硬件承担、哪些由软件实现；软件需求可以标记功能安全等级、网络安全属性，和安全分析条目关联；所有软件需求要求明确验收标准，保障可测试；变更触发时自动提示下游软件需求、设计、用例同步更新，基线版本统一留存，评估时证据可快速调取。

亚远景 DPAI 垂类 AI 辅助做需求质量预审，识别软件需求里模糊描述、缺失接口定义、缺少异常分支的条目，给出优化建议；辅助区分系统描述和软件实现描述，减少工程师重复梳理工作量。需求评审、确认决策依旧由软件工程师、安全工程师完成。

亚远景 PCAT 过程能力评估工具预置 SWE.1 检查清单，内部预评估阶段核查软硬件边界、需求可验证性、追溯链路完整性，提前识别边界混淆、派生缺失等弱项，在正式评估前闭环整改。

工具负责链路维护、版本管控、风险提示，但需求拆解、软硬件边界判定、安全约束落地，必须依靠工程师评审确认。把 SWE.1 做好，打通系统需求到软件需求的转化链路，软件研发的源头输入才能稳定可靠，夯实 ASPICE 软件工程域的评估基础。