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

　　一、ASPICE SYS.2系统需求分析怎么开展

　　SYS.2通常承接SYS.1所形成的利益相关方需求，并向后为系统架构、硬件需求和软件需求提供输入。在项目刚开始的时候，不应当急着逐条去补需求编号，而是需要先把产品边界、系统自身的职责以及与外部交互的关系梳理清楚，否则后面很容易出现需求重复、范围逐渐偏移，或者把原本应该由外部系统完成的功能写进当前系统的情况。

　　1、明确需求输入和系统边界

　　从【利益相关方需求】和【系统上下文】当中，识别出当前系统需要承担的功能、外部接口、运行环境以及限制条件。

　　分析时，需要将客户真正提出的目标、项目内部推导出的技术要求，以及暂时还没有结论的问题，这三者区分开来。客户提出的“启动要快”，还不能直接作为系统需求来使用，需要继续明确从哪一个事件开始计时、在什么样的温度和电压条件下测量、允许的最长时间是多少，以及达到怎样的状态才算是启动完成。

　　2、形成结构化系统需求

　　系统需求可以按照功能域、运行模式、接口类型、产品变型或者发布范围来进行分类，同时需要维护优先级、来源、状态、责任人以及目标版本等属性。进行分类的目的，不能仅仅为了让目录看起来整齐，而是要方便后续向架构进行分配、进行变更影响分析以及保证测试的覆盖程度。如果同一条需求同时描述了正常功能、故障处理和性能限制，通常应该将其拆分开来，否则到了后面很难分别进行验证。

　　3、分析技术可行性和依赖关系

　　通过【系统需求评审记录】保存需求可行性、存在冲突的条目、有待确认的问题以及最终的处理结论。

　　评审的时候，不能只检查语句是否通顺，还要看现有平台、算力、存储空间、通信带宽、传感器精度以及成本方面的约束能不能支撑这些需求。有些需求单独看起来都很合理，组合在一起却会相互冲突，例如缩短启动时间可能会增加峰值功耗，而提高诊断覆盖度又可能延长初始化过程，这些相互依赖的关系应当在系统需求阶段就暴露出来，而不是留到集成测试的时候再去处理。

　　二、ASPICE SYS.2需求质量怎么检查

　　需求质量的检查，既包括单条需求写得是否规范，也包括整套需求是否完整、一致以及是否具有可追溯性。只做语法层面的检查是不够的，一份措辞规范的需求规格说明，仍然有可能遗漏关键状态、异常路径和外部接口。

　　1、检查单条需求是否可验证

　　一条系统需求，应当明确主体、触发条件、系统行为、约束范围以及可以判定结果的标准，要尽量避免使用“尽可能快”“适当处理”“支持高性能”这一类模糊的表述。检查的时候可以直接提出这样一个问题：测试人员在看到这条需求之后，能不能设计出一个判定通过或者失败的明确方法。如果还需要再回头去询问需求作者这条需求究竟是什么意思，就说明它还没有达到可验证的状态。

　　2、检查完整性和上下游一致性

　　通过【双向追溯矩阵】，检查利益相关方需求是否已经被系统需求所覆盖，同时也要确认每一条系统需求是否存在合理的来源。

　　建立了追溯链接，并不等于内容就已经一致。在追溯关系建立之后，还需要比较上下游的内容是否真正对应得上，不能出现客户要求在2秒内完成响应，而系统需求却变成了3秒的情况；也不能在把一条客户需求拆分成多条系统需求之后，反而遗漏了其中的某一个使用场景。双向追溯除了用来证明覆盖关系，也要用于在需求发生变更的时候，快速找到受到影响的对象。

　　3、检查非功能需求和系统上下文

　　项目当中，注意力很容易集中在功能流程上面，而性能、资源、可靠性、诊断、网络安全、功能安全和环境适应性这些方面的需求，则常常写得比较零散。检查的时候，还要看系统需求对外部ECU、传感器、执行器、供电、通信网络以及用户操作有没有产生影响，例如新增的周期报文会不会增加总线负载，故障后的降级处理会不会改变其他系统的工作条件，这些都属于SYS.2需要去分析的系统上下文影响。

　　三、ASPICE SYS.2常见问题怎么整改

　　SYS.2的整改，不能等到评估之前才临时去补充文档。需求一旦进入架构、软件和硬件开发以及测试这些阶段，上游出现的小问题就会在多个下游对象当中被放大。比较实际的做法，是把需求质量检查纳入到日常评审和变更流程当中，发现问题之后及时回到源头进行修正。

　　1、按问题类型分别处理

　　需求中的问题，可以将其划分为缺失、歧义、不可验证、内容冲突、技术不可行、属性不完整和追溯错误等不同类别。不同类别的问题，处理的方式并不一样，缺失的需求需要补充相应的场景，存在歧义的需求需要找到相关方进行确认，技术不可行的需求则可能需要调整目标或者改动架构方案。如果将所有问题都简单地标记为“文档修改”，到了后面就很难判断真正的风险究竟在哪里。

　　2、变更后重新完成影响分析

　　按照【变更请求】→【影响分析】→【需求更新】这样的顺序，处理已经确认过的需求变化。

　　影响分析需要覆盖系统上下文、系统架构、硬件、软件、验证活动、项目计划以及供应商接口。不能只修改当前需求的文字，然后等待下游人员自己去发现变化。如果某项利益相关方需求没有同步修改，但双方已经就系统需求的调整达成了一致意见，也应当保留下明确的协商证据，避免在评估时出现上下游内容不一致却又无法解释的情况。

　　3、准备能够相互印证的过程证据

　　评估的时候，通常需要结合【系统需求规格】【需求属性】【分析结果】【一致性证据】以及【沟通记录】，来判断SYS.2是否得到了真正的执行。

　　这些材料不一定非要拆成多个独立的文档，也可以保存在需求管理工具、评审系统和变更平台当中，关键在于内容能够相互对应。如果需求状态显示已经批准，却找不到对应的评审结论；追溯链接已经建立，但变更之后没有进行更新；问题记录已经关闭，却没有处理依据，这些情况都会削弱证据的可信程度。

　　总结

　　ASPICE SYS.2系统需求分析怎么开展，以及ASPICE SYS.2需求质量怎么检查，其核心是从利益相关方需求出发，形成结构化、可验证、技术可行的系统需求，并同步分析需求之间的依赖关系和系统上下文影响。质量检查不能只看文字格式，还需要检查完整性、一致性、双向追溯以及变更之后的影响范围。把需求评审、问题整改和证据留存放在同一套流程当中，SYS.2才不会变成评估之前临时整理出来的一份文档。