第2章：需求分析阶段——系统需求的定义与分类
各位同学，咱们今天聊聊需求分析。说实话，很多工程师觉得写需求是件苦差事，不如直接写代码来得痛快。但我做了十几年ECU开发，踩过的坑告诉我：需求阶段省下的时间，后面会加倍还回来。
我记得刚入行那会儿，带我的老工程师说过一句话：「需求写得越清楚，后面吵架越少。」当时我不太理解，直到自己带项目才明白——需求就是整个项目的「宪法」。你想想看，如果宪法都模棱两可，下面的人怎么执行？
2.1 系统需求的定义
系统需求，说白了就是「客户想要什么」和「系统必须做什么」的正式描述。它不能是模糊的想法，必须是可验证、可测试的陈述。
举个例子：
- 模糊的需求：「刹车响应要快」——多快算快？没法验证。
- 清晰的需求：「从踩下刹车踏板到制动压力达到目标值的90%，时间不超过150ms」——这就可测了。
核心原则：好的需求必须满足SMART原则——具体的(Specific)、可测量的(Measurable)、可实现的(Achievable)、相关的(Relevant)、有时限的(Time-bound)。
我在项目中遇到过一件事：客户说「雨刮器在雨天要自动启动」。我们理解成「检测到雨水就刮一下」，结果客户实际想要的是「根据雨量大小调节刮刷频率」。你看，一个模糊的需求，差点让整个功能重做。
2.2 功能需求与非功能需求
需求可以分成两大类，这个分类很重要，因为它们的验证方式完全不同。
2.2.1 功能需求
功能需求描述的是「系统做什么」。它直接对应ECU的某个功能行为。
常见的功能需求例子：
- 当车速超过120km/h时，仪表盘显示超速警告图标
- 按下车窗升降开关后，车窗电机在200ms内开始动作
- 发动机水温超过105°C时，冷却风扇以高速档运行
这些需求都可以通过「输入→处理→输出」的方式来描述。我个人习惯用「当...时，系统...」的句式来写功能需求，清晰明了。
2.2.2 非功能需求
非功能需求描述的是「系统做得怎么样」。它不直接对应某个功能，但决定了系统的质量。
常见的非功能需求包括：
| 类别 | 说明 | 例子 |
|---|---|---|
| 性能 | 响应时间、吞吐量 | CAN报文延迟不超过10ms |
| 可靠性 | 故障率、可用性 | 系统MTBF不低于10000小时 |
| 安全性 | 功能安全等级 | 满足ASIL B等级要求 |
| 可维护性 | 代码可读性、模块化 | 软件模块间耦合度低于0.3 |
| 环境适应性 | 温度、湿度、振动 | 工作温度范围-40°C~125°C |
避坑指南：我曾经见过一个项目，功能需求写得非常详细，但非功能需求几乎没写。结果样车测试时发现，所有功能都能跑，但一上高温环境就死机。为什么？因为没有定义高温下的工作条件。非功能需求不是「锦上添花」，而是「保命条款」。
2.3 需求管理工具简介
需求写好了，怎么管？靠Excel？小项目还行，大项目就乱套了。我见过用Excel管理需求的团队，到了后期根本分不清哪个版本是最新的。
这里介绍两款主流工具：DOORS和Polarion。
2.3.1 IBM DOORS
DOORS是传统老牌工具，很多Tier 1供应商都在用。它的核心优势是：
- 强追溯性：每条需求都可以链接到测试用例、设计文档
- 基线管理：可以锁定某个版本的需求集，防止随意修改
- 形式化语言支持：可以用逻辑表达式定义需求关系
但DOORS也有缺点：界面老旧，学习曲线陡峭。我记得第一次用DOORS时，光配置视图就折腾了半天。
2.3.2 Siemens Polarion
Polarion是后起之秀，基于Web的架构，用起来更现代。它的特点：
- 协作友好：多人同时在线编辑，实时同步
- 与ALM集成：可以和Jira、Jenkins等工具打通
- 模板丰富：内置了ASPICE、ISO 26262等标准模板
我个人更倾向于Polarion，尤其是做敏捷开发时。但如果你在传统OEM工作，DOORS可能还是主流。
我的建议：工具只是手段，关键是流程。不管你用DOORS还是Polarion，一定要建立「需求变更控制流程」。我曾经有个项目，客户半夜发邮件改需求，工程师第二天直接改代码，结果测试用例没更新，最后出了个大bug。从那以后，我要求所有需求变更必须走正式流程，哪怕只是改一个字。
2.4 需求分析中的常见误区
最后，分享几个我踩过的坑：
- 需求写得太技术化：需求是给所有人看的，包括测试、项目经理、客户。别用太多技术术语。
- 忽略需求优先级：所有需求都标「必须实现」，等于没有优先级。我习惯用MoSCoW方法——Must have、Should have、Could have、Won't have。
- 需求与设计混为一谈：需求是「做什么」，设计是「怎么做」。别在需求里写「用SPI通信」，那是设计决策。
嗯，这一章的内容就到这里。下一章我们聊聊系统架构设计，看看怎么把需求转化成具体的模块划分。记住一句话：需求分析做得好，后面开发没烦恼。