2. 需求建模实战

需求建模的第一步不是打开工具画图，而是把一段自然语言需求文本拆解成可建模的元素。Cameo Systems Modeler 中，需求以 Requirement 元素承载，需求之间的层次与关系则通过包含（Containment）、派生（Derive）、满足（Satisfy）、验证（Verify）等关系表达。本节以一个无人机续航需求为例，完整走通“文本→需求元素→需求层次→需求关系→需求表→追溯矩阵”的链路。

一、从需求文本中提取需求元素

假设原始需求文本如下：

REQ-UAV-001 无人机在标准载荷下应具备不少于 45 分钟的悬停续航能力。
REQ-UAV-002 电池组容量应不低于 12000 mAh。
REQ-UAV-003 整机空载重量应不超过 2.4 kg。
REQ-UAV-004 悬停续航测试应在 25℃、无风环境下进行，实测值不低于 45 分钟。

建模时，每条带编号的陈述对应一个 Requirement 元素。在 Cameo 中通过 Requirements 图或模型浏览器创建，关键属性包括 Id（如 REQ-UAV-001）、Text（需求正文）、Priority、Source、Risk 等。注意：Id 是需求追溯的锚点，必须唯一且稳定，不要用“需求1”这类无意义编号。

提取时容易犯的错误是把“约束条件”和“需求”混为一谈。REQ-UAV-004 中的“25℃、无风”是验证条件，应作为该需求的 Text 组成部分或独立的验证用例，而不是拆成一条独立需求。判断标准是：能否独立被满足或验证。能独立验证的才拆成独立需求。

二、构建需求层次

需求不是平铺的。REQ-UAV-001 是顶层续航需求，REQ-UAV-002 和 REQ-UAV-003 是支撑它的子需求——电池容量和重量共同决定续航。在 Cameo 中，用 Containment 关系（需求图中的嵌套或 contains 依赖）建立层次：REQ-UAV-001 包含 REQ-UAV-002 和 REQ-UAV-003。层次结构让“改一条需求影响哪些需求”变得可追踪。

层次构建的实操要点：在需求图中从父需求拖出 Containment 到子需求，或在模型浏览器中直接拖拽嵌套。Cameo 会自动在需求表视图中以缩进形式呈现层次。建议层次不超过三层，过深会导致追溯矩阵难以阅读。

三、建立需求关系：包含、派生、满足、验证

四类关系各有明确语义，不能混用：

  • 包含（Containment）：父需求与子需求的分解关系，表示“整体由部分组成”。REQ-UAV-001 包含 REQ-UAV-002。
  • 派生（Derive）：从上层需求推导出下层需求，方向是“源需求→派生需求”。例如从 REQ-UAV-001 派生出 REQ-UAV-004 作为验证需求。
  • 满足（Satisfy）：设计元素（如 Block 电池组）满足某条需求。方向是“设计元素→需求”。
  • 验证（Verify）：验证用例（TestCase）验证某条需求。方向是“验证用例→需求”。

在 Cameo 中，满足关系通过 Satisfy 依赖从 Block 指向 Requirement；验证关系通过 Verify 依赖从 TestCase 指向 Requirement。注意方向不要画反：需求是被满足、被验证的一方，箭头指向需求。

实操提示：在需求图中右键需求元素，选择 Related Elements 可快速查看该需求被哪些 Block 满足、被哪些 TestCase 验证，这是排查“孤儿需求”的高效方式。

四、需求表与追溯矩阵

需求表（Requirement Table）是需求的表格化视图，列可配置为 Id、Text、Priority、Satisfied By、Verified By。在 Cameo 中通过 Create Diagram → Requirement Table 生成，然后在列选择器中勾选需要的属性。需求表的价值在于批量检查：一眼看出哪些需求没有满足元素、哪些没有验证用例。

追溯矩阵（Traceability Matrix）则是需求与设计元素/验证用例的交叉表。行是需求，列是 Block 或 TestCase，交叉点有标记表示存在关系。Cameo 的 Traceability Matrix 支持自动生成，选择源元素类型和目标元素类型即可。矩阵适合做覆盖率统计：例如 4 条需求中，3 条有满足关系、2 条有验证关系，覆盖率一目了然。

无人机续航需求模型：层次与关系 需求层次（Containment） REQ-UAV-001 悬停续航 ≥ 45 min REQ-UAV-002 电池容量 ≥ 12000 mAh REQ-UAV-003 空载重量 ≤ 2.4 kg 包含 包含 派生（Derive） REQ-UAV-004 悬停续航测试条件与判据 派生 满足与验证关系 «Block» 电池组 BatteryPack «TestCase» 悬停续航测试 REQ-UAV-002 电池容量需求 REQ-UAV-001 续航需求 满足 验证 追溯矩阵（覆盖率检查） 需求 \ 元素 BatteryPack TestCase REQ-UAV-001 — ✓ REQ-UAV-002 ✓ —

五、实操闭环：从文本到可追溯模型

完整操作顺序如下：第一步，在 Requirements 包下创建 4 个 Requirement 元素，填入 Id 和 Text。第二步，在需求图中建立 REQ-UAV-001 对 REQ-UAV-002、REQ-UAV-003 的 Containment。第三步，从 REQ-UAV-001 拉出 Derive 到 REQ-UAV-004。第四步，创建 Block 电池组，用 Satisfy 指向 REQ-UAV-002。第五步，创建 TestCase 悬停续航测试，用 Verify 指向 REQ-UAV-001。第六步，生成需求表检查 Satisfied By 和 Verified By 列是否为空。第七步，生成追溯矩阵确认覆盖率。

结果判断依据：需求表中每条需求至少有一个满足元素或验证元素；追溯矩阵中 REQ-UAV-001 的验证列有标记、REQ-UAV-002 的满足列有标记。若某行全空，说明该需求是“孤儿需求”，需要补充设计或验证元素，或确认该需求是否应删除。

常见错误：把 Satisfy 箭头画成从需求指向 Block。Cameo 中满足关系的方向是设计元素→需求，画反会导致追溯矩阵无法正确统计覆盖率。验证关系同理，方向是 TestCase→Requirement。

需求表与追溯矩阵不是二选一，而是互补：需求表适合逐条编辑和检查属性，追溯矩阵适合全局看覆盖率和影响范围。实际项目中建议两者都生成，需求表用于日常维护，追溯矩阵用于评审和变更影响分析。

← 上一章 📖 返回目录 下一章 →