第2章：系统需求分析：功能需求与非功能需求、需求管理工具、需求追溯矩阵

好，咱们接着聊。上一章我们把变速箱控制软件的架构轮廓画了个大概，这一章得往里面填“肉”了——也就是需求分析。

说实话，我见过太多项目，代码写得飞起，结果最后发现需求压根没对齐。那场面，真是“车都造好了，发现轮子是方的”。所以，需求分析这块，咱们得花点功夫。

2.1 功能需求：变速箱到底要干什么？

功能需求，说白了就是“这软件得能干啥”。对于变速箱控制来说，核心功能其实就那么几大类。

• 换挡控制：根据车速、油门、发动机转速，决定什么时候升挡、什么时候降挡。这是基本功。
• 扭矩管理：换挡过程中，发动机扭矩怎么降、怎么恢复，直接影响平顺性。我见过一个项目，扭矩恢复快了，换挡像被人踹了一脚。
• 故障诊断：传感器坏了、执行器卡了，系统得能检测出来，并且进入安全模式。嗯，这里要注意，故障诊断的覆盖率直接决定了功能安全等级。
• 通讯管理：跟发动机、ABS、车身稳定系统通过CAN总线聊天。聊崩了，车就得“罢工”。

你可能会问：“这些功能需求怎么描述才够清楚？”我个人习惯用用例图加场景描述。比如“升挡”这个功能，我会写：

用例名称：自动升挡
触发条件：车速 > 20km/h，油门开度 < 30%
前置条件：变速箱处于D挡，油温正常
主流程：
1. TCU检测到升挡条件满足
2. 请求发动机降扭
3. 打开换挡电磁阀
4. 同步器动作
5. 关闭电磁阀
6. 请求发动机恢复扭矩
后置条件：挡位+1，扭矩恢复

你看，这样写，开发人员拿到手就知道该干什么，测试人员也知道怎么测。

2.2 非功能需求：跑得快、稳、还省油

功能需求管“能不能”，非功能需求管“好不好”。

我记得有一次，客户反馈说换挡太慢了。我们一查，功能逻辑完全正确，但实时性没达标。这就是非功能需求没写清楚。

常见的非功能需求包括：

• 实时性：换挡指令从发出到执行，延迟不能超过10ms。我建议把这个指标写进需求文档，不然开发人员可能用100ms的循环周期。
• 可靠性：MTBF（平均无故障时间）要大于5000小时。说白了，车开到报废，变速箱控制软件不能“死机”。
• 可维护性：代码要模块化，方便后续升级。我曾经接手过一个项目，所有逻辑写在一个函数里，3000行代码，那叫一个酸爽。
• 功耗：TCU本身功耗要低，不能把电瓶耗光了。特别是停车时，系统得进入休眠模式。

2.3 需求管理工具：别再用Excel了

我知道，很多小团队还在用Excel管需求。说实话，Excel不是不能用，但版本一多，你就分不清哪个是最新的了。

我个人推荐几款工具：

工具	适用场景	我的评价
DOORS	大型项目，功能安全要求高	功能强大，但学习曲线陡。我用了两年才玩明白。
Polarion	中型项目，与ALM集成好	界面友好，适合敏捷开发。
Jama	跨团队协作	云端部署，适合多地开发。
Codebeamer	嵌入式开发，与代码关联强	我最近在用的，感觉不错。

你想想看，如果需求变了，你能一键知道哪些代码、哪些测试用例受影响？这就是工具的价值。

2.4 需求追溯矩阵：谁是谁的爹？

需求追溯矩阵，听起来高大上，其实就是一张表，告诉你“每个需求对应哪个设计、哪个测试、哪段代码”。

为什么要做这个？

• 验证覆盖率：每个需求都有对应的测试用例吗？没有？那你怎么知道做对了？
• 变更影响分析：客户说“我要改换挡逻辑”，你通过矩阵一看，哦，影响3个模块、5个测试用例。改起来心里有底。
• 功能安全要求：ISO 26262明确要求，ASIL等级高的需求必须双向追溯。说白了，你得能证明“每个安全需求都被实现了，并且被验证了”。

举个例子：

需求ID	需求描述	设计文档	代码模块	测试用例
REQ-TCU-001	升挡延迟 < 10ms	DSN-TCU-001	shift_control.c	TC-TC-001
REQ-TCU-002	故障诊断覆盖率 > 95%	DSN-TCU-002	diag.c	TC-DIAG-001

2.5 我的实战建议

好了，理论讲完了，说点实际的。

第一，需求一定要分层。顶层是系统需求，中间是软件需求，底层是单元需求。每一层都要有明确的负责人。

第二，需求评审不能省。我建议至少做两轮：第一轮内部评审，第二轮客户评审。评审时，把开发、测试、系统工程师都叫上。别怕吵架，吵出来的需求才靠谱。

第三，需求变更要走流程。哪怕只是改一个字，也要走变更申请。不然，你永远不知道谁在什么时候改了什么东西。

最后，送你一句话：需求分析花的时间，会在开发阶段十倍地省回来。别急着写代码，先把需求理清楚。

下一章，我们聊聊系统架构设计。到时候，我会拿一个真实的变速箱控制架构出来，咱们一起拆解。