一、汽车软件需求分析概述

1.1 汽车软件发展历程

说起汽车软件，很多人第一反应是“不就是个嵌入式系统吗？”

嗯，十几年前确实是这样。但现在的汽车，你想想看，一辆高端电动车跑的代码量已经超过1亿行。比Facebook的服务器端代码还多。

我入行那会儿，2008年左右，汽车上的软件还很简单：

• 发动机控制单元（ECU）——几千行C代码
• 车窗、门锁控制——几百行汇编
• 仪表盘显示——纯硬件驱动

那时候的软件，说白了就是硬件的“附属品”。改个功能？重新烧录芯片，周期三个月。

转折点出现在2012年左右。我记得很清楚，当时我在做一个T-Box项目，客户突然要求支持OTA升级。项目经理当场就懵了——我们连版本管理都没有，怎么远程升级？

从那以后，汽车软件开始“野蛮生长”：

• 2013-2015年：智能座舱概念兴起，Linux/Android进入车载系统
• 2016-2018年：ADAS功能爆发，传感器融合算法成为核心
• 2019-2021年：域控制器架构普及，SOA（面向服务架构）成为主流
• 2022年至今：中央计算平台+区域控制器，软件定义汽车成为现实

1.2 需求分析的重要性

为什么需求分析这么重要？

我直接说一个真实案例吧。

2017年，我参与过一个自动泊车项目。客户的需求文档里写了一句：“车辆应能在标准车位内自动泊入”。

就这一句话，开发团队花了6个月。结果呢？

• 测试时发现：车位线模糊时，系统直接罢工
• 用户反馈：泊车速度太慢，后面车按喇叭催
• 法规问题：某些国家要求泊车时驾驶员必须双手在方向盘上

问题出在哪？需求太模糊了。

“标准车位”是什么标准？2.5米宽还是3米宽？

“自动泊入”是全程无人干预，还是需要驾驶员确认？

这些都没说清楚。

后来我们花了3个月重新做需求分析，把一句话拆成了200多条具体需求：

• 车位检测：支持平行、垂直、斜向三种车位
• 最小车位尺寸：车身长度+1.2米
• 泊车时间：不超过30秒
• 安全策略：遇到障碍物立即停止
• 用户交互：通过中控屏显示泊车轨迹

你看，这才是需求分析该有的样子。

需求分析的重要性，我总结为三点：

1. 减少返工——需求越清晰，开发越少走弯路。行业数据显示，需求阶段发现的问题，修复成本是开发阶段的1/10，是测试阶段的1/100。
2. 明确边界——系统该做什么、不该做什么，必须白纸黑字写清楚。否则开发人员和测试人员会互相甩锅。
3. 规避风险——汽车是安全关键系统。一个需求遗漏，可能导致功能安全失效，甚至危及生命。

1.3 需求分析在V模型中的位置

说到V模型，做汽车软件的应该都不陌生。但很多人只是知道“左边是需求，右边是测试”，具体怎么对应，其实没搞明白。

我习惯把V模型分成三个阶段：

阶段	左侧（需求分析）	右侧（验证确认）
系统级	系统需求分析	系统集成测试
子系统级	子系统需求分析	子系统测试
组件级	软件需求分析	单元测试

需求分析在V模型中的位置，说白了就是“最左边的那一竖排”。

具体来说：

• 系统需求分析：从客户需求出发，定义整车级功能。比如“车辆应支持L2级自动驾驶”。
• 子系统需求分析：把系统需求分解到各个子系统。比如“感知子系统应能识别前方200米内的车辆”。
• 软件需求分析：把子系统需求细化到软件组件。比如“目标检测模块的召回率应≥95%”。

这里有个关键点：V模型不是简单的“先做需求，再做设计，最后测试”。

实际上，需求分析和测试设计是同步进行的。我建议的做法是：

1. 写需求的同时，写对应的测试用例（至少写关键场景）
2. 需求评审时，测试人员必须参加
3. 需求变更时，同步更新测试用例

为什么？因为需求分析的质量，直接决定了测试的有效性。你想想看，如果需求本身是错的，测试再怎么测也发现不了问题。

最后说一个我自己的体会：

很多工程师觉得需求分析是“文档工作”，不如写代码有成就感。但我想说，真正的高手，都是在需求阶段就把问题解决掉的。代码写得再好，需求错了也是白搭。

所以，别小看需求分析。它决定了你接下来几个月是“愉快地开发”还是“痛苦地返工”。