在《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由仿真/测试工程师把控对应仿真参数和测试用例。对于需求的层级划分一个有效的判断标准换一个工程领域的人看不懂说明划分太细看完不知道系统该怎么运行说明划分太粗。Q6XSD / JSON Schema 为什么被称为“数据契约”标准最终的落地形态是 Requirement.xsd 和 Scenario.xsd它们规定着一条需求导出的文件长什么样、每个字段是什么、关联关系如何表达。图6 统一的 XML 与 JSON 数据格式示例该标准不属于任何一家工具厂商遵守它的软件工具之间都能互通。标准预留了与主流格式的互操作路径支持 ReqIF 导入、可用 SysML v2KerML精确定义语义、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日。配图根据标准数据模型绘制。- END-*本文为原创最终解释权归杭州华望系统科技所有。未经授权严禁复制或转载。*关注【杭州华望MBSE】将推送更多精彩有趣的文章期待与你同行 QA解析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由仿真/测试工程师把控对应仿真参数和测试用例。对于需求的层级划分一个有效的判断标准换一个工程领域的人看不懂说明划分太细看完不知道系统该怎么运行说明划分太粗。Q6XSD / JSON Schema 为什么被称为“数据契约”标准最终的落地形态是 Requirement.xsd 和 Scenario.xsd它们规定着一条需求导出的文件长什么样、每个字段是什么、关联关系如何表达。图6 统一的 XML 与 JSON 数据格式示例该标准不属于任何一家工具厂商遵守它的软件工具之间都能互通。标准预留了与主流格式的互操作路径支持 ReqIF 导入、可用 SysML v2KerML精确定义语义、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日。配图根据标准数据模型绘制。- END-*本文为原创最终解释权归杭州华望系统科技所有。未经授权严禁复制或转载。*关注【杭州华望MBSE】将推送更多精彩有趣的文章期待与你同行