4. SWE.1 软件需求分析：如何从系统需求导出软件需求，需求的可追溯性与一致性
好，我们进入SWE.1。这个环节，说白了就是回答一个问题：系统想要什么，软件具体要做什么？
很多团队容易在这里翻车。系统需求写了一大堆，到了软件这边，要么直接照抄，要么凭空发挥。结果呢？开发到一半发现软件做出来的东西，跟系统想要的根本不是一回事。我见过最夸张的一次，系统需求里写了个“故障诊断”，软件团队直接做了个故障码列表，结果系统那边要的是基于模型的预测性诊断——完全对不上。
所以，今天我们就来聊聊，怎么把系统需求“翻译”成软件需求，并且保证这条链路清晰、可追溯。
4.1 系统需求与软件需求的“分界线”
先搞清楚一个概念：系统需求是“做什么”，软件需求是“怎么做”。
举个例子：
- 系统需求：车辆在碰撞后0.5秒内，自动拨打紧急呼叫电话。
- 软件需求：当安全气囊ECU发送碰撞信号后，软件模块应在200ms内启动蜂窝网络连接，并在300ms内完成呼叫建立。
看出来了吗？系统需求关注的是“整车行为”，软件需求关注的是“软件模块的具体实现”。
核心原则：软件需求必须能从系统需求中“推导”出来，而不是“创造”出来。
我个人习惯，在拿到系统需求后，先做一件事：拆解。把系统需求里的每一个动词、每一个时间约束、每一个条件，都拆成软件能理解的单元。
4.2 导出软件需求的“三步法”
我总结了一个简单的方法，叫“三步法”。你试试看，很管用。
第一步：识别系统需求中的“软件相关”元素
不是所有系统需求都跟软件有关。比如“安装支架采用不锈钢材质”，这跟软件没关系，直接过滤掉。但“系统应支持OTA升级”，这100%是软件的事。
第二步：分解为软件功能
把系统需求拆成一个个具体的软件功能。比如“OTA升级”可以拆成：
- 下载管理
- 版本校验
- 安装回滚
- 状态上报
第三步：定义验收标准
每个软件需求，必须有一个明确的、可测试的验收标准。不能是“性能好”，而应该是“下载速度不低于2MB/s，且CPU占用率不超过30%”。
我的小技巧：写软件需求时，多用“应”、“必须”、“当...时”这类词。比如“当接收到CAN报文ID 0x123时，软件应解析并更新车速变量”。这样写，测试人员一看就知道怎么测。
4.3 需求的可追溯性：别让需求“断链”
可追溯性，是ASPICE里反复强调的东西。说白了，就是从系统需求到软件需求，再到代码、测试用例，这条线不能断。
我曾经在一个项目里吃过亏。系统需求改了，但软件需求没同步更新。结果测试用例还是按旧需求写的，最后测试全过，但实车功能就是不对。查了三天，才发现是需求追溯链断了。
所以，我建议你在项目一开始就建立追溯矩阵。比如这样：
| 系统需求ID | 系统需求描述 | 软件需求ID | 软件需求描述 | 测试用例ID |
|---|---|---|---|---|
| SYS-001 | 碰撞后0.5s内拨打紧急电话 | SW-001 | 200ms内启动蜂窝网络 | TC-001 |
| SYS-001 | 碰撞后0.5s内拨打紧急电话 | SW-002 | 300ms内完成呼叫建立 | TC-002 |
| SYS-002 | 支持OTA升级 | SW-003 | 下载管理模块 | TC-003 |
你看，一个系统需求可能对应多个软件需求，一个软件需求也可能对应多个测试用例。这就是“多对多”的追溯关系。工具上，我推荐用DOORS或Polarion，但小团队用Excel也能管，关键是坚持维护。
4.4 需求的一致性：别让需求“打架”
一致性，比可追溯性更难搞。因为需求多了，难免会有冲突。
举个例子：系统需求说“系统应在1秒内响应”，但软件需求里写“数据采集周期为2秒”。这不就矛盾了吗？
怎么避免？我分享三个经验：
- 定期做需求评审。别等开发完了再发现矛盾。我习惯每两周拉一次评审会，系统工程师、软件工程师、测试工程师坐在一起，一条一条过。
- 建立需求冲突处理机制。发现矛盾后，谁有最终决定权？我建议是系统架构师。但前提是，他必须理解软件实现的代价。
- 用工具做自动化检查。比如，你可以写个脚本，检查所有需求中的时间约束、数值范围是否一致。嗯，这个我后面会专门讲。
注意：一致性检查不是一次性的。需求变更时，一定要重新检查。我见过最惨的案例，就是改了一个系统需求，忘了改对应的软件需求，结果整个模块重做。
4.5 实战：一个完整的导出示例
我们拿一个实际例子走一遍流程。
系统需求：车辆在行驶过程中，当检测到驾驶员疲劳时，系统应发出声光报警，并在10秒内无响应时，自动减速至30km/h。
好，开始拆解：
- 识别软件相关元素：疲劳检测、声光报警、计时器、自动减速控制。
- 分解为软件功能：
- 疲劳检测算法（输入：方向盘转角、车道偏移等）
- 报警管理模块（控制蜂鸣器和LED灯）
- 计时器模块（10秒倒计时）
- 减速控制模块（通过CAN发送减速请求）
- 定义验收标准：
- 当疲劳检测算法输出为“疲劳”时，报警管理模块应在100ms内激活声光报警。
- 计时器模块应在报警激活后开始10秒倒计时，精度±100ms。
- 若10秒内无驾驶员干预（如按下取消按钮），减速控制模块应发送减速请求，目标速度30km/h，减速度不超过2m/s²。
你看，这样写出来的软件需求，开发人员知道要做什么，测试人员知道怎么测，系统工程师也能追溯回去。完美。
总结一下：SWE.1的核心就三件事——拆解、追溯、一致。拆解要细，追溯要全，一致要严。做到这三点，你的软件需求分析就稳了。
下一章，我们会聊SWE.2——软件架构设计。到时候我会讲讲怎么把今天写的这些需求，变成真正的架构方案。嗯，那才是真正考验功力的时候。