第三章：需求来源——客户、法规、内部与市场
做ECU需求分析，第一步不是写文档，而是搞清楚一个问题：这些需求到底从哪来的？
我刚开始带项目那会儿，总觉得需求就是客户给的一纸合同。后来吃过几次亏才明白——需求来源是个多面体。你漏掉任何一个面，后面都可能翻车。
今天咱们就把这四大来源掰开揉碎了讲。嗯，都是实战中摸爬滚打出来的经验。
3.1 客户需求——最直接的“甲方爸爸”
客户需求，说白了就是主机厂（OEM）给我们的技术规范。这是最基础、最不能打折扣的需求来源。
客户需求通常包含这几类：
- 功能需求：比如“车速超过120km/h时，自动点亮双闪”
- 性能需求：比如“从接收到CAN报文到执行器动作，延迟不超过10ms”
- 接口需求：比如“使用CAN FD通信，波特率500kbps”
- 诊断需求：比如“支持UDS协议，0x19服务读取DTC”
我的经验：客户给的SOR（需求规范）往往有模糊地带。比如“响应要快”——多快算快？我一般会主动找客户确认具体数值，写成可测试的指标。不然验收时扯皮，吃亏的是我们。
3.2 法规需求——ISO 26262是绕不开的坎
法规需求，这是硬约束。不满足就不能上市，没得商量。
汽车电子领域，最核心的法规标准就是ISO 26262（功能安全）。还有ISO 21434（网络安全）、GB/T 34590（中国版功能安全）等。
法规需求怎么落到ECU上？我举个例子：
| ISO 26262 条款 | 对应的ECU需求 |
|---|---|
| ASIL等级要求 | MCU需支持锁步核，内存需ECC保护 |
| 故障检测时间（FTTI） | 电压监控必须在10ms内检测到欠压 |
| 安全机制 | 每100ms执行一次CPU自检（LBIST） |
| 故障响应 | 检测到严重故障后，500ms内进入安全状态 |
避坑指南：我曾经遇到一个项目，客户没提功能安全等级，我们也没追问。结果样件测试时发现需要ASIL B，整个MCU都得换。那叫一个惨。所以——法规需求一定要在项目启动时就确认清楚。
3.3 内部需求——自己给自己提要求
内部需求，就是公司内部各部门提出的需求。这部分容易被忽视，但往往决定了产品的可维护性和可制造性。
内部需求主要来自：
- 硬件团队：比如“MCU引脚必须兼容两种封装”
- 软件团队：比如“Bootloader必须支持OTA升级”
- 测试团队：比如“所有DTC必须支持快照数据记录”
- 生产部门：比如“产线刷写时间不能超过30秒”
- 售后部门：比如“诊断仪必须能读取历史故障发生时的环境数据”
我个人习惯是，在需求分析阶段专门开一个“内部需求评审会”。把硬件、软件、测试、生产的人都叫来，挨个问：“你们有什么要求？”
你想想看，如果生产部门说“刷写时间太长”，你到量产阶段才改，那代价就大了。
3.4 市场反馈——来自用户的真实声音
市场反馈，说白了就是“用户骂什么，我们就改什么”。
这部分需求通常来自：
- 售后故障数据：比如“某车型的ECU在低温环境下频繁报通信故障”
- 用户投诉：比如“空调控制响应太慢”
- 竞品分析：比如“竞品已经支持远程诊断，我们还没有”
- 召回事件：比如“某批次ECU存在软件bug，需要修复”
我记得有一次，某款ECU在北方冬天频繁出现“启动困难”的投诉。我们分析后发现，是低温下电池电压偏低，而ECU的欠压保护阈值设得太高了。后来我们调整了阈值，并增加了低温启动的辅助策略。这就是典型的市场反馈驱动需求变更。
核心观点：四大需求来源不是孤立的。客户需求是“要什么”，法规需求是“必须满足什么”，内部需求是“怎么做好”，市场反馈是“哪里需要改”。
一个成熟的ECU需求分析，必须把这四个维度都覆盖到。漏掉任何一个，都可能让项目翻车。
一个成熟的ECU需求分析，必须把这四个维度都覆盖到。漏掉任何一个，都可能让项目翻车。
3.5 实战建议——如何管理这些需求
说了这么多，最后给点实操建议：
- 建立需求追溯矩阵：每条需求都要能追溯到来源。客户说的、法规要求的、内部提的、市场反馈的，分门别类。
- 优先级排序：法规需求 > 客户需求 > 市场反馈 > 内部需求。别搞反了。
- 需求变更要有流程：市场反馈来了，不是直接改代码。先评估影响，再走变更流程。
- 定期复盘：每个项目结束后，看看哪些需求来源被遗漏了。下次改进。
好了，第三章就到这里。下一章咱们聊聊需求分析的具体方法——怎么把模糊的客户需求，变成工程师能看懂的技术规格。
公众号:蓝海资料掘金营，微信deep3321