SYS.2 - System Requirements Analysis : The purpose of the System Requirements Analysis Process is to transform the defined stakeholder requirements into a set of system requirements that will guide the design of the system. （系统需求分析：系统需求分析过程的目的是将已定义的利益相关者需求转换为一组系统需求，这些需求将指导系统设计。）
从这个例子可以看出，ASPICE中每个过程域各司其职，而要了解一个过程域是干什么的，首先要了解它在整个ASPICE过程域中框架中的位置。APSICE3.1的章节3.1. Process reference model（流程参考模型）的这个概要图被各种ASPICE的介绍文章广泛引用，从这个图中可以看到各个过程域在整个框架中的位置。
（[ASPICE3.1]Figure 2 — Automotive SPICE process reference model - Overview）
如上图所示，PDCA循环的含义是将质量管理分为四个阶段，即计划（Plan）、执行（Do）、检查（Check）、处理（Act），而这4个阶段也正可以对应SWE.6的7个BP，如下表所示。1)Plan (计划)不同于CMMI在软件领域的单一，ASPICE所对应的汽车行业有多个competency（部门），如下图所示以“Plug-In（即插即用）”的形式结合在一起。由于每个部门的组织形式、开发流程各不一样，因而在统一的项目计划之下，每个部门也需要各自的计划，如系统部门需要系统工程管理计划（SEMP – System Engineering Management Plan），覆盖SYS.1到SYS.5的内容；软件部门则需要软件开发计划（SDP – Software Development Plan），SWE.6.BP1中的测试策略就包含在这个SDP之中。（[ASPICE3.1] Figure D.1 — The "Plug-in" concept）SWE.6.BP1中，明确要求“开发软件合格性测试策略，包括回归测试策略”作为后续BP的依据。在ASPICE过程域中，并非所有过程域都需要定义策略，如SYS.2系统需求分析、SWE.1软件需求分析就没有特定策略，这并不是说它就没有计划，而是计划阶段的内容已经覆盖在MAN.3项目管理之中了。SYS.2的计划覆盖在SEMP中，而SWE.1的计划覆盖在SDP之中，而这些计划，ASPICE在2-5级的GP（通用实践）中有更加明确的要求。关于策略（strategy）和计划（plan）的关系，ASPICE3.1用下图进行说明。（[ASPICE3.1] Figure D.7— Strategy and plan）2)Do（执行）计划有了，没毛病干就完了，那么具体都干些什么呢？三件事——写用例、选用例、做测试——在SWE.6.BP2到SWE.6.BP4给出了答案。类似的，根据V模型环环相扣，下面是部分过程域执行步骤的简要内容——在ASPICE中，各个过程域的工作产品粒度有不同的单位，也有特定的术语。如下图所示，同样是CAN（Controller Area Network）模块开发，在系统架构层级就是Element（元素）、在软件架构层级就称为Component（组件）、到了代码就叫Unit（单元），软件集成以上级别的测试就成了Item（条目）了。了解这个术语的区别便于我们在系统上设置字段的时候有统一规范，如果什么阶段都叫“Component”，就容易引起误解了。（[ASPICE3.1] Figure D.3 — Element, component, unit, and item）3)Check（检查）检查的内容体现在双向追溯和一致性，这在下图中一目了然：[ASPICE3.1] Figure D.4 — Bidirectional traceability and consistency）ASPICE的环环相扣体现在它的追溯性上，以SWE.6为例，需要确保：- 100%软件需求被软件合格性测试覆盖。- 每个软件合格性测试条目（Item）可追溯到相应的软件需求。- 一致性得到保证，比如不能把CAN的测试用例链接到XCP上。- 选中的测试用例100%得到执行并生成测试结果，如果没通过的需要修复，或者确保没有影响并与客户达成一致。- 需求变更的内容要在测试中体现相应修改。4)Act（处理）活干完了、也检查了，最后的处理步骤是什么呢？花开两朵，各表一枝：对V模型左侧的需求设计开发阶段而言，“达成一致并沟通（communicate agreed…）”即可告一段落；而对V模型右侧的测试阶段而言，“总结并沟通（summarize and communicate…）”才算宣告完成——如下图所示。（[ASPICE3.1] Figure D.5 — Agree, summarize and communicate）蓝色——分门别类留证据项目计划需要包含哪些内容？系统需求需要考虑哪些要素？这些问题都可以ASPICE3.1的附录B-工作产品特性（Annex B Work product characteristics）中找到。该部分描述了共计21类工作产品的特性需求，列表如下：以MAN.3项目管理为例，通过附录B可以找到主要工作产品项目计划的主要内容要求。项目计划（Project Plan）编号为08-12，因此需要考虑通用计划（08-00）和项目计划（08-12）的特性。无论是组织模板或是项目计划，都应当覆盖这些内容。首先是通用计划08-00 Plan（计划）的特性，这在考虑组织模板的各类计划如质量计划、配置管理计划、测试计划等等的时候，都应当考虑满足这些特性。中英双语列举如下——其次是项目计划08-12 Plan（项目计划）的特性，各个适用于各个competency（部门）的计划制定，中英双语列举如下——纽带——流程结果（Process outcomes）上述的红绿蓝三个部分由流程结果（Process outcomes）作为纽带关联而成，如下说明以SUP.10 Change Request Management（变更请求管理）中的第一个outcome为例。SUP.10的变更请求管理过程域中，红色部分的第一个流程结果（Process outcomes）为“a change request management strategy is developed（制定变更请求管理策略）”，基于此，绿色部分的BP（基础实践）和蓝色部分Output Work Product（输出工作产品）的相应内容分别为：绿色部分的BP（基础实践）SUP.10.BP1: Develop a change request management strategy.Develop a change request management strategy, including change request activities, a status model for the change requests, analysis criteria, and responsibilities for performing these activities. Interfaces to affected parties are defined and maintained. [OUTCOME 1] （SUP.10.BP1：制定变更请求管理策略。制定变更请求管理策略，包括变更请求活动、变更请求的状态模型、分析标准和执行这些活动的职责。定义并维护与受影响方的接口。[结果1]）蓝色部分Output Work Product（输出工作产品）08-28 Change management plan → [OUTCOME 1] （08-28变更管理计划→[结果1]） 总结一下ASPICE分为32个过程域，每个过程域通过红色、绿色、蓝色分别解答了Why、How、What（为什么做、怎样做、做成什么）的问题，红色、蓝色、绿色的内容通过流程结果（Process Outcome）链接，思路非常清晰。而这三个部分又参考了不同的质量标准，内容相当丰富，可以进一步深度解析。关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯
在测试XTS时会遇到修改产品属性、SElinux权限、等一些内容，修改源码再编译很费时。今天为大家介绍一个便捷的方法，让OpenHarmony通过挂载镜像来修改镜像内容！触觉智能Purple Pi OH鸿蒙开发板演示。搭载了瑞芯微RK3566四核处理器，树莓派卡片电脑设计，支持开源鸿蒙OpenHarmony3.2-5.0系统，适合鸿蒙开发入门学习。挂载镜像首先，将要修改内容的镜像传入虚拟机当中，并创建一个要挂载镜像的文件夹，如下图：之后通过挂载命令将system.img镜像挂载到sys
关注公众号，点击公众号主页右上角“ ··· ”，设置星标，实时关注智能汽车电子与软件最新资讯
