4. 硬件设计流程

系统需求分析，说白了就是搞清楚客户到底要什么。很多工程师觉得这步就是“翻译”客户的话，其实没那么简单。我做了十几年ECU开发，见过太多因为需求没对齐，最后改板改到崩溃的项目。

你想想看，客户说“我要一个稳定的雨刮控制器”。什么叫稳定？是刮100万次不出错，还是下雨天不能突然停？这些细节，全得在需求分析阶段挖出来。

4.1 客户需求解读：别让“我以为”害了你

客户给的需求，通常有两种形式：一种是正式的RFQ（Request for Quotation），里面会有功能列表、性能指标；另一种就是口头沟通或者邮件里的零散信息。我个人习惯，拿到客户需求后先做三件事：

1. 分类整理：把功能相关的归一类，性能相关的归一类，法规相关的单独列出来。
2. 标记模糊点：凡是出现“尽可能”、“最好”、“必要时”这类词，全部标红。
3. 确认边界：比如工作温度范围、供电电压波动、EMC等级，这些必须白纸黑字写清楚。

4.2 系统需求规格书（SRS）编写

SRS是ECU开发的“宪法”。所有后续的设计、测试、验收，都得拿它说话。我见过很多团队SRS写得像流水账，结果开发到一半发现需求矛盾，只能返工。

一份好的SRS，应该包含以下核心内容：

4.3 功能需求与非功能需求

很多新手分不清这两类。我举个例子：

• 功能需求：踩刹车时，刹车灯必须在100ms内点亮。
• 非功能需求：刹车灯控制器在85℃环境下，连续工作1000小时不失效。

功能需求描述的是“系统做什么”，非功能需求描述的是“系统做得怎么样”。两者缺一不可。

在车载ECU开发中，非功能需求往往比功能需求更烧钱。比如：

• 可靠性：ISO 26262功能安全等级（ASIL A/B/C/D）
• 环境适应性：温度、湿度、盐雾、振动
• EMC：辐射发射、抗扰度（ISO 11452系列）
• 诊断：UDS协议支持、故障码管理

4.4 需求追溯矩阵：别让需求“丢了”

需求追溯矩阵（RTM），说白了就是一张表，把客户需求、SRS条目、设计文档、测试用例、验证结果全部串起来。它的作用是：

1. 正向追溯：从客户需求出发，能找到对应的设计和测试。
2. 反向追溯：从测试用例出发，能找到它验证的是哪条需求。
3. 变更影响分析：客户改了一条需求，能快速知道哪些设计、代码、测试要跟着改。

我习惯用Excel或者DOORS来维护RTM。格式大概这样：

4.5 需求分析阶段的知识体系

下面这张图，是我自己总结的需求分析阶段核心逻辑。你可以把它当成一个检查清单：

这张图把需求分析的四个核心环节串起来了。从客户需求出发，经过解读和分类，写成SRS，最后用RTM保证每条需求都有归宿。嗯，这里要注意：RTM不是做完就扔的，它要贯穿整个项目生命周期。

4.6 避坑指南：需求分析阶段的常见问题

最后，分享几个我亲身经历过的教训：

• 需求模糊：客户说“响应要快”，你得追问“快”是10ms还是100ms？不量化，后面全是扯皮。
• 需求遗漏：只写了功能需求，忘了写诊断需求。结果样机做出来，连个故障码都读不出来。
• 需求矛盾：一边要求“成本降低20%”，一边要求“所有器件必须用车规级”。这两个目标有时候是冲突的，得提前和客户沟通优先级。
• RTM不更新：需求变了，RTM没改。最后测试发现测错了东西，白干两周。