4、需求建模基础：UML用例图、UML活动图、UML状态机图、SysML需求图

说到需求建模，我脑子里第一个蹦出来的词就是「可视化」。你想想看，光靠文字描述需求，就像让一个厨师只看菜谱不看食材——能做出菜来才怪。建模就是把那些抽象的文字，变成大家都能看懂的图形。今天咱们就聊聊四种最常用的建模手段。

4.1 UML用例图：谁在用系统做什么

用例图是我个人最常用的需求分析工具。它解决一个核心问题：谁（角色）要干什么（功能）。说白了，就是画清楚系统边界和交互关系。

举个例子。我在做车载信息娱乐系统时，画过一个「音乐播放」的用例图。参与者有「驾驶员」和「乘客」。用例包括「播放歌曲」「切换曲目」「创建播放列表」等。这里有个坑——用例粒度要适中。太粗了看不清细节，太细了图就变成蜘蛛网。

用例图里有个容易混淆的概念：包含（include）和扩展（extend）。包含是「必须做的」，扩展是「可选做的」。比如「播放歌曲」必须包含「加载音频文件」，但可以扩展「显示歌词」。嗯，这个区别很重要，搞反了会导致需求遗漏。

4.2 UML活动图：流程怎么走

活动图，说白了就是流程图。它描述的是业务逻辑或工作流。我习惯用它来梳理复杂的功能流程，特别是那些涉及多个角色、多个分支的场景。

活动图的基本元素包括：

• 起始节点：实心圆，流程开始的地方
• 活动节点：圆角矩形，表示一个动作或步骤
• 决策节点：菱形，表示条件分支
• 合并/分叉：粗横线，表示并行或同步
• 结束节点：实心圆加外圈，流程结束

我记得有一次做ADAS（高级驾驶辅助系统）的需求分析。功能是「自动紧急制动」。这个流程涉及传感器检测、决策判断、执行制动等多个步骤，而且还有各种条件分支——比如车速、障碍物距离、驾驶员是否干预。用活动图一画，整个逻辑就清晰了。

活动图还有一个妙用：发现遗漏的需求。当你把流程一步步画出来时，那些「如果这样怎么办」的场景就会自然浮现。比如「如果传感器故障怎么办？」——嗯，这就是一个异常处理需求。

4.3 UML状态机图：对象的状态变化

状态机图，关注的是单个对象在其生命周期中的状态变化。你想想看，一个车机系统里的「蓝牙连接」功能，它有哪些状态？断开、连接中、已连接、配对中、配对失败……每个状态之间怎么跳转？这就是状态机图要解决的问题。

状态机图的核心元素：

• 状态（State）：圆角矩形，表示对象的一个稳定状态
• 转移（Transition）：箭头，表示状态之间的跳转
• 事件（Event）：触发转移的条件
• 动作（Action）：转移时执行的操作

我个人建议：状态机图不要画得太复杂。如果一个对象有超过10个状态，或者转移线交叉得像蜘蛛网，那就说明这个对象需要拆分了。我曾经接手过一个项目，一个状态机图有30多个状态，结果没人能看懂，最后重构了。

4.4 SysML需求图：需求的结构化表达

SysML需求图，是系统工程领域专门用来管理需求关系的图。它不像UML那三种图那么「动态」，它更关注需求本身的结构——谁派生谁、谁满足谁、谁验证谁。

需求图的核心元素：

• 需求节点：矩形，包含需求ID、文本描述
• 关系：
  • 派生（derive）：一个需求从另一个需求衍生出来
  • 满足（satisfy）：某个设计元素满足某个需求
  • 验证（verify）：某个测试用例验证某个需求
  • 细化（refine）：对需求的进一步解释

为什么需要需求图？我举个例子。你写了一份需求文档，里面有100条需求。开发说「我实现了第35条」，测试说「我验证了第35条」。但你怎么知道第35条是从哪条顶层需求来的？怎么知道它和别的需求有没有冲突？需求图就是干这个的。

SysML需求图有个好处：它让需求可追溯。你想想看，如果客户问「为什么这个功能要这么做？」你可以顺着需求图一路追溯到顶层需求。我曾经用这个图说服了客户放弃一个不合理的需求——因为那个需求无法追溯到任何顶层目标。

4.5 四种图的对比与选择

说了这么多，你可能想问：到底什么时候用哪种图？我整理了一个对比表，方便你参考。

图类型	关注点	适用场景	输出物
用例图	系统边界、角色与功能	需求获取阶段，明确功能范围	功能列表、角色定义
活动图	业务流程、工作流	复杂流程梳理、异常路径分析	业务流程图、操作手册
状态机图	对象状态、事件驱动	有明确状态转换的功能（如通信协议、模式切换）	状态表、事件列表
需求图	需求结构、追溯关系	大型项目、功能安全、合规性需求管理	需求追溯矩阵、影响分析报告

我个人习惯是：先用例图定范围，再活动图画流程，状态机图补细节，需求图管结构。当然，这不是死规矩。你完全可以根据项目特点灵活组合。