3、EPS系统需求分析总览：需求分析在V模型中的位置，功能需求与非功能需求，需求层级
各位同学，咱们今天聊聊EPS需求分析的总览。说实话，很多工程师一上来就写代码、画原理图，结果做到一半发现需求没搞清楚，返工成本高得吓人。我当年就吃过这个亏，所以今天把这部分单独拎出来讲透。
3.1 需求分析在V模型中的位置
V模型大家应该不陌生。左边是需求分析、系统设计、子系统设计、组件实现，右边是单元测试、集成测试、系统测试、验收测试。需求分析就在V模型的左上角，是整个开发流程的起点。
为什么说它重要？你想想看，V模型的精髓是"左倾验证"——左边的每个阶段，都要对应右边的测试活动。需求分析阶段产出的需求文档，直接决定了系统测试和验收测试的通过标准。我在项目中遇到过，有人把需求写得模棱两可，结果测试团队和开发团队吵了三天，最后发现是需求本身的问题。
核心观点：需求分析的质量，决定了整个项目80%的风险。V模型左边花1小时把需求理清楚，右边能省下10小时的返工时间。
我个人习惯，在V模型的需求分析阶段，会做三件事：
- 明确输入：客户到底要什么？法规要求是什么？
- 定义输出：需求文档长什么样？验收标准是什么？
- 建立追溯：每个需求都能追溯到测试用例，反之亦然。
嗯，这里要注意，V模型不是死板的。实际项目中，需求分析往往要迭代好几次。我建议你把这个阶段看作"螺旋上升"的过程，而不是一次性的任务。
3.2 功能需求与非功能需求
需求分两类：功能需求和非功能需求。说白了，功能需求是"系统能做什么"，非功能需求是"系统做得怎么样"。
3.4.1 功能需求
功能需求描述的是EPS系统的具体行为。比如：
- 方向盘助力随车速变化
- 主动回正功能
- 故障诊断与报警
- 与CAN总线通信
这些需求通常用"系统应..."的句式来描述。我见过很多新手，写功能需求时喜欢用"可能"、"大概"这类模糊词。千万别这样！功能需求必须是可验证的。比如"方向盘助力随车速变化"就不够具体，应该写成"当车速从0km/h增加到100km/h时，方向盘手力从2Nm线性增加到5Nm"。
小技巧：写功能需求时，问自己三个问题——输入是什么？输出是什么？边界条件是什么？三个问题都答清楚了，需求就合格了。
3.4.2 非功能需求
非功能需求往往被忽视，但恰恰是这些需求决定了产品的品质。常见的非功能需求包括：
| 类别 | 示例 | 为什么重要 |
|---|---|---|
| 性能 | 助力响应时间≤50ms | 影响驾驶手感 |
| 可靠性 | MTBF≥10000小时 | 影响安全性 |
| 安全性 | 故障后进入安全模式 | 法规强制要求 |
| 可维护性 | 支持OTA升级 | 降低售后成本 |
| 环境适应性 | 工作温度-40℃~125℃ | 适应各种工况 |
我曾经犯过一个错，只关注功能需求，把非功能需求丢给开发团队"看着办"。结果样机做出来，高温测试直接挂了——电机驱动器在85℃时频繁重启。后来花了两个月重新选型、改设计，教训深刻啊。
避坑指南：非功能需求一定要量化。别写"响应要快"，要写"从CAN报文接收到助力输出，延迟不超过50ms"。我曾经因为"响应要快"这个模糊需求，和测试团队扯皮了整整一周。
3.3 需求层级：系统级、子系统级、组件级
需求不是平铺直叙的，它有层级结构。我习惯把需求分成三层：系统级、子系统级、组件级。每一层关注的点不同，粒度也不同。
3.3.1 系统级需求
系统级需求描述的是整个EPS系统对外表现的行为。它不关心内部怎么实现，只关心"系统对外提供什么功能"。
举个例子：
- "EPS系统应提供随速助力功能"
- "EPS系统应支持CAN诊断协议"
- "EPS系统在故障时应进入安全模式"
系统级需求通常由系统工程师编写，面向客户和整车厂。我建议你写系统级需求时，多用"用户语言"，少用"技术术语"。比如"助力平滑"比"PWM占空比调节平滑"更容易让客户理解。
3.3.2 子系统级需求
子系统级需求把系统级需求分解到各个子系统。EPS系统通常包含：
- 机械子系统：转向管柱、齿轮齿条、万向节
- 电子子系统：ECU、传感器、电机
- 软件子系统：控制算法、诊断逻辑、通信协议
比如系统级需求"随速助力功能"，分解到子系统级就是：
- 机械子系统：提供足够的机械刚度，保证助力传递效率≥95%
- 电子子系统：扭矩传感器精度≤±0.1Nm，电机响应时间≤10ms
- 软件子系统：助力曲线查表算法，更新频率≥100Hz
我在项目中遇到过，子系统级需求写得太粗，导致机械团队和电子团队互相推诿。后来我强制要求每个子系统需求都要有明确的接口定义，才解决了这个问题。
3.3.3 组件级需求
组件级需求是最细粒度的需求，直接指导硬件设计和软件开发。比如：
- "电机驱动芯片应支持PWM频率20kHz"
- "扭矩传感器SPI通信速率≥1MHz"
- "软件模块应实现PID控制算法，采样周期1ms"
组件级需求必须可测试、可验证。我建议你写组件级需求时，直接给出验收标准。比如"电机驱动芯片应支持PWM频率20kHz，实测误差≤±1%"，这样测试团队拿到手就能直接测。
总结一下：系统级需求回答"为什么做"，子系统级需求回答"做什么"，组件级需求回答"怎么做"。三层需求层层分解，每一层都要有明确的输入输出和验收标准。
3.4 我的经验总结
做了这么多年EPS，我总结了几条需求分析的心得：
- 需求一定要可追溯：每个组件级需求都能追溯到子系统级，再追溯到系统级。反过来也一样。这样改需求时，影响范围一目了然。
- 非功能需求别后补：我见过太多项目，功能需求写完了，非功能需求随便补几条。结果后期测试发现性能不达标，改起来伤筋动骨。
- 需求评审要拉上测试：测试团队是最早发现需求问题的人。让他们参与评审，能提前发现很多坑。
- 别怕需求变更：需求变更是正常的，但变更要有流程。我习惯用需求追溯矩阵来管理变更，每次变更都评估影响范围。
好了，这一章的内容就到这里。下一章咱们聊聊具体的需求分析方法论，到时候我会拿一个真实的EPS项目案例来拆解。记住，需求分析不是写文档，而是理清思路、规避风险的过程。你花在需求分析上的每一分钟，都会在后面的开发阶段得到回报。