1. 课程导入与全景认知
在复杂系统研发中，需求从来不是一张静态清单，而是一条贯穿全生命周期的信息链。MBSE（基于模型的系统工程）把这条链从文档搬到模型里，用可追溯、可验证、可变更的方式管理需求。本课程要解决的核心问题只有一个：如何让每一条利益相关者需求，都能沿着模型逐层分解，最终落到可验证的系统元素上，并形成闭环。
一、什么是需求分解与追踪闭环
需求分解，是把高层的、面向用户的目标，逐层转化为系统级、子系统级、组件级可实现的规格。追踪闭环，则是让这条分解链上的每一环都保留双向链接：向上能回答“这条设计为什么存在”，向下能回答“这条需求由谁实现、如何验证”。
在MBSE中，这种关系不是靠文档编号手工维护，而是通过模型元素之间的显式关系（如«deriveReqt»、«satisfy»、«verify»、«trace»）表达。需求、架构、测试用例都是模型中的一等公民，工具可以自动生成追溯矩阵、影响分析报告和覆盖率统计。
二、为什么需要闭环：价值与代价
没有闭环的研发，典型症状是：需求变更后不知道影响哪些模块；测试通过了却说不清覆盖了哪条需求；评审时靠人工翻文档核对，遗漏率高。闭环带来的直接价值有三点：
- 变更可控：修改一条需求，工具立即列出受影响的设计元素和测试用例，评估工作量与风险。
- 验证可证：每条需求都有对应的验证方法（分析、检查、演示、测试）和验证结果，覆盖率可量化。
- 沟通可信：利益相关者、系统工程师、软硬件开发者、测试人员共享同一模型视图，减少语义歧义。
代价同样真实：建模初期投入增加，需要定义关系语义和命名规范；工具链需要支持模型查询与报告生成；团队要改变“先写文档再补追溯”的习惯。这些投入在系统复杂度上升后会被显著摊薄。
三、端到端流程概览
从利益相关者需求到系统验证，MBSE需求闭环通常经过以下阶段。注意，这不是线性瀑布，而是带反馈的迭代过程：
- 利益相关者需求捕获：识别干系人，收集期望、约束、场景，形成Stakeholder Requirements。
- 系统需求定义：将利益相关者需求转化为系统级功能与非功能需求，明确边界和接口。
- 需求分解与分配：按架构层级分解，分配到子系统、组件，建立«deriveReqt»和«satisfy»关系。
- 设计与实现：在架构模型中落实需求，产生设计参数和实现约束。
- 验证与确认：为每条需求定义验证方法，建立测试用例，执行并记录结果。
- 追溯与影响分析：维护双向追溯，变更时执行影响分析，更新模型和验证状态。
下面这张图展示了从利益相关者需求到系统验证的端到端信息流，以及各阶段之间的追溯关系。图中同时标出了闭环反馈路径：验证结果反向确认需求，变更请求触发影响分析并回流到分解环节。
四、核心挑战与应对思路
实际项目中，闭环难以落地通常不是因为工具不支持，而是因为语义和纪律问题。常见挑战包括：
- 关系语义混乱：把«trace»当万能关系，导致追溯矩阵无法区分“派生”“满足”“验证”。应对：在项目早期定义关系使用规范，明确每种关系的方向和含义。
- 粒度失控：需求分解过细导致模型爆炸，过粗则无法验证。应对：以“可独立验证”为分解粒度判据，每条需求至少对应一种验证方法。
- 变更不同步：需求改了，设计和测试没跟上。应对：把影响分析嵌入变更流程，模型变更后自动生成待办清单。
- 验证覆盖不透明：说不清哪些需求已验证、哪些没有。应对：用覆盖率指标（如需求验证覆盖率=已验证需求数/总需求数）持续监控。
五、本课程的学习路径
后续章节将沿着这条端到端链路展开：先讲需求捕获与建模语言基础，再讲分解策略与架构分配，然后进入验证用例设计与追溯矩阵构建，最后讨论变更管理、工具链集成和度量指标。每一章都会给出可操作的模型片段、参数示例和判断依据，帮助你把闭环从概念变成日常工程实践。
在开始之前，请记住一个判断标准：如果一条需求无法回答“它从哪来、由谁实现、怎么验证”这三个问题，它就还没有进入闭环。本课程的目标，就是让每一条需求都能回答这三个问题。