【原】汽车行业业务需求分析的解决方案

Donald当劳 2021-11-20

展开全文

1、汽车行业的复杂性

汽车行业的软件开发有别于传统互联网行业的软件开发，其更倾向于一个系统工程。因为你除了要关心软件系统以外，同时也要兼顾不同零部件之间的协作，以及ECU的算力问题。所以，并不能简单地通过传统的瀑布、敏捷等开发方法直接套用在汽车行业当中。

基于汽车行业的复杂度，行业的软件成熟度通过ASPICE进行评估。ASPICE通过V模型来体现其设计的生命周期，并将相关的生命周期区分成SYS系统V模型，SWC软件V模型两个主要层面来了解汽车。同时硬件开发、线束、布线等都有其相应的V模型进行表现。

ASPICE对整车开发定义了多套V模型，包括系统分析V模型、软件开发V模型、硬件开发等多种V模型。

汽车电子电器架构设计从传统的分布式结构逐步发展，向领域驱动和中心化的方向推进，其目的就是简化电子电器的线束的复杂度，并且能够通过统一的方式使用和调度不同Zone区域节点的功能。

OMG组织发布的系统建模语言SysML是一种通用图形建模语言，通过需求、分析、设计、验证等角度来定义复杂系统，实现对包括硬件、软件、信息、人员、程序和设施等的定义。该语言提供了大量UML扩展的图形，针对系统建模当中的系统需求，行为，结构和参数的语义等信息，并可以用于与其他工程分析模型集成进行。

SysML针对相关的行业定义了一些特有的图形进行描述，专业的汽车设计软件PREEvision，是一个可以支持整车电子电器开发设计以及仿真的软件，PREEvision为汽车EEA电子电器开发的各个阶段提供了不同的图形的支持。

但是，即使是有一定的技术基础，很多时候遇到具体业务场景实施时，依然会有各种各样的问题。一方面各种方法论无法通用地解决所有问题；另外一方面，汽车行业从业人员需要的技能比较多，要能够透彻看清楚各个环节，需要大量跨领域的知识。大多从业人员自身的技能依然维持在传统的模式上，行业局限性比较大，软件及架构等技能也相对有限。

2、使用UML驱动汽车行业需求分析的意义

UML是一种通用的建模语言，其作用贯穿整个软件系统的生命周期。SysML是UML的一个子集，它继承和扩展了UML基础的各种能力和模型。

UML是一种用于对软件密集型系统进行可视化、详述、构造和文档化的建模语言，主要适用于分析与设计阶段的系统建模。UML最主要的特点是表达能力丰富。UML从各种OOA&D方法中吸取了大量的概念，对这些概念的语义、图形表示法和使用规则作了完整而详细的定义。可以说，UML对系统模型的表达能力超出了以往任何一种OOA&D方法。当然，它的复杂性也超出了以往任何一种方法。

UML的问世引起了计算机软件界的广泛重视，因为它代表了一种积极的方向——多种方法相互借鉴、相互融合、趋于一致、走向标准化。建模语言的标准化为软件开发商及其用户带来了诸多便利。

UML1.x是为软件行业制定的一种交互语言，用来给软件的各个阶段提供交流手段。UML2.x基于UML1.x的成功结果，尝试对世间万物进行建模，在解决了一些UML1.x问题的基础上增加了许多图例来支持更多行业的建模要求。

3、为何选择UML语言作为需求的整理语言

UML语言是一种面向对象的建模语言，适合用来辅助了解复杂的系统和结构，具有比较高的思维同质性。我们可以想象一下，如果我们要为一盘围棋进行建模，将所有的围棋棋子都看成对象，这样理解其行为容易还是从过程的角度来思考所有围棋容易。从面相对象角度，我们只需要关心每个棋子每一瞬间的位置和行为即可。

UML语言适用于系统所有阶段的建模，它提供了多种方式来体现信息内容。这些表现非常容易被系统和软件周期的各个阶段的成员进行理解，方便了各个阶段成员之间的交流。

