ASPICE里面的SYS&SWE是什么？

基于最近对ASPICE的理解，举一个例子探讨一下ASPICE里面的SYS&SWE。

项目开始：

OEM: 给我开发一个人脸识别进入系统。
TIER1: 好的，请问有什么具体要求？
OEM: 在年末做出来，要人脸识别准确度高，识别速度快就行。
TIER1: 收到。

TIER1内部：

系统工程师埋头分析中-------------------------------------------------------

SYS.1 & SYS.2

分析完毕，接下来该系统架构师出场啦--------------------------------------

SYS.3

其实这个过程是比较漫长的。

关于客户需求：以为OEM没有提出特别明确的需求，是不是TIER1会很开心？其实不是，往往这种情况是因为OEM一开始可能还没有想清楚，所以最致命的就是会导致后面的需求不断的变更，而需求的变更是最讨厌的。比如：OEM突然要求尽量不采用录入的方式进行人脸识别，而是希望使用公安数据库的数据进行人脸识别（脑补一下哈），那么一开始可能是在车机的人脸识别方案，可能都要迁移到后台服务器进行人脸识别，进而需要增加无线通信协议，大数据库等等，会涉及到整个硬件和软件架构的变更。所以，客户需求越详细越好，客户需求越详细，对后续的系统需求和系统架构的约束越多，方案也就越容易确定。

关于系统需求：系统需求是对客户需求的一个拆解，细化，同时是基于系统需求分析工程师的理解将整个系统的功能分析的更加清晰。系统需求应该是清晰的，而不应该模棱两可。比如上面那条系统需求：能进行人脸匹配。其实是不清晰的。系统需求应该更加清楚：比如修改为：能针对18-70周岁的亚洲车主，在车主主动录入人脸的情况下，并且当车主距离摄像头1m范围内，识别出车主身份。系统需求分解后，需要将其来自客户需求的不确定部分，和客户，比如OEM进行充分沟通，尽量避免需求的频繁变更。

关于系统架构：系统架构是基于系统需求的分析，尽量确定出硬件框架层级（比如，硬件接口，主要元器件，布置，电源等）和软件框架层级（基础层，应用层，软件通讯接口）等。并且将系统需求分配到软硬件架构，判定是否当前架构能满足所有的需求。

以上是个人浅见，欢迎交流，其他见后续更新哦。。。

文章转载自公众号：软件赋能汽车