ASPICE SYS.2系统需求分析应当如何开展，以及SYS.2的需求质量应当如何检查，其重点并不是把客户需求换成另一种表述写进系统需求文档，而是要形成一套经过分析、结构清晰、可以验证，并且与利益相关方需求保持一致的完整系统需求。除了功能需求之外，还需要覆盖性能、接口、运行环境、安全、诊断以及各类约束条件，同时要对技术可行性、需求之间的依赖关系以及系统上下文所带来的影响进行分析。

在聊ASPICE SUP.1的配置管理怎么审计、审计出来的问题又该怎么关闭时，要紧的不是单独去查有没有版本号这回事，也不只是翻翻配置库，看文件有没有全塞进去。SUP.1真正操心的地方，是那些工作产品能不能被清楚地认出来并管住，发生了变更之后能不能顺着线索往回追，还有项目在往前跑的过程中，能不能随时都闹明白“当前到底用的哪个版本、是谁在什么时间改的、因为啥改的、这次改动又连累到了哪些别的东西”。所以，给配置管理做审计，就得围着配置项、基线、变更记录，还有最终交付物跟清单能不能对得上号来展开；而问题的关闭，也必须靠着实打实的证据串成一个闭环，不能只丢一句“已整改”就完事。

在功能安全的前期工作里，Item定义该怎么写，Item边界又该怎么去划分，这一步常常容易让人卡住。Item定义并不是给系统写一段普普通通的介绍，也不是把控制器、传感器、执行器都列成一张清单就算完事儿了；它真正要去说明的，是当前要分析的那个车辆功能到底是什么，这个功能需要依赖哪些对象，以及边界内外怎样互相交换信息。

在软件开发评审的时候，有两个问题经常是连在一块儿出现的，一个是怎么去策划ASPICE的集成测试，另一个是在测试做完之后，那些用来证明测试确实被执行了、而且结果有效的证据，又要怎么去保存下来，集成测试这件事，并不是简单地把一堆模块拼到一起去跑上一遍，看见没报错就算结束了，它需要我们能够说清楚，模块之间到底应该按照一个什么样的顺序去集成、它们之间的接口关系是怎样的、测试的依据又是什么、测试是在什么环境里跑的，还有最后出来的结果，有没有形成一个完整的闭环，而保存证据，也不是随随便便地把截下来的图往文件夹里一塞就行了的，它的目的是要让后面来做评审的人，能够顺着需求、设计、测试用例、执行时候的记录，还有对缺陷的处理，这一整条线，一路顺畅地查下去。

在项目进行的过程中，如果只是靠大家在口头上去同步，那么对ASPICE的需求变更进行管理，还有为它留下相应的痕迹，这件事在后期评审的时候，是站不住脚的，需求一旦发生了变动，跟在它后面的系统设计、软件设计、测试用例、验证的结果，还有那些要交付的文件，全部都会被牵动起来；如果我们只是在开会的时候，随口说了一句“这个地方改一下”，那么到了后面做评审的时候，就很难去解释清楚，当时到底是为什么要改、这个改动经过了谁的批准、它影响到了哪些地方、以及改完之后有没有被重新验证过，ASPICE这套东西，它所关注的，就是过程是可以被追溯的，还有变更一定是处于受控状态的，所以，对需求变更的管理，就是要把它的来源、影响、决策、实施，还有验证，这五个环节给串到一条线上。

很多团队一提ASPICE，第一反应都是先补模板、补记录、补评审表，结果资料堆了不少，流程还是容易断在中间。真正难的地方，通常不是某一份文档不会写，而是需求、设计、编码、验证和问题闭环没有按同一条主线串起来。公开资料对这件事讲得很清楚，Automotive SPICE的软件链路本身就是从软件需求分析、软件架构设计、软件详细设计与单元构建，一直连到单元验证、软件集成测试和软件确认测试，而且评估关注的不只是工作产物，还包括过程结果和双向追溯。

很多人第一次接触ASPICE，会把它理解成一套审计清单，或者单纯把它当成车厂供应商准入门槛。这样理解不算全错，但不够核心。按VDA QMC和Automotive SPICE官方资料的口径，ASPICE更准确地说，是汽车领域的一套过程参考模型和过程评估模型，基础来自ISO IEC 330系列，用来描述过程、评估过程能力，并让不同组织在同一把尺子下看研发过程做得怎么样。

在ASPICE实践里，变更本身不可怕，可怕的是变更没有边界与证据，需求改了但影响没评估，代码改了但测试与基线没同步，最后在集成阶段集中爆雷。要把变更做成可控动作，关键是把入口收紧到同一套申请与评审机制里，再让影响分析、实施、验证、基线更新形成闭环，让任何一次变更都能被追溯与复核。

ASPICE审核访谈怎么准备，ASPICE怎么整理访谈问题清单这类问题，通常出现在评估临近或刚做完差距分析之后。访谈不是聊天，它是评估员用来验证过程是否真实运行、证据是否闭环、人员是否理解并按规则做事的关键环节。准备不到位时，最常见的风险不是材料缺一两份，而是同一个问题不同角色回答不一致、证据指向不清、现场找不到版本与记录，导致能力等级判断被拉低。

在做ASPICE时，工件如果只停留在一份文档名字，评估时很容易被追问两件事：这份东西对应哪个过程输出，里面哪些字段算必须证据。工件定义做得清楚，模板就能做得省心，因为你不需要靠人记住要写什么，只要按字段填就能把证据链补齐。