4. 需求工程与需求建模实战

在MBSE面试中，需求工程几乎是必考区。面试官不会只问你“需求重要不重要”，而是会追问：需求从哪里来、怎么分解、怎么追溯、怎么验证、变更后怎么评估影响，以及需求图和需求表到底该选哪个。这一章我们就把这条链路走通，让你在面试中能讲出可执行的方法，而不是停留在概念层面。

一、需求捕获：从利益相关者到可建模需求

需求捕获不是“把用户说的话记下来”，而是把模糊期望转化为可验证的工程陈述。实际项目中，输入通常来自利益相关者访谈、运营场景、法规标准、接口协议、历史故障报告和竞品分析。以无人机巡检系统为例，客户说“希望续航长一点”，这不是需求，而是期望。我们需要通过场景化提问把它转化为：“在搭载双光吊舱、风速不大于5m/s、环境温度25℃的条件下，单次任务续航时间不小于45分钟。”这条陈述包含了条件、对象、指标和约束，才具备可验证性。

捕获阶段建议做三件事：第一，建立利益相关者清单，标注其关注点与优先级；第二，用用例或场景描述运行流程，识别功能需求与非功能需求；第三，为每条需求分配唯一标识和来源，避免后续追溯断链。面试中如果被问到“你怎么保证需求不遗漏”，可以回答：用场景覆盖矩阵检查每个运行场景是否都有对应需求，用接口清单检查外部交互是否都有需求承接。

二、需求分解：从系统级到可分配层级

需求分解的核心是“分配”而非“复制”。系统级需求描述整体能力，分解后要落到子系统、组件或软件配置项。以巡检无人机为例，系统级需求“续航不小于45分钟”可分解为：电池能量密度不低于某阈值、整机功耗不高于某值、气动效率满足巡航升阻比要求。每条子需求都要能反向支撑父需求，并且有明确的验证方法。

分解时容易犯两个错误：一是把设计约束当需求，比如“必须用某型号电机”；二是分解粒度过细，直接跳到零件参数。合理的做法是保持“需求-设计”分离：需求说“做什么”，设计说“怎么做”。面试中可强调：分解后的每条需求都应满足“独立可验证、无歧义、可追溯、有边界”。

三、需求追溯：正向、反向与双向链路

追溯是MBSE区别于文档工程的关键。正向追溯从利益相关者需求到系统需求、子系统需求、设计元素、测试用例；反向追溯从测试结果回到需求来源。实际建模中，常用追溯关系包括：derive（派生）、satisfy（满足）、verify（验证）、refine（细化）。

以“续航不小于45分钟”为例，正向链路是：利益相关者需求→系统需求→电池需求→电池选型→续航测试用例。反向链路是：续航测试失败→定位到电池需求→检查系统需求→确认利益相关者期望。面试中如果问“追溯有什么用”，可以答：变更影响分析、覆盖度检查、验证充分性判断、审计合规。没有追溯，需求变更就是一场灾难。

四、需求验证：方法、判据与闭环

需求验证不是“测一下”，而是确认需求本身正确、完整、一致、可验证。验证方法包括：检查（inspection）、分析（analysis）、演示（demonstration）、测试（test）。每条需求在捕获时就要确定验证方法。例如“续航不小于45分钟”适合用测试；“符合某适航条款”适合用检查或分析。

验证闭环的关键是：需求→验证用例→执行结果→覆盖状态。面试中可举例：某需求有验证用例但未执行，覆盖状态为“未验证”；执行后结果超差，状态为“失败”，需触发变更或设计调整。只有全部需求达到“通过”或“可接受”状态，才能认为验证完成。

五、需求变更影响分析：从变更请求到影响清单

变更影响分析是面试高频题。实际流程是：收到变更请求→识别受影响需求→沿追溯链路找下游设计、测试、接口→评估工作量、风险、成本→给出决策建议。以“续航从45分钟提升到60分钟”为例，影响可能包括：电池能量需求增加、整机重量增加、结构强度需复核、续航测试用例需更新、适航验证项目可能增加。

面试中要强调：变更影响分析不是拍脑袋，而是基于追溯链路和覆盖矩阵。可以给出一个简化判断依据：如果变更影响超过3个子系统或涉及安全关键需求，必须走正式变更评审；如果仅影响文档描述且不改变验证结果，可走快速通道。

六、需求图与需求表的选择

需求图和需求表不是二选一，而是互补。需求图适合表达关系：追溯、派生、满足、验证、包含。需求表适合表达属性：标识、文本、来源、优先级、验证方法、状态、版本。实际建模中，常用需求图展示需求层次和追溯链路，用需求表管理需求属性和覆盖状态。

选择依据可以归纳为：看关系用图，看属性用表；看全局用图，看细节用表；看变更影响用图，看验证覆盖用表。面试中如果问“你更倾向哪个”，可以答：两者结合，图用于沟通和影响分析，表用于管理和验证闭环。

七、可直接使用的需求追溯与验证矩阵示例

下面给出一份简化但可填写的需求追溯与验证矩阵，适用于面试中展示你的工程化思维。字段包括需求标识、需求描述、来源、父需求、验证方法、验证用例、当前状态、变更影响标记。

需求标识	需求描述	来源	父需求	验证方法	验证用例	状态	变更影响
REQ-SYS-001	搭载双光吊舱、风速≤5m/s、25℃时，续航≥45min	客户期望	—	测试	TC-END-001	已通过	高
REQ-SUB-001	电池可用能量≥某阈值	REQ-SYS-001派生	REQ-SYS-001	分析	AN-BAT-001	已通过	高
REQ-SUB-002	巡航功耗≤某值	REQ-SYS-001派生	REQ-SYS-001	测试	TC-PWR-001	未执行	中
REQ-IF-001	吊舱供电接口电压范围符合协议	接口协议	—	检查	IN-IF-001	已通过	低

使用说明：状态列可填“未验证、已通过、失败、可接受”；变更影响列可填“高、中、低”，高表示涉及安全关键或跨3个以上子系统。面试中你可以说：这张表就是需求验证闭环的最小管理单元，图用来展示链路，表用来跟踪状态。

八、面试应答要点

当面试官问“你怎么做需求工程”时，不要只背流程。可以按“捕获→分解→追溯→验证→变更”讲一条完整链路，并给出一个具体例子。当问“需求和设计怎么区分”时，强调需求说做什么，设计说怎么做。当问“变更影响怎么分析”时，强调基于追溯链路和覆盖矩阵，而不是凭经验。当问“图和表怎么选”时，强调图看关系、表看属性，两者结合。

最后提醒：MBSE面试中，需求工程不是考你背术语，而是考你能否把模糊期望变成可验证、可追溯、可管理的工程对象。把这一章的链路走通，你就能在面试中展现出真正的系统工程思维。