3、需求分析基础：需求的定义与分类、功能性需求与非功能性需求、需求分析的关键活动

3.1 需求到底是什么？——先聊聊我的理解

做嵌入式系统这么多年，我见过太多项目栽在需求上。说白了，需求就是「系统应该做什么」和「系统应该做成什么样」的完整描述。但你别小看这句话，我当年在做一个ABS控制器项目时，就因为「制动响应时间」这个需求写得不够清楚，导致硬件选型出了大问题，最后不得不返工。

我个人习惯把需求比作「合同」。客户和开发团队之间，白纸黑字写清楚。你想想看，如果合同条款模棱两可，后面扯皮的事肯定少不了。在汽车领域，尤其是ABS这种安全关键系统，需求含糊的代价可能是生命。

3.2 需求的分类——别把所有需求混为一谈

我经常看到新手工程师把各种需求堆在一起，结果评审时谁也理不清。其实需求分类有章可循，我一般按下面这个框架来梳理：

分类维度	类型	典型例子（ABS系统）
按层次	用户需求 / 系统需求 / 软件需求	驾驶员期望制动距离 ≤ 40m（用户）→ ABS控制器响应时间 ≤ 10ms（系统）→ 轮速采样周期 = 5ms（软件）
按性质	功能性 / 非功能性	检测车轮是否抱死（功能）→ 故障诊断覆盖率 ≥ 99%（非功能）
按来源	业务需求 / 法规需求 / 接口需求	支持4通道独立控制（业务）→ 满足ISO 26262 ASIL D（法规）→ CAN总线通信速率500kbps（接口）

嗯，这里要注意：分类不是目的，目的是让每个需求都有明确的归属和责任人。我在项目中吃过亏——有一次把法规需求混在功能需求里写，结果测试时才发现漏了「电磁兼容性」的要求，那叫一个狼狈。

3.3 功能性需求与非功能性需求——ABS系统的实战视角

功能性需求，说白了就是「系统要做什么事」。拿ABS来说：

• 实时采集四个车轮的转速信号
• 根据滑移率判断车轮是否趋于抱死
• 控制电磁阀调节制动压力
• 在故障时点亮警告灯并降级运行

这些需求很直观，写起来也相对容易。但真正考验功力的是非功能性需求——它描述的是「系统做得有多好」。

我曾经遇到一个项目，功能性需求写得滴水不漏，但非功能性需求几乎空白。结果样车测试时，ABS在高温环境下频繁误触发，查了两个月才发现是温度漂移导致传感器阈值偏移。你说冤不冤？

3.4 需求分析的关键活动——我的五步法

做了十几年嵌入式，我总结了一套需求分析的「五步法」，每一步都有血泪教训在里面：

1. 需求获取——别只等着客户给文档。我习惯主动去问、去观察、去模拟场景。做ABS时，我专门跟车跑了三天山路，才真正理解「湿滑路面制动」到底意味着什么。
2. 需求分析——把模糊的描述变成可量化的指标。比如「制动响应要快」→「从ECU接收到轮速信号到输出电磁阀控制信号，总延迟 ≤ 3ms」。
3. 需求规格化——用标准模板写需求。我个人推荐使用EARS（Easy Approach to Requirements Syntax）语法，每条需求都写成「当...时，系统应...」的结构，清晰且无歧义。
4. 需求验证——找同行评审，别自己闷头写。我记得有一次评审会上，测试工程师指着一条需求问：「这个『正常情况』怎么定义？」当场把我问住了。从那以后，我每条需求都要求有明确的验收标准。
5. 需求管理——用工具跟踪变更。在MBSE环境下，我常用Polarion或DOORS来维护需求基线。每次变更都要问三个问题：影响谁？成本多少？风险多大？

3.5 避坑指南——我踩过的那些坑

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

• 「想当然」的坑： 我曾经默认「轮速传感器信号是干净的」，结果实际工况下噪声大得离谱。后来我学乖了，每条需求都追问一句：「如果这个条件不成立，系统该怎么办？」
• 「过度细化」的坑： 需求不是越细越好。我见过有人把「LED闪烁频率」写成「每500ms亮100ms，再400ms灭」，结果硬件实现时发现跟PWM模块的时钟分频对不上。其实写成「闪烁频率2Hz，占空比20%」就够了。
• 「忽略接口」的坑： ABS系统不是孤岛，它跟ESP、TCS、发动机ECU都有交互。接口需求写不清楚，联调时就是灾难。我现在做需求分析，第一件事就是画系统上下文图，把所有外部接口列清楚。

好了，关于需求分析的基础就聊这么多。下一章我会结合MBSE工具，讲讲怎么用SysML建模语言来结构化地表达这些需求。到时候咱们再细聊。