Q&A解析MBSE中的需求和场景数据模型

 

 

在《MBSE数据模型及交换（T/DISA 1101-2025）》标准发布后，不少同行对这套标准的内容和范围产生了好奇。本文以问与答的形式，结合杭州华望系统科技在参与“MBSE数据模型及交换咨询研究项目”中的思考，围绕标准中“需求和场景数据模型”部分所涉及的内容，回答几个最常被问到的问题。

 

Q1：这套标准解决什么问题？

 

当遇到需求写在 A 工具里、模型建在 B 工具里、仿真跑在 C 工具里这样的场景时，数据处于凌乱和散落的状态，需要一套标准把这些散乱的数据串联起来。简而言之，标准要做的就是：连点成线，把散落的数据构建成有逻辑关联的数据模型；串珠成链，让不同厂商的工具基于统一格式进行串联；应用成片，推动建成国内 MBSE 工具的生态圈。需要说明的是：一套标准在本质上不是某个具体项目的直接产物，而是对大量工程实践中产生的共性概念进行系统抽象地整梳理，最终达成各方的共识与平衡。它回答的不是“某个项目怎么做”的问题，而是“整个行业应该用什么样的共同语言进行交流”的关切。

 

Q2：为什么要把“需要（Need）”和“需求（Requirement）”两个概念分开？

 

在现实的项目场景中，“希望系统响应要快”——这是一条 Need，是利益相关方的期望，带着明显的主观感受。若直接把它写进需求文档中，则测试阶段必然遇到问题：“快”究竟意味着多少时间？因此，工程师要做的是进一步“概念精化”：

层级	内容示例
Need（需要）	“希望系统响应要快”——来自某业务主管的原始期望
Requirement（需求）	正常负载下，端到端时延 ≤ 500 毫秒
Requirement（需求）	峰值负载（并发≥1000）下，响应时间 ≤ 2 秒，无超时报错

显然，将一条Need 拆成两条有量化指标、有测试条件的 Requirement，带来的变化很实际：评审有了明确标准，争议时能反向追溯到出处，测试团队收到的不再是要猜测的文字。

 

Q3：标准中的14类实体、10类关系，是不是过度设计？

 

需求从来不是一条文字，而是一张结构化的网。传统采用Excel 进行管理时，一行一条需求，几百条以内的需求还能应付。但如果需求达到上千条并跨多个子系统时，某一条需求的变更将会引起什么样的影响就很难给出明确答案。标准用两类设计把这张网显式化：

• 14 类需求实体：以 Need 和 Requirement 为核心，加上利益相关方、需求来源、上下文、治理（版本基线、状态机）、评估依据等外围主体，覆盖需求从诞生到归档的全生命周期；
• 10 类关联关系：通过追溯、分配、分解、场景关联、验证关联等方式，将Need 和 Requirement构成相互关联的关系网。

图1  以”需求”为中心、以”场景”为贯穿载体的业务概念架构图

 

图2  需求相关核心概念与数据实体分类图

 

图3  需求-场景-验证追溯关系网

 

有了这张关系网，一条底层设计的需求发生变更时，影响域可以由数据结构自动计算获得——上层需求、关联场景、测试用例同步标识，不在需要人工凭记开展行排查。这 14类实体与10类关系正是对各种工程实践进行反复抽象和收敛后的公共子集。

 

Q4：场景为什么要分三层？

 

场景这个名词在不同角色的人看来是用例图或测试用例或操作剖面。标准给出了统一的三层分解之后，使得场景在数据层面具有了可操作性：

 

图4  场景三层分解的示意图

 

以舰船推进系统为例：

 

层级	示例	SysML 映射	回答的问题
Scenario（场景）	全速航行	用例	系统要做什么
Scene（情景）	主机从怠速切换到全速	状态机	在什么状态下运行
Situation（情态）	海况4级、35°C、燃油低压告警下的切换时序	活动图	具体发生了什么，参数是多少

 

