2. 需求驱动的功能行为建模起点

在SysML功能行为联合建模中，需求不是一张静态的清单，而是驱动整个功能行为模型演化的源头。本节要解决的核心问题是：如何把自然语言描述的需求，转化为可追溯、可验证、可驱动功能行为建模的结构化起点。这个起点由两类图共同承担——需求图（Requirement Diagram）负责表达需求本身及其追溯关系，用例图（Use Case Diagram）负责表达系统对外呈现的功能行为边界。两者配合，才能把“要做什么”与“谁在什么场景下触发它”连接起来。

需求图：把需求变成可追溯的模型元素

SysML需求图的核心价值在于，它把一条条需求从文档段落提升为具有标识、属性和关系的模型元素。一个典型的需求元素包含标识符（如REQ-ACC-001）、需求文本、优先级、验证方法（inspection/analysis/test/demonstration）以及来源。这些属性不是装饰，而是后续验证与变更影响分析的依据。

需求图真正强大的地方是它的关系类型。SysML定义了多种需求关系，其中在功能行为建模起点阶段最常用的是以下几种：

• 包含（containment）：把高层需求分解为子需求，形成需求层级。例如“整车制动功能”可分解为“常规制动”“紧急制动”“驻车制动”三条子需求。
• 派生（derive）：表示一条需求由另一条需求推导而来，通常伴随设计决策。派生关系是需求向功能行为模型映射的关键桥梁。
• 满足（satisfy）：由设计元素（如活动、状态机、模块）声明其满足某条需求。这是功能行为模型与需求建立追溯的核心关系。
• 验证（verify）：由测试用例或验证活动声明其验证某条需求，与验证方法属性配合使用。
• 细化（refine）：表示某元素对需求做进一步说明，常用于把模糊需求细化为可建模的约束。

需要特别强调的是，满足关系是功能行为模型与需求之间的正式追溯纽带。当我们在后续章节中建立活动图、状态机或序列图时，每个行为元素都应通过满足关系挂接到至少一条需求上，否则该行为就缺乏存在依据。

功能需求与行为需求的区分

很多建模项目在起点阶段就埋下隐患，原因是没有区分功能需求与行为需求。这两类需求在SysML中对应不同的建模路径，混淆会导致追溯断裂。

功能需求描述系统“做什么”，即系统对外提供的功能或服务。它通常可以用“系统应能……”的句式表达，关注的是功能的存在性与完整性。例如：“系统应能根据驾驶员踩下制动踏板的深度，输出对应的制动力。”功能需求主要映射到用例、活动或功能结构。

行为需求描述系统“如何随时间响应”，即系统在特定事件、条件或时间约束下的行为序列、状态迁移和响应时序。它关注的是动态顺序与条件。例如：“当车速高于30 km/h且制动踏板被踩下时，系统应在200 ms内进入制动助力状态。”行为需求主要映射到状态机、序列图和活动图中的控制流。

区分二者的实用判据是：如果一条需求可以用“输入—处理—输出”的功能分解来满足，它偏向功能需求；如果一条需求必须用“事件—条件—动作—状态”的时序逻辑来满足，它偏向行为需求。实际项目中，一条需求往往同时含有功能与行为成分，此时应拆分为两条需求，分别挂接不同的建模元素，避免一条需求被多个异构元素“部分满足”而无法验证。

用例图：功能行为的对外边界

用例图在SysML中用于表达系统与外部参与者之间的功能交互。它不描述内部实现，而是划定系统功能行为的边界。用例图的三个核心元素是：参与者（Actor）、用例（Use Case）以及它们之间的关联、包含、扩展和泛化关系。

在需求驱动的建模起点上，用例图承担两个具体任务。第一，把功能需求按参与者视角组织成用例，每个用例对应一组相关的功能需求。第二，通过用例的场景描述，为行为需求提供触发条件和主成功场景，从而为后续序列图和状态机提供输入。

例如，针对“制动控制”功能需求，可以识别出参与者“驾驶员”和“车辆传感器”，用例包括“请求常规制动”“请求紧急制动”“监测轮速”。其中“请求紧急制动”用例可进一步通过扩展关系挂接“ABS介入”场景，这个场景正是行为需求的来源。

从需求到功能行为模型的映射方法

映射不是一步完成的，而是一个有明确中间产物的过程。下面给出一个可操作的映射路径，并以简化的制动控制示例贯穿说明。

第一步：需求分类与编号。把收集到的需求逐条标注为功能需求（F）或行为需求（B），并赋予唯一标识。示例：F-001“系统应能输出与踏板深度成比例的制动力”；B-001“当车速大于30 km/h且踏板深度大于20%时，系统应在200 ms内进入助力状态”。

第二步：功能需求映射到用例与活动。每条功能需求至少映射到一个用例；用例内部的主成功场景进一步分解为活动图中的动作节点。F-001映射到用例“请求常规制动”，其主场景分解为“采集踏板深度→计算目标制动力→输出制动指令”三个动作。

第三步：行为需求映射到状态机与序列图。每条行为需求映射到状态机中的迁移或序列图中的消息时序。B-001映射到状态机中“待命→助力”的迁移，迁移的触发事件为踏板深度大于20%，守卫条件为车速大于30 km/h，迁移动作中标注200 ms的时间约束。

第四步：建立满足关系并检查覆盖。在需求图中，用满足关系把活动、状态机、序列图等行为元素连接到对应需求。然后做覆盖检查：是否存在没有任何行为元素满足的需求？是否存在没有任何需求依据的行为元素？前者说明建模遗漏，后者说明范围蔓延。

第五步：用验证关系闭环。为每条需求指定验证方法，并用验证关系连接到测试用例或验证活动。功能需求F-001可用测试验证，行为需求B-001可用分析或测试验证，时间约束200 ms需要明确测量点与容差。

追溯关系与覆盖检查

追溯关系不是建模完成后的“补录”，而应在建模过程中同步建立。推荐的做法是：每新增一个行为元素，立即在需求图中建立满足关系；每新增一条需求，立即检查是否有对应的用例或行为元素。覆盖检查可以按以下三个问题逐条核对：

1. 每条功能需求是否至少映射到一个用例？
2. 每条行为需求是否至少映射到一个状态迁移或消息时序？
3. 每个行为元素是否至少满足一条需求？

如果第1或第2个问题出现“否”，说明需求尚未落地，需要补充用例或行为建模；如果第3个问题出现“否”，说明存在无需求依据的行为，需要确认是范围蔓延还是需求遗漏。这个检查在项目早期执行成本最低，越往后修复代价越高。

一个可复用的映射检查表

下表给出从需求到功能行为模型的映射检查表，可直接用于建模评审。表中“示例”列以本节制动控制案例填写，实际使用时替换为项目自身内容。