4. 需求建模与结构化：从模糊到精确的桥梁
需求文档写了一大堆文字，评审会上大家点头说“明白了”，结果开发做出来完全不是那么回事。这种场景，我遇到过太多次了。
为什么会这样？因为自然语言天生就有歧义。你说“快速响应”，我认为是 200ms，他觉得 500ms 也能接受。所以我们需要一套“图形化+结构化”的工具，把模糊的需求变成精确的模型。这就是本章要讲的核心：用例图、活动图、状态机图、需求追溯矩阵。
我个人习惯，拿到一堆原始需求后，第一件事不是写文档，而是画图。画着画着，逻辑漏洞就自己冒出来了。
4.1 用例图：谁在用系统做什么
用例图是需求建模的起点。它回答两个问题：谁（角色）要做什么（功能）。
在智能座舱里，角色不只是“驾驶员”。还有乘客、手机 App、云端后台、甚至 OTA 升级服务器。每个角色都有自己关心的功能。
核心三要素
- 角色（Actor）：小人图标，代表与系统交互的人或外部系统
- 用例（Use Case）：椭圆，代表一个完整的功能单元
- 关系：连线，包括关联、包含（«include»）、扩展（«extend»）、泛化
举个例子。驾驶员要“设置导航目的地”，这个用例里可能包含“语音输入地址”和“手动输入地址”两个子流程。用 «include» 表示“一定会执行”，用 «extend» 表示“可选执行”。
我的经验：用例图不要画得太细。一个用例对应一个完整的用户目标，而不是一个点击动作。比如“调节音量”是一个操作，但“切换音源”才是一个用例。我在项目中见过有人把“按下音量+键”都画成一个用例，结果图比需求文档还长，评审会开了一下午没看完。
4.2 活动图：把流程跑一遍
用例图只说了“做什么”，没说“怎么做”。活动图就是用来描述流程的——谁先做、谁后做、遇到分支怎么走。
活动图有点像流程图，但更强调泳道（Swimlane）的概念。每个角色有自己的泳道，活动放在对应的泳道里，一眼就能看出职责边界。
我举个例子。用户通过语音说“我冷了”，座舱系统要执行一系列动作：
- 语音识别引擎把语音转成文本
- 自然语言理解模块解析意图（“调节温度”）
- 空调控制模块执行升温操作
- HMI 界面反馈“温度已调高 2 度”
这些活动分别属于不同的子系统。用活动图画出来，谁负责什么，接口在哪里，一目了然。
避坑指南：我曾经在一个项目中，活动图只画了“正常流程”，没画异常分支。结果开发上线后，语音识别超时了，系统直接卡死。后来我养成了一个习惯——每个活动图必须包含至少一个异常路径，比如“超时”、“识别失败”、“网络断开”。
4.3 状态机图：对象的一生
有些需求不是流程驱动的，而是状态驱动的。比如一个车门锁，它有“解锁”、“闭锁”、“儿童锁激活”等状态。用户的操作会让它在这些状态之间切换。
状态机图就是干这个的。它描述一个对象有哪些状态、什么事件触发状态变化、变化时做什么动作。
在智能座舱里，状态机图特别适合描述：
- 屏幕的显示模式（白天/夜晚/息屏）
- 空调的工作模式（制冷/制热/通风/自动）
- 驾驶模式（经济/舒适/运动/雪地）
- 语音助手的唤醒状态（休眠/唤醒/聆听/处理）
状态机图三要素
- 状态：圆角矩形，表示对象在某个时刻的稳定情况
- 转移：箭头，表示从一个状态到另一个状态
- 事件/条件：标注在箭头上，触发转移的原因
举个例子。语音助手的简单状态机：
初始状态: 休眠
事件: 用户说"你好，小驰" → 转移到: 唤醒
事件: 唤醒后等待 5 秒无语音 → 转移到: 休眠
事件: 用户说出指令 → 转移到: 处理
事件: 处理完成 → 转移到: 休眠
事件: 用户说"退出" → 转移到: 休眠你看，用文字描述也能说清楚，但画成状态机图，开发人员一眼就能看懂所有合法路径，不会漏掉边界情况。
我的习惯：状态机图一定要定义清楚“初始状态”和“非法状态”。比如车门在行驶中突然收到“解锁”指令，系统应该忽略还是报警？这些在状态机图里必须画出来。我见过一个项目，状态机图没画“行驶中禁止解锁”这个转移，结果测试阶段发现 bug，返工了两周。
4.4 需求追溯矩阵：让每条需求都有归宿
前面三种图都是“建模”工具，而 RTM 是“结构化”工具。它把需求、设计、代码、测试用例全部串起来，形成一条完整的追溯链。
说白了，RTM 就是一张大表。每一行是一条需求，每一列是一个阶段产物。比如：
| 需求 ID | 需求描述 | 用例图 | 活动图 | 状态机图 | 设计文档 | 测试用例 | 状态 |
|---|---|---|---|---|---|---|---|
| REQ-001 | 驾驶员可通过语音设置导航目的地 | UC-01 | AD-03 | — | DS-002 | TC-005~TC-008 | 已实现 |
| REQ-002 | 空调温度调节精度为 0.5°C | UC-04 | AD-07 | SM-02 | DS-005 | TC-012~TC-015 | 已实现 |
| REQ-003 | 行驶中禁止播放视频 | UC-06 | AD-09 | SM-04 | DS-008 | TC-020~TC-022 | 已实现 |
| REQ-004 | 语音助手支持粤语识别 | UC-02 | — | — | — | — | 未实现 |
这张表有什么用？
- 完整性检查：有没有需求没有对应的设计？有没有设计没有对应的测试？一眼就能看出来。
- 变更影响分析：如果 REQ-002 要修改，所有关联的用例图、活动图、状态机图、设计文档、测试用例都要同步更新。RTM 告诉你影响范围。
- 验收依据：测试通过后，在 RTM 里标记“已实现”，项目交付时拿着这张表逐条核对，谁也赖不掉。
避坑指南：我曾经见过一个团队，RTM 表建得漂漂亮亮，但没人维护。三个月后，需求改了 20 版，RTM 还是最初那一版。结果项目验收时，测试用例和需求对不上，吵了整整一周。我的建议是：RTM 必须和需求变更流程绑定——每次需求变更，必须同步更新 RTM，否则变更不生效。
4.5 四种工具如何配合使用
你可能会问：这四个工具，我到底该用哪个？
我的答案是：全都要。它们不是互斥的，而是互补的。
- 用例图：从用户视角定义功能边界。适合需求分析阶段，和产品经理、用户一起画。
- 活动图：描述跨角色的业务流程。适合系统设计阶段，明确各模块的交互顺序。
- 状态机图：描述单个对象的状态变化。适合详细设计阶段，给开发人员看。
- RTM：把前面三种图的结果和需求、设计、测试串起来。适合全生命周期管理。
我个人的工作流是这样的：拿到需求后，先画用例图确定范围；然后针对核心用例画活动图，把流程跑通；遇到状态敏感的功能，补充状态机图；最后把所有产出物登记到 RTM 里，持续维护。
下面这张图展示了它们之间的关系：
4.6 本章小结
需求建模与结构化，说白了就是把“人话”翻译成“工程语言”。用例图、活动图、状态机图是三种不同的翻译工具，RTM 是确保翻译结果不丢失的索引表。
我在项目中见过太多“需求文档写得很厚，但开发看不懂”的情况。其实只要花半天时间，把核心需求画成图，很多问题在画图过程中就暴露了。比如某个用例没有对应的活动图，某个状态转移缺少触发条件，某个需求在 RTM 里找不到对应的测试用例——这些坑，早发现早解决，比等到集成测试阶段再返工划算得多。
嗯，这一章的内容就到这里。记住：一张好图，胜过千言万语。