需求里的“响应时间不超过5秒”，只有分解到Situation才有了边界条件、异常触发、时序参数，才能被真正仿真和检验。场景是把需求文字转换成可验证运行的实例。

 

图5  三层场景与 SysML 模型的映射关系

 

 

Q5：三层粒度如何确定？有没有典型的坑？

 

“层级混乱”是最常见的坑。例如，把 Situation 级的时序参数塞进 Scenario，一个场景被写成了几十页的文档；把 Situation级的需求细化到近乎测试脚本，和测试团队重复劳动。

在实践中，需求的层级划分原则是按以下的关系：

• Scenario 由系统架构师把控，对应需求条目；

• Scene 由系统工程师把控，对应运行模式划分；

• Situation 由仿真/测试工程师把控，对应仿真参数和测试用例。

对于需求的层级划分，一个有效的判断标准：换一个工程领域的人看不懂，说明划分太细；看完不知道系统该怎么运行，说明划分太粗。

 

Q6：XSD / JSON Schema 为什么被称为“数据契约”？

 

标准最终的落地形态是 Requirement.xsd 和 Scenario.xsd，它们规定着一条需求导出的文件长什么样、每个字段是什么、关联关系如何表达。

图6  统一的 XML 与 JSON 数据格式示例

该标准不属于任何一家工具厂商，遵守它的软件工具之间都能互通。标准预留了与主流格式的互操作路径：支持 ReqIF 导入、可用 SysML v2（KerML）精确定义语义、JSON Schema 可集成至 PLM 数据管理层，并通过枚举扩展机制允许企业扩展领域自有需求类型而不破坏互操作性。

图7  与 ReqIF、SysML v2、PLM 及 AI 扩展的互操作路径

 

 

Q7：企业执行该标准的路径是什么？

 

标准从建模、关联查询、生命周期管理、生态扩展四个维度给出了其落地的参考方案：

 

图8  系统工程场景下的四维度应用实践

 

 

建议循序渐进地按照以下五步进行：

◆ 建模：梳理企业现有的需求类型，与标准的元模型建立映射，先把核心的 Need 和 Requirement 创建起来，不必立刻一步到位；

◆ 关联：配置关联关系，建立双向追溯矩阵（RTM）——这是后续一切能力的基础；

◆ 场景化：为关键需求补齐三个层级的场景细节；

◆ 格式化：按 XSD / JSON Schema 格式导出交换文件，验证合规后打通工具链；

◆ 智能化：在积累了足够多的需求场景数据后，可引入 AI 开展需求冲突预警、场景覆盖度评估——这正是行业共同探索的未来发展方向。

 

Q8：标准落地的最大阻力是技术限制吗？

 

不是。技术问题（工具适配、格式转换）都可以用时间和工程手段解决。真正的落地阻力来自于组织层面：

• 数据治理责任：“需求从哪来、谁维护、谁审批”，这些概念在很多企业从未被正式定义，标准的制定将倒逼组织完成梳理。这项行动不难但花时间，也容易触碰到组织的边界；

• 习惯迁移：系统工程师已经习惯使用 Word/Excel，引入标准所带来的学习成本和心理阻力都真实存在。

因此，在标准落地的过程中不要强推全套执行，先从痛点切入（比如变更影响分析），让工程师感受到执行标准后产生的效率提升。技术障碍用工具解决，组织障碍用场景和价值说服。

 

结语

行业对“需求和场景应该如何被表达、关联、交换”进行系统性梳理而沉淀出来的共识，即：14类实体让需求可治理，三层级场景让需求可验证，数据契约让标准可流通。

MBSE 解决方案的落地靠的不是某一个软件工具，而是数据在工具之间自由、无损地流动。杭州华望系统科技将持续参与其他各类标准的制定及其工程验证，也欢迎有意共同推进标准制定的团队与我们探讨交流。

 

---

 

本文内容整理自 DISA 联盟工业软件大讲堂公开讲座《MBSE数据模型及交换》第6章：需求和场景数据模型（杭州华望系统科技有限公司，2026年5月19日）。配图根据标准数据模型绘制。