4. 需求分类：功能需求、非功能需求、性能需求、接口需求、安全需求
好，咱们继续往下聊。
上一章我们把需求从哪来、怎么挖讲清楚了。但光有需求还不够，你得会分类。为什么？
我见过太多项目，需求文档写得像流水账，开发拿到手一脸懵。你想想看，一个功能需求和一条安全需求混在一起，测试用例怎么写？评审会怎么开？
所以，今天咱们就聊聊需求分类这件事。我个人习惯把ECU需求分成五类：功能需求、非功能需求、性能需求、接口需求、安全需求。这五类，基本覆盖了ECU开发的方方面面。
4.1 功能需求：它要「做什么」
功能需求是最直观的。说白了，就是ECU必须完成的具体行为。
比如：
- 当车速超过120km/h时，仪表盘发出报警声
- 按下车窗升降开关，车窗电机正转3秒
- 接收到CAN总线上的刹车信号，点亮刹车灯
这些都是功能需求。它们描述的是「输入-处理-输出」的完整链路。
我的经验：写功能需求时，一定要把触发条件、执行动作、预期结果写清楚。我曾经在项目里看到一条需求写着「车门未关好时报警」，结果开发做了蜂鸣器响，测试说应该亮灯，最后发现需求里根本没写用什么方式报警。这种坑，踩一次就够了。
功能需求通常用用例图或状态机来描述。我个人习惯在需求文档里附一个简单的状态转换表：
| 当前状态 | 触发事件 | 执行动作 | 下一状态 |
|---|---|---|---|
| 车门关闭 | 门锁电机转动 | 解锁门锁 | 车门解锁 |
| 车门解锁 | 拉手开关按下 | 驱动门锁电机 | 车门打开 |
4.2 非功能需求：它要「做得怎么样」
功能需求回答了「做什么」，非功能需求回答的是「做得怎么样」。
举个例子：
- 系统启动时间不超过2秒
- 软件升级过程中不能丢失已存储的配置参数
- 系统在-40°C到85°C范围内正常工作
这些都是非功能需求。它们往往比功能需求更难量化，但恰恰是决定ECU好不好用的关键。
避坑指南：我曾经遇到一个项目，功能需求写得非常详细，但非功能需求只写了「系统应稳定可靠」。结果测试时发现，连续运行72小时后，内存泄漏导致系统死机。从那以后，我要求每个非功能需求必须带一个可测量的指标，比如「连续运行1000小时，内存占用增长不超过5%」。
非功能需求通常包括：
- 可用性：系统全年可用时间比例
- 可维护性：代码模块化程度、诊断接口是否标准
- 可移植性：是否支持跨平台编译
- 可靠性：平均无故障时间（MTBF）
4.3 性能需求：它要「多快、多准、多省」
性能需求，其实是非功能需求的一个子集。但我习惯把它单独拎出来，因为ECU开发中，性能问题太容易出事了。
性能需求关注三个维度：
- 时间：响应时间、采样周期、通信延迟
- 资源：CPU占用率、内存使用量、Flash空间
- 精度：传感器采样精度、控制输出误差范围
举个例子：
// 性能需求示例
// 1. 从CAN报文接收到刹车信号，到刹车灯点亮，延迟不超过50ms
// 2. 发动机转速采样周期为10ms，误差不超过±1ms
// 3. 系统运行时，CPU占用率不超过70%，峰值不超过85%注意：性能需求一定要和硬件平台挂钩。同样的软件，跑在200MHz的芯片上和跑在400MHz的芯片上，性能表现完全不同。我建议在写性能需求时，明确标注目标硬件平台和编译器版本。
4.4 接口需求：它和谁「说话」
ECU不是孤岛。它要和传感器、执行器、其他ECU、诊断工具、甚至云端通信。接口需求就是定义这些「对话规则」。
接口需求分为三类：
- 硬件接口：引脚定义、电平标准、连接器型号
- 软件接口：API函数原型、数据结构定义、通信协议
- 人机接口：按键布局、指示灯颜色、报警音频率
我见过最惨的案例，是两个ECU团队各自开发，结果一个用CAN 2.0A，一个用CAN 2.0B，联调时才发现ID长度对不上。嗯，接口需求没写清楚，后果就是加班改代码。
| 接口类型 | 需求示例 | 验证方法 |
|---|---|---|
| CAN通信 | ID=0x123，周期100ms，数据长度8字节 | CANoe监控报文 |
| GPIO | Pin5输出高电平驱动继电器，电流≥100mA | 万用表测量 |
| UART | 波特率115200，8N1，无流控 | 串口调试工具 |
4.5 安全需求：它不能「闯祸」
最后，也是最重要的——安全需求。
汽车电子和手机不一样。手机死机了重启就行，ECU死机了可能车就失控了。所以安全需求是ECU需求分析中的红线，碰不得。
安全需求通常来自：
- 功能安全标准：ISO 26262定义的ASIL等级要求
- 预期功能安全：SOTIF（ISO 21448）
- 网络安全：防止黑客攻击、数据篡改
举个例子：
// 安全需求示例
// 1. 当刹车踏板位置传感器故障时，系统进入跛行模式，最高车速限制为30km/h
// 2. 安全气囊ECU必须在5ms内检测到碰撞信号，并在10ms内触发点火
// 3. 所有CAN报文必须包含CRC校验，防止数据被篡改我的经验：安全需求一定要写「失效模式」和「安全状态」。比如「当主电源掉电时，系统应在100ms内切换到备用电源，并保持所有安全功能正常运行」。我曾经在评审会上问开发：「如果这个传感器坏了，系统会怎么样？」开发想了半天说：「应该会报错吧。」——这种回答，在安全评审里是过不了关的。
安全需求还有一个特点：它往往是冗余的。比如一个关键信号，可能需要两路传感器同时采集，两路MCU同时计算，最后比较结果。这不是浪费，这是安全。
小结
好了，五类需求咱们都过了一遍。你可能会问：「一个需求能不能同时属于多个类别？」
答案是：可以。比如「系统启动时间不超过2秒」，它既是性能需求（时间维度），也是非功能需求（可用性维度）。分类的目的是为了管理，不是为了贴标签。
我个人习惯在需求文档里给每条需求加一个「类型」字段，这样评审时一目了然。测试团队也能根据类型设计不同的测试用例。
下一章，咱们聊聊怎么把这些需求写成规范的文档。嗯，那又是另一门学问了。