第二章 系统需求分析：需求捕获方法、需求分类与文档编写规范
各位同学，咱们今天聊聊系统需求分析。说实话，这一章是整个EEC开发流程的基石。我见过太多项目，代码写得漂亮，硬件设计也没问题，最后栽在需求上。为什么？因为需求没搞清楚，后面全是白费功夫。
2.1 需求捕获方法：别让需求“溜走”
需求捕获，说白了就是搞清楚客户到底想要什么。但这事儿没那么简单。客户往往自己都说不清楚。我遇到过一位客户，张口就说“我要一个高性能的控制器”。你问他多高？他说“反正要高”。嗯，这种需求你没法写进文档里。
我个人习惯用以下几种方法捕获需求：
- 客户访谈：面对面聊，别光听，要追问。比如客户说“响应要快”，你得问“快是多少毫秒？”。
- 场景分析：让客户描述典型使用场景。比如“飞机起飞时，系统应该怎么做？”。场景越具体，需求越清晰。
- 原型演示：做个简单的界面或仿真模型，让客户“摸一摸”。很多时候，客户看到原型才会说“哦，我要的不是这个”。
- 文档审查：看看已有的系统规范、行业标准。DO-178C里很多需求其实是从这些文档里提炼出来的。
2.2 需求分类：功能需求与非功能需求
需求拿到手，不能直接扔给开发团队。你得先分类。我习惯分成两大类：功能需求和非功能需求。
2.4.1 功能需求
功能需求就是“系统要做什么”。比如：
- “当发动机转速超过3000rpm时，系统应发出警告”
- “系统应支持CAN总线通信，波特率500kbps”
- “用户按下启动按钮后，系统应在2秒内完成自检”
这些需求很直接，测试也容易。你写个测试用例，跑一遍就知道过没过。
2.4.2 非功能需求
非功能需求就有点“虚”了。它描述的是系统“做得怎么样”。比如：
- 性能：CPU占用率不超过70%
- 可靠性：MTBF（平均无故障时间）不低于10000小时
- 安全性：符合DO-178C Level A标准
- 可维护性：代码注释率不低于30%
我曾经在一个项目中，非功能需求写得不够细。结果开发团队把性能优化放最后，最后测试时发现响应时间超标。嗯，从那以后，我要求非功能需求必须量化，不能写“响应要快”这种模糊话。
| 需求类型 | 示例 | 验证方法 |
|---|---|---|
| 功能需求 | 系统应记录最近100条故障日志 | 功能测试 |
| 非功能需求 | 日志写入时间不超过10ms | 性能测试 |
| 安全需求 | 系统应具备看门狗定时器 | 安全分析 |
2.3 需求文档编写规范：DO-178C的要求
说到需求文档，就绕不开DO-178C。这是航空电子领域的“圣经”。你想想看，飞机上的代码出问题，那可是要出人命的。所以DO-178C对需求文档的要求极其严格。
2.3.1 需求的可追溯性
DO-178C要求每条需求都必须可追溯。什么意思？就是你要能说清楚：
- 这条需求是从哪里来的（来源）
- 它对应哪些设计（设计实现）
- 它对应哪些测试用例（测试验证）
我建议用表格或工具（比如DOORS、Reqtify）来管理。别用Excel，项目大了根本管不住。
2.3.2 需求的唯一标识
每条需求都要有唯一的ID。比如：
REQ-SYS-001：系统应在上电后3秒内完成初始化
REQ-SYS-002：系统应支持3种工作模式：正常、维护、应急ID的命名规则要统一。我习惯用“REQ-模块-序号”这种格式。这样一看就知道是哪个模块的需求。
2.3.3 需求的原子性
一条需求只描述一个功能。别把多条需求揉在一起。比如：
❌ 错误写法：
系统应在上电后完成初始化，并检测所有传感器状态，如果传感器故障则报警。✅ 正确写法：
REQ-SYS-001：系统应在上电后3秒内完成初始化
REQ-SYS-002：系统应在初始化完成后检测所有传感器状态
REQ-SYS-003：如果传感器故障，系统应在1秒内发出报警你想想看，如果一条需求里包含多个功能，测试时怎么验证？一个功能没过，整条需求算不算没过？
2.3.4 需求的语言规范
DO-178C推荐使用“系统应...”这种句式。避免使用“可能”、“也许”、“大概”这类模糊词。我见过一份需求文档，里面写“系统可能支持CAN通信”。嗯，这种需求你让开发怎么做？
2.4 避坑指南：我踩过的那些坑
做需求分析这么多年，我踩过不少坑。分享几个典型的：
- 坑一：需求变更不管理。客户今天说要A，明天说要B。你不做变更管理，项目就乱套了。我建议用变更控制流程，每次变更都要评审、签字。
- 坑二：需求写得太技术。需求文档是给客户、测试、开发所有人看的。别写太多技术细节。比如“系统应使用I2C协议读取传感器”，这其实是设计，不是需求。
- 坑三：忽略非功能需求。功能需求写得很细，非功能需求一笔带过。结果系统做出来，功能都对，但性能不达标。嗯，这种项目我见过不止一个。
2.5 小结
需求分析这事儿，说难不难，说简单也不简单。关键是养成好习惯：多问、多记、多验证。我个人习惯在项目启动前，花30%的时间在需求分析上。别急着写代码，需求搞清楚了，后面反而更快。
下一章咱们聊聊系统架构设计。到时候我会讲讲怎么把需求转化成架构。嗯，那又是另一门学问了。