遥感卫星 MBSE 需求分解与变更影响分析
01
项目背景
遥感卫星设计需要载荷、平台及数据处理等专业协同。任务书中的成像、资源和接口约束分散在不同文档中，需求变化后容易出现同一参数多处维护、修改通知不到位和评审版本不一致。
本方法案例聚焦卫星系统的设计组织与需求变更管理，围绕实施规划、模型基线和验证关系，建立可复核的变更分析流程。
02
领域建模与技术路线
先统一卫星、载荷、接口、需求和参数等领域概念，再以 SysML 组织需求、结构、行为与约束。领域扩展只表达明确业务含义，不改变基础模型语言语义；可复用的功能与接口单元进入受控模型库。
总体需求分配给功能，功能再分配到子系统；指标之间保留来源、分解关系与假设。变更分析沿已建立的关系查找候选影响对象，设置待复核标记，避免把关系覆盖不足误当作没有影响。
03
实施过程与变更闭环
实施从一条载荷业务链开始，确认输入任务、功能分解、平台支持和输出数据，再扩展到相关专业。以统一命名、模型包和关系规则控制建模颗粒度，使不同人员创建的模型能够在同一层级上评审。
选择一项需求变化做闭环演练：登记变更原因，生成影响候选清单，逐项确认设计与验证动作，再更新模型和报告。基线发布前核查待复核项是否关闭，未决项保留责任人与后续处理条件。
04
交付内容与验收
交付可包括领域词汇与扩展规则、总体到分系统的追溯模型、模型库条目、变更评审记录及报告模板。报告中的参数和关系应来自指定版本，不能把不同方案的数据混在一份评审材料中。
验收选取一条需求、一项接口和一次变更，检查可否定位上下游关系、生成对应清单、解释人工复核结果。对没有计算或试验支撑的性能属性，标明依据缺口，不以模型图完整替代指标达成。
05
适用边界
适合多个专业共享系统需求、需要频繁进行方案评审的研发团队。若输入任务本身不稳定，应先建立假设与变更规则，再扩展模型规模，避免一次性绘制过大且难维护的系统图。
本方法案例聚焦卫星需求变更与模型追溯。接入专业仿真和试验数据时，应明确工具版本、接口语义、访问权限及各项验证责任。
06
实施效果
可预期的作用是减少跨文档重复维护，让评审围绕同一模型基线进行，并使需求变更的处理范围更清楚。收益来自关系与责任可追溯，而不是单纯把文档改成图。
建议记录变更影响分析耗时、漏通知项数量和报告与模型不一致项，采用相近复杂度的变更进行比较。现有依据主要展示策划与方法，不足以给出已实现的效率增幅。