4. 软件需求分析：从系统需求到软件需求的映射

好，咱们进入第四章。系统需求分析做完之后，下一步就是软件需求分析。说白了，就是把系统分配给软件的那些活儿，拆成一条条具体、可验证的软件需求。

这一步做不好，后面编码、测试全是糊涂账。我见过太多项目，系统需求写得很漂亮，一到软件层面就含糊了——"系统应能快速响应"这种话，你让开发怎么实现？测试怎么验收？

4.1 从系统需求到软件需求的映射

系统需求是"做什么"，软件需求是"怎么做"的细化。举个例子：系统需求说"车辆在碰撞后0.5秒内解锁车门"，那软件需求就要拆成：

• 碰撞信号检测的阈值和滤波策略
• 解锁指令的优先级和仲裁逻辑
• 执行器的驱动时序和故障回退

我个人习惯用需求追溯矩阵来做这个映射。每一行是一条系统需求，每一列是它拆出来的软件需求。这样能确保没有遗漏，也方便后续变更影响分析。

我在项目中遇到过一种情况：系统需求里写了"系统应支持OTA升级"，结果软件团队只拆了"下载"和"安装"，忘了"版本校验"和"回滚机制"。后来升级失败，车机变砖，差点召回。所以映射的时候，一定要把异常路径也考虑进去。

4.2 软件需求规格说明（SRS）的编写要点

SRS不是写作文，是写合同。它要清晰、无歧义、可测试。我总结了几个关键点：

4.2.1 结构化组织

我建议按功能模块来组织SRS，而不是按开发团队或时间顺序。比如：

• 4.1 电源管理模块
• 4.2 通信管理模块
• 4.3 诊断服务模块

每个模块下面再分：功能需求、接口需求、性能需求、安全需求。

4.2.2 需求编号与唯一性

每条需求必须有唯一ID。别用"SW_REQ_001"这种流水号，我习惯用"SW_PWR_ACT_001"这种带模块前缀的编码。你想想看，后期变更管理的时候，一眼就能看出是哪个模块的需求变了。

4.2.3 需求描述规范

描述要遵循"谁 + 在什么条件下 + 做什么 + 达到什么标准"的句式。举个例子：

❌ 错误写法：系统应能处理CAN报文。
✅ 正确写法：当ECU接收到ID为0x123的CAN报文时，应在10ms内解析并更新内部状态变量。

4.3 需求优先级划分（MoSCoW方法）

资源永远不够，需求永远太多。所以必须排优先级。MoSCoW方法是我最常用的：

优先级	含义	举例	交付要求
Must have	必须有，否则系统不可用	制动信号响应、安全气囊触发	必须交付，不可协商
Should have	应该有，但可临时降级	自动大灯、雨量感应	尽量交付，可延期
Could have	可以有，锦上添花	氛围灯颜色自定义、迎宾灯效	资源允许时交付
Won't have	这次不做，以后再说	手势控制、AR导航	明确排除，避免误解

划分优先级的时候，我建议让系统工程师、软件工程师、测试工程师、项目经理一起参与。为什么？因为不同角色对"重要"的理解不一样。项目经理觉得"成本"重要，测试觉得"可测性"重要，开发觉得"实现难度"重要。大家坐下来吵一架，优先级就清楚了。

4.4 需求评审流程（正式评审与走查）

需求写完了，不能直接扔给开发。必须评审。评审分两种：正式评审和走查。

4.4.1 正式评审

正式评审像法庭审判，流程严格，有角色分工：

1. 策划：确定评审范围、时间、参与人
2. 预审：评审员提前阅读材料，记录问题
3. 评审会议：逐条过需求，记录缺陷和决策
4. 返工：作者修改缺陷
5. 验证：评审组长确认修改是否到位
6. 关闭：所有缺陷关闭，评审结束

正式评审适合关键安全需求或变更影响大的需求。我经历过一次安全气囊控制器的需求评审，整整开了三天会，每条需求都抠字眼。虽然累，但确实发现了好几个歧义点。

4.4.2 走查

走查就轻松多了。作者把需求讲一遍，大家边听边提意见。没有严格的角色分工，也不需要提前预审。适合非关键需求或初稿阶段。

走查的优点是快，缺点是容易漏问题。所以我一般建议：先走查，再正式评审。走查把明显的问题过滤掉，正式评审集中精力抠细节。

嗯，这里要注意：评审不是为了找茬，是为了提前发现问题。我见过一些团队把评审开成了批斗会，作者被怼得抬不起头。这样不好。评审应该是建设性的，大家的目标是让需求更好，不是证明谁错了。

这张图把整个流程串起来了。从系统需求出发，经过映射、编写、优先级划分，最后到评审。每一步都不可或缺。你想想看，如果跳过映射直接写SRS，很可能漏掉关键功能；如果跳过优先级划分，开发团队不知道先做什么后做什么；如果跳过评审，需求里的坑就留给开发和测试去踩了。