第四章：软件需求分析——从系统需求到软件需求的分解
大家好，欢迎来到第四章。
上一章我们聊完了系统需求。今天，我们往下走一层，进入软件需求分析。这一步，说白了就是回答一个问题：系统要我做什么，我作为软件，具体该怎么干？
我个人习惯把这一步叫做“翻译工作”。系统需求是给整车看的，软件需求是给代码看的。翻译得好，后面开发顺风顺水；翻译得不好，嗯，我见过太多项目在集成测试阶段吵得不可开交，最后发现是需求理解错了。
核心观点：软件需求分析不是简单的“复制粘贴”，而是基于系统需求，结合ECU的硬件资源、通信协议、操作系统等约束条件，进行的一次精细化分解。
4.1 从系统需求到软件需求的分解
系统需求通常描述的是“车辆要做什么”。比如：
- “当车速超过120km/h时，发出报警音。”
- “制动踏板被踩下时，制动灯必须在200ms内点亮。”
这些需求到了软件层面，就得拆成更细的条目。你想想看，软件不知道什么是“车速”，它只知道CAN总线上某个ID的第3个字节代表车速值。软件也不知道什么是“报警音”，它只知道某个GPIO引脚输出PWM波，频率是2kHz。
分解的原则，我总结为三点：
- 可验证性：每个软件需求都能通过测试来证明“我做到了”。
- 原子性：一个需求只描述一件事。别把“采集车速并判断是否超速”写在一起，拆成“采集车速”和“超速判断”两个需求。
- 无歧义：用数字说话，别用“大约”、“尽快”、“合理”这类词。
我的经验：我在项目中遇到过这样一个案例——系统需求写的是“在高温环境下，系统应正常工作”。结果软件需求里直接照抄了这句话。到了测试阶段，大家吵翻了：什么叫高温？50度？80度？持续多久？最后不得不回头补需求。所以，软件需求里必须写清楚：工作温度范围、持续时间、性能指标。
举个例子，系统需求是“当车速超过120km/h时，发出报警音”。分解后的软件需求可能是：
| 需求ID | 需求描述 | 验证方法 |
|---|---|---|
| SW-REQ-001 | 软件应通过CAN总线接收车速信号，信号ID为0x100，起始位为第2字节，长度为2字节，分辨率为0.01 km/h。 | CAN报文注入测试 |
| SW-REQ-002 | 软件应每10ms计算一次当前车速的滑动平均值，窗口大小为5个采样点。 | 单元测试 |
| SW-REQ-003 | 当滑动平均车速大于120 km/h时，软件应置位报警标志位。 | 单元测试 |
| SW-REQ-004 | 当报警标志位置位时，软件应驱动GPIO_PIN_5输出2kHz的PWM波，占空比为50%。 | 硬件在环测试 |
你看，一个系统需求，拆成了4个软件需求。每个需求都清清楚楚，测试工程师拿到手就知道怎么测。
4.2 软件需求规格说明书（SRS）的编写要点
SRS，Software Requirements Specification，是软件需求的“宪法”。所有开发、测试、管理工作，都得围着它转。
我见过很多SRS，写得像天书。要么太抽象，要么太啰嗦。这里我分享几个编写要点：
4.2.1 结构要清晰
我个人习惯用层次化结构。比如：
- 第1章：引言（目的、范围、定义、参考文献）
- 第2章：总体描述（产品视角、用户特征、约束条件）
- 第3章：功能需求（按功能模块划分，每个模块下再细分）
- 第4章：非功能需求（性能、安全、可靠性、可维护性）
- 第5章：接口需求（硬件接口、软件接口、通信接口）
- 第6章：需求可追溯性矩阵
4.2.2 语言要精确
避免模糊词汇。比如：
- ❌ “系统应快速响应” → ✅ “系统应在50ms内完成响应”
- ❌ “数据应定期更新” → ✅ “数据应每100ms更新一次”
- ❌ “错误应被妥善处理” → ✅ “当检测到CRC校验错误时，软件应丢弃当前报文，并置位错误计数器”
避坑指南：我曾经在一个项目里看到SRS写“软件应具备良好的可扩展性”。这句话毫无意义。什么叫“良好”？谁来定义？正确的写法是：“软件应支持通过CAN总线在线升级固件，升级过程中不应影响其他ECU的正常通信。”——这才是可扩展性的具体体现。
4.2.3 每个需求都要有唯一ID
这个太重要了。没有ID的需求，就像没有名字的人，你没法讨论它、追踪它、测试它。我建议的命名规则是：
- SW-REQ-XXX：功能需求
- SW-NFR-XXX：非功能需求
- SW-INT-XXX：接口需求
这样一看ID，就知道是什么类型的需求。
4.2.4 需求之间不能冲突
比如，一个需求说“系统应在10ms内响应”，另一个需求说“系统应执行完整的自检流程，耗时50ms”。这两个需求放在一起，就是矛盾的。你必须在SRS里明确优先级，或者给出折中方案。
4.3 需求可追溯性矩阵
需求可追溯性矩阵，英文叫Requirements Traceability Matrix，简称RTM。这东西，说白了就是一张表，告诉你“谁是从谁来的，谁又去了哪里”。
为什么需要它？
你想想看，一个ECU可能有几百条系统需求，分解后变成上千条软件需求。如果没有RTM，你根本不知道：
- 这条软件需求对应哪条系统需求？
- 如果系统需求变了，哪些软件需求需要跟着改？
- 测试用例覆盖了哪些需求？还有哪些需求没被测试？
RTM就是用来回答这些问题的。
RTM的典型结构：
| 系统需求ID | 系统需求描述 | 软件需求ID | 软件需求描述 | 设计文档 | 测试用例ID | 状态 |
|---|---|---|---|---|---|---|
| SYS-REQ-001 | 车速超过120km/h时报警 | SW-REQ-001 | 接收车速信号 | SW-DES-001 | TC-001 | 已实现 |
| SYS-REQ-001 | 车速超过120km/h时报警 | SW-REQ-002 | 计算滑动平均车速 | SW-DES-002 | TC-002 | 已实现 |
| SYS-REQ-001 | 车速超过120km/h时报警 | SW-REQ-003 | 判断超速并置位标志 | SW-DES-003 | TC-003 | 已实现 |
| SYS-REQ-001 | 车速超过120km/h时报警 | SW-REQ-004 | 驱动PWM输出报警音 | SW-DES-004 | TC-004 | 待测试 |
你看，一条系统需求，对应四条软件需求。每条软件需求都有对应的设计文档和测试用例。状态栏告诉你，哪些做完了，哪些还没做。
我的习惯：我一般会在项目启动时就建好RTM的框架，然后在开发过程中持续更新。别等到最后再补，那时候你会发现根本补不全。我记得有个项目，团队觉得RTM太麻烦，想着“反正需求都在文档里，到时候再整理”。结果到了V模型右侧的测试阶段，发现有一半的测试用例不知道对应哪个需求，又花了三周时间重新梳理。嗯，从那以后，RTM就成了我每个项目的标配。
RTM的维护要点：
- 双向追溯：从系统需求能查到软件需求，从软件需求也能查到系统需求。
- 变更管理：任何需求变更，都要同步更新RTM。别只改需求文档，忘了改矩阵。
- 自动化工具：如果项目规模大，建议用DOORS、Polarion或Jama这类工具。Excel虽然方便，但几百条需求时，维护起来很痛苦。
小结
这一章我们聊了三个核心内容：
- 需求分解：把系统需求翻译成软件能理解的、可验证的、原子化的需求。
- SRS编写：结构清晰、语言精确、唯一ID、避免冲突。
- RTM：建立从系统需求到软件需求、再到设计和测试的完整追溯链。
下一章，我们会进入软件架构设计。到时候聊聊怎么把这一堆需求，组织成一个能跑起来的软件架构。
好，今天就到这里。有什么问题，欢迎交流。
公众号:蓝海资料掘金营，微信deep3321