UML语言提供了大量的表现方式，使用者可以从多种维度描述系统和架构的相关信息。无论是系统、架构、软件、硬件、嵌入式、功能、非功能等都可以使用不同的UML语言图例进行精确描述将实施过程碰到的信息和内容进行沉淀。而且，汽车行业的业务行为复杂，需要一种能够兼容各种要求的模式进行表现。

当前汽车行业蓬勃发展，软件定义汽车的概念越来越普及。固有的思路和传统的方法已经无法支持新概念的引入，同时也存在固有理念影响了新概念引入整车的情况（例如元宇宙、SOA服务驱动等），从正向角度思考汽车系统和汽车软件的开发流程越来越得到重视。这也是汽车行业发展的未来方向。未来的汽车就是一个带有四个轮子的手机。如何能够将所有新思想、新概念引入汽车行业，如何落地，都期待新的火花的出现。

需求分析和业务分析是一个过程，是一个整理思路的过程，使用工具是辅助我们梳理思路。是一个比较复杂的整理和匹配要求的方式，沉淀后得到一个统一的结果。使用 PREEvision 编写的内容可以理解为是一个结果，产生这个结果的过程需要更多的专业的好行业的知识的注入。

4、进行汽车行业的需求整理需要用到的一些图例

用例图

原则上来说，用例图并不是一种面向对象的图形，UML引入用例图的目的是为了能够在UML进行面向对象建模时，提供一个基础和入口，以及划定分析设计的边界。

Use Case 用例图主要包含Actor 和 use case两样东西，use case 是一组连续行为的集合，例如“打开门”等。事件可大可小，原则上并没有严格约束。Actor用来描述对该事件的驱动者或者该事件关联的外部各方。我们也可以通过Region域的划定来将用例放置于指定的限定的范围内。Actor和Use Case之间的连线代表交互关系。

活动图

活动图用来描述行为的过程，可以表示行为执行的步骤和过程中的并发、条件、选择、合并等行为的体现。

顺序图

顺序图用来描述强时间要求的顺序行为。精确体现对象之间的驱动和执行关系。UML2.0为了增强sequence顺序图的功能，加入了fragment的概念，让顺序图可以表现一些可重用的顺序块和逻辑信息，例如条件分支等。

状态机

State Machine 状态机图体现的是事物状态以及状态之间变化的关系，以及变化的驱动源等信息。状态机能够很好地体现事物的一些静态特性。

类图

在UML语言当中，所有需要沉淀的内容都需要通过类图（或类相关图）进行沉淀的。在需求整理过程中，并不一定要类图参与，但是类图的参与能够更好地将需求内容延续到后期的架构和软件过程当中。

5、如何开启汽车行业的需求分析过程

什么是需求

所谓需求，是指因为欲求引发的某种动机，这个动机就是需求。我们一般的理解是利益相关者stakeholder对系统的一种要求。需求有业务需求、用户需求和功能需求等。

如何描述用户的需求呢？对于软件行业我们一般会从业务的角度去描述用户的需求，更直观地，我们会通过冰山模型来表现

用户要实现的功能就是整座冰山，冰山浮出水面的部分就是用户的需求，用户需求就是冰山对于用户的可见部分。所谓可见部分，包括视觉、听觉、触觉、味觉在内的各种感知。例如主机厂要求的用户需求，可以是中控屏的操作，可以是雷达的声响，也可以是语音与SIRI 的对话过程。我们触碰雨刮开关，导致雨刮摆动，这也是主机厂能够感觉到的用户需求。通过对冰山水面可见部分的分析和理解，搭建出整个能够支持冰山的不可见部分的内容。

汽车行业需求分析过程，可以区分为业务建模、系统建模以及软件建模过程三个阶段，

业务建模

业务建模是将业务相关过程进行完整梳理，将软件功能和非软件功能进行确认和分离，从而将需求工作的重点集中在需求的软件部分。

例如我们在研究一个自动洗车过程，自动洗车应该包含：

1.将车(自动)从停车场开到洗车房

2.点击系统开启自动洗车模式（自动洗车模式关闭窗户、停止雨刮、关闭空调、锁住后车门、关闭车身保护雷达等）

