SYS.1 需求挖掘的核心，不只是收集各方诉求，更重要是和利益相关方达成正式共识，当诉求发生变化时开展变更分析，同步把变更信息传递给所有受影响方。实际车载研发中，客户口头提出调整点、生产制造反馈约束条件、售后反馈使用痛点，各类新诉求源源不断。部分开发团队为赶进度，直接把新诉求写入需求文档，跳过共识评审，也不通知其他受影响团队。旧的需求基线被改动，但部分参与前期确认的利益相关方并不知情。等到后续系统设计、软件实现阶段，不同团队拿着版本不一致的需求，矛盾集中爆发，大量返工，在 ASPICE 评估抽样检查时，会发现利益相关方需求变更缺少完整分析与确认证据。

落地 ASPICE SYS.1 需求挖掘，经常遇到几类典型现实问题。利益相关方清单静态不变，项目迭代过程新增的角色没有纳入清单，新诉求来源没有被识别。口头、会议提出的诉求没有转化成正式记录，缺少诉求来源信息。诉求发生改动直接修改文档，不走变更流程，不做影响分析。需求变更之后，不重新获取利益相关方的确认，直接生效。变更完成后，没有把变更内容同步给到全部受影响岗位，部分团队继续使用旧版本需求。需求基线更新不及时，多版本需求混杂，分不清哪一份是已经达成共识的正式版本。

SYS.1 明确，利益相关方的期望不能拿来直接当做正式需求，必须经过分析权衡、多方达成共识；哪怕是后续发生变更，同样需要遵循这套逻辑，不能口头改需求就直接落地。

亚远景 APMS 研发过程管理平台维护完整的利益相关方清单，项目迭代中可以补充新增角色。每一条诉求记录提出人、提出时间，经过分析权衡之后形成利益相关方需求，完成多方确认之后冻结需求基线。一旦利益相关方提出修改诉求，触发变更流程，开展变更影响分析，评估改动对下游系统需求、项目进度带来的影响，重新获取利益相关方确认，更新基线，同时向全部受影响方推送变更通知。所有历史基线完整保存，方便 ASPICE 评估调取查阅。

亚远景 DPAI 垂类 AI 可以梳理零散会议纪要、客户邮件，提取潜在的利益相关方诉求，给出录入参考，诉求的权衡、评审确认依旧需要项目各角色人工完成。

亚远景 PCAT 过程能力评估工具预置 SYS.1 专项检查点。内部预评估阶段核查利益相关方清单、诉求记录、变更分析与确认证据，识别口头改需求、跳过共识确认的问题，正式 ASPICE 评估之前补齐短板。

工具负责诉求归档、基线管控、变更提醒，但诉求的权衡取舍、多方共识确认，必须依靠各个业务岗位人员完成。管好利益相关方需求的变更流程，守住需求共识基线，才能够落实 SYS.1 各项基础实践，满足 ASPICE 评估取证要求。