3.将汽车档位挂在N空挡位置

4.洗车房机器开始洗车过程

5.洗完车关闭自动洗车模式（恢复天窗、雨刮等的状态）

6.将车（自动）从洗车房开回停车场

业务建模及业务分析过程是必须有的，但是在整理整车业务需求时可以简化相关过程。通过业务建模后，我们判断1和6，汽车从停车场自动开到洗车房并回来的过程现在依然不成熟，所以无法支持，于是将这个过程分析为人为处理实现。对于4，无需人为干预。对于3，需要人为将物理档位切换，当前车身并不具备这个功能，但是我们可以编写一个用户指引guideline来引导用户完成洗车过程。于是，对于2和5将被分析成系统需求，交由自动洗车功能模块来完成。

系统建模

系统建模的目的是将车身功能进行分析和细化，依据用户可感知的部分的信息，搭建起整个系统的架构。就是参考冰山可见部分构建出整个冰山的内容。描述冰山可见部分可以理解为系统需求过程，构造出支撑可见部分的整个冰山可以理解为系统架构、系统设计的过程。系统建模过程也需要考虑非功能性需求，例如安全、性能、法律法规等非功能性需求也会影响系统整个建模过程。

软件建模

系统建模过程结束后，将设计结果转换成软件架构实现的接口要求，一般是子系统的接口需求或者SOA服务的服务接口需求。软件接口需求会定义软件接口的名称、参数信息和参数值、返回信息和返回值。参数信息和参数值之间存在一定的依赖关系，这些依赖关系也需要也需要通过一定的方式描述其内部功能实现的流程关系。这些接口的定义信息就是软件子系统的需求。

同时，软件建模过程也会从系统建模过程细化出来各种非功能性需求，这些非功能性需求也会影响软件建模和实现过程。

6、整车业务需求分析过程

这里主要讲解的是系统需求分析的全过程，业务场景分析虽然包含在内，但是会一带而过。软件分析过程可以参考传统的软件分析过程实施完成。

具体分析过程可以参考以下流程（并不是完整流程，可以根据具体企业的要求和场景进行调整）。总体流程氛围业务场景分析和梳理、系统需求分析和梳理、系统需求细化、系统需求评审的过程。

业务场景分析的目的如下：

1.梳理出可以通过软件实现的系统功能；

2.将功能硬件理解成软件包（所有硬件功能的实现都由软件进行代理完成）；

3.将硬件部分都理解成non-human 的actor，包括声音，雷达等等可感知部分

4.梳理出涉及的human的actor，例如驾驶员、乘客等。

系统需求分析的目的如下：

1.识别所有系统用例，系统用例为一系列时间相关的行为总和。并将系统用例通过简单的名称进行描述；

2.将系统用例与actor以及non-human的actor进行关联，清晰体现出所有系统用例的边界；

3.将non-functional的非功能性需求进行描述以及体现；

4.将UI相关（界面、语音、雷达等交互）与非UI行为进行分离，单独描述；

5.将所有涉及或影响到这个业务场景的事件也作为系统用例进行表现。但是要注意其Actor的识别，例如司机踩油门导致车速加快会启动车门安全锁，那么启动这个驱动者的Actor将是车身，而不是驾驶员；

系统需求细化的目的如下：

1.将UI相关的用例，借助活动图描述出页面流转的关系，主要体现出页面，以及页面切换的逻辑依赖关系。非页面行为可以弱化成单个活动行为；

2.将非UI的用例细化成以功能实现为主线的活动图，UI相关部分需要体现成UI类型活动图；

3.对于外部事件相关的活动也需要转换成活动图；

4.细化过程的语言描述不可以存在歧义，存在歧义的文字描述需要在术语定义当中进行定义；

5.对于一些部件或状态类型的信息可以通过状态机进行体现；

6.对于一些时间强相关的事件可以通过序列图进行体现；

7.对于需要有信息沉淀或术语定义类型的信息，可以通过类图进行体现。例如恢复 “原来状态” 就代表需要存在一个需要沉淀下来的信息。

需求评审的目的如下：

1.评审是一个周期性的行为，可以理解成检查，主要目的是进行各个阶段的把关工作。

2.需求评审和总需求交付评审不是一个概念，总交付评审是一个盖章过程，需求各个阶段的评审是对阶段工作的检查。

3.评审通过提前的同行交流、跨部门交流、架构师检查等方式来发现需求阶段存在的问题。

4.由于需求人员的背景和知识能力的差异，可以通过评审来减少错误，同时达到提高专业能力和实现共识的目的。

7、整车业务系统需求分析的一些要点

在需求分析的时候需要注意以下几点：

1.非功能性需求需要依赖不同的要求进行描述和表示，可能是图形也可能是文字表格，目的是能够体现需求的特点和相关性。此次并不会对非功能性需求描述过多，更多的需求表述可以另设话题讨论。

2.不管是需求分析，还是架构设计，都是一个递进的过程，图形随着分析的递进，逐步细化和深入。当前展示的内容主要是展示分析结果，相关分析过程信息将会通过文字表示。

3.使用UML进行需求分析，目的都是为了能够简化和清晰需求描述，做到简化和解耦的目的，部分难以表述的内容会建议采用文字表述的方式进行表达。

4.图形的多少并不是越多越好，判断标准就是是否能够清晰表达需求的信息。当然，另外一个判断标准就是：任何人拿着需求文档都能够通过UML和文字清晰了解需求内容即可。所以并没有严格的标准。

5.需求的编写是以UML管理的目录结构为基础，Word文档和Excel的表述只是它的一种展示方式。

6.当前需求的编写是通过UML Designer软件进行编写，通过工具，能够更好地管理和定位软件模型，这个工具本身并不能完美支持UML2.x的所有内容，为了避免切换工具的时候带来的移植问题，编写图形时都使用标准的图形即可。

8、整车业务系统需求分析实例

总述

该文档的编写是以一个《自动洗车功能》作为基础，自动洗车功能概述如下：自动洗车功能是为了使用户能够快速自动洗车，在进入自动洗车机前，通过快捷按键一次性完成关窗、停止雨刮、关闭雷达、禁止开启后车门等操作，并且在洗车完成后通过快捷按键恢复各个相关零部件洗车前状态。自动洗车模式包括进入自动洗车模式、退出自动洗车模式、自动洗车模式保持期间对相关零部件的操作的三大部分。各个功能需求通过需求整理和车型对标获得。

下图是自动洗车模式层次架构的样貌。整个需求分析过程是一个递进过程，分析过程会产生许多图形和结构以及关系，可以使用package包分类管理起来。

模型是UML定义的元对象，图形 diagram是模型在不同侧面的一个体现，根据需要将特定的UML模型进行展示和体现，根据需求在图形上进行取舍。图形展示并不会影响模型之间的关系，图形可以看成只是一个辅助工具而已。

用例

首先第一步是进行用例的确定，确定的基本方向为：1.UI与非UI进行分离。2.将正常业务与异常业务场景进行分离。3.异常业务场景单独体现。4.由于触及的外部零部件都是可见部分，所以将外部零部件都作为单独的non-human actor来体现。

下图A中，UI进入自动洗车模式表示通过中控屏启动功能的过程，虚拟按键点击和语音交互都是一种UI的启动方式而已。因为这里是UI用例，UI用例是借助UML来体现UI交互过程，它并不是一个真实的用例的概念，所以我们只需要关心驱动者是驾驶员即可，无需考虑零部件的相关行为。

下图B中，对中控屏主动控制，发出信号的是驾驶员，每个用例我们可以理解成一块软件团完成的功能。窗户雨刮等为non-human的actor，这些作为外部部件。未来经过架构阶段的推导，外部部件都会很自然地变成一个一个的子系统或服务，但这是后话。这个阶段，我们只需要将冰山上可见部分，就是用户可感知部分，都作为外部的actor考虑即可。对于关闭自动洗车模式的行为，在用户无意中改变了档位以后，一样会触发关闭自动洗车模式的行为，所以我们将这个行为作为扩展考虑。其原因是我们几乎不用增加任何的描述就可以体现更改档位导致的变化，也可以理解为我们在进行用例细化的时候只需要细化其中一个用例即可。

下图C中，表现的是自动洗车模式场景ongoing的状态时，某些对空调、窗户等硬件操作后会影响自动洗车模式的情况。简单来说，就是洗车模式关闭的时候会将相关零部件恢复到进入洗车模式前的状态，但是如果零部件被触碰，例如天窗被调整以后，退出时将忽略天窗的恢复。由于该事件的完整行为过程为外部器件驱动并记录外部事件的信息，因此用例定义简单。

A.UI相关用例	B.功能用例	C.外部事件用例

用例活动

有的用例内容可以通过其他用例的信息体现，所以无需进行用例活动描述，能够体现用例信息的用例需要将用例实现过程，即所有涉及可见/可感知的行为，都通过活动图体现出来。文字表达不能模糊，必须清晰体现具体行为，对于某些词汇定义，可以在词汇表进行解释。

对于UI相关的用例，主要是体现UI交互/语音交互的交互过程，甚至包括硬件操作过程，弱化非UI部分的内容。如果图形不能表达清楚，可以通过文字进行补充。

描述UI活动过程中，需要把事件和行为进行分离。流程描述的是事件，例如按下按钮是确认行为，而不是点击按钮或语音（小度，小度，我选一）确认。可以通过文字描述体现这个按钮确认行为，包含通过鼠标点击和语音确认两种方式。

对于UI的action采用自定义的方式表示，红底表示UI相关，白底的活动为非UI/软件行为层面的行为。

对于非UI的业务流程，必要的地方依然会描述出UI活动，更多的内容需要分析软件判断逻辑，这些逻辑和行为基本是与actor相关的。非UI流程里，所有涉及到的外部Actor（human actor或non-human actor）交互的过程都应该在活动图里进行体现。有时候，UI活动的结束就是非UI的开始。

对于外界事件的影响，根据实际情况将用例的活动描述转换成活动图进行表现。

类图

根据实际情况，将类图进行抽取和表现。

类图的来源包括：

1.术语定义

2.状态机抽象

3.关键实体对象

4.存储管理信息

5.模糊术语定义

在UML语言当中，所有需要沉淀保存和管理的信息都是通过类来实现的，类图可以体现出实体的信息。进行类图抽象，可以辅助后续架构设计进行类的抽取。因此，根据实际情况抽取类图。

当前类图并没有很好地体现实体的内容，并不是一个合理的类图信息的展示，但是却能够体现需求整理者对各种信息的理解。基于这些信息，架构设计人员可以根据类图进行参考和对实体对象信息的收集。

状态机图

状态机可以清晰体现出对象的状态的类型、状态之间切换的条件以及方向等信息。

下图为后视镜的状态信息，包含折叠和展开。这个状态机也体现了状态之间进行切换的时候的行为以及转换方向等信息。

下图展示了一个二维的状态变化管理，通过状态机表现两个状态类型转换之间的关系信息等。

其他模型

由于当前进行需求分析的方式是采用工具UML，更多的是通过图形方式展示结构和关系类型。但是图形不是万能的，有时候一两句话就能够简化和体现相关信息，所以文字描述也可以适当使用。同时，任何的理解和共识信息都可以通过文字进行描述，方便相关人员的同步和理解。

基于UML模型的管理结构，存在presentation角度的图形管理展示，可以借助工具进行展示。虽然工件artifact和关系是UML语言的基础，图形只是不同角度、不同侧面的展示方式而已，但是人们接受信息的方式是通过图形去体现的，所以图形展示是一个重要的管理环境。

通过表格针对需要展示某些信息的列表以及描述信息的内容进行体现。

http://mp.weixin.qq.com/s?__biz=Mzg5NzUyMjU1OA==&mid=2247483825&idx=1&sn=3e426e6fd5ea9c24f6b1ee768d60d854&chksm=c071cfa0f70646b6b86410df46e45e3d5817307930ab7f81c898eae7556ea589011c84a1fc69#rd