3. 利益相关者需求捕获
在MBSE项目中，需求分解与追踪闭环能否真正闭合，起点并不在建模工具里，而在“人”身上。利益相关者需求捕获要解决三个连续问题：找对人、问对事、把回答变成可追踪的结构化条目。如果这一步只留下会议纪要和零散邮件，后续的系统需求、架构分配和验证用例就会失去源头，追踪链在起点处断裂。
一、识别利益相关者：先画边界，再列角色
利益相关者不是“所有关心项目的人”，而是对系统需求有实质影响或受系统实质影响的角色。识别时建议从三个维度展开：生命周期维度（概念、开发、制造、部署、运行、维护、退役）、接口维度（与系统直接交互的操作者、维护者、相邻系统）、约束维度（法规、安全、认证、采购、财务）。
以“无人机物流配送系统”为例，可识别出：运营调度员、现场装卸员、空域监管机构、电池维护人员、收货客户、保险方、相邻空管系统。每个角色要记录其关注点、影响力和验收话语权。例如空域监管机构关注飞行高度与禁飞区合规，属于“高影响、低频率”角色；现场装卸员关注单次装载时间与误操作防护，属于“高频、直接操作”角色。识别结果应形成一张利益相关者清单，字段至少包括：角色名称、类别、关注点、影响程度、需求来源渠道、接口对象。
二、elicitation 技术：访谈、工作坊、观察的配合使用
需求获取（elicitation）不是“收集已有需求”，而是通过结构化互动把隐性期望显性化。三种常用技术各有适用面：
- 访谈：适合深挖单个角色的动机、约束和例外场景。建议采用半结构化访谈，先问目标与痛点，再问输入输出和异常处理。例如问调度员：“当同时有5个订单且两架无人机可用时，你如何决定派单顺序？”这类问题能引出优先级规则和冲突处理需求。
- 工作坊：适合多角色对齐、解决冲突和快速形成共识。典型形式是场景走查：把“下单—调度—装载—飞行—交付—异常返航”画成时间线，让各角色在节点上标注期望、担忧和接口。工作坊产出的是跨角色共识，而不是某一个人的意见。
- 观察：适合发现“说的”和“做的”不一致的隐性需求。到现场看装卸员实际操作，可能发现他们习惯用单手扶住箱体、另一只手扫码，这直接导出“扫码模块应支持单手操作或免手持触发”的需求。
实际项目中，三者通常组合使用：先访谈关键角色形成初步议题，再用工作坊对齐冲突，最后用观察验证操作类需求。每次获取活动都要留下可追溯的记录，包括时间、参与角色、原始陈述和待确认问题。
三、从原始陈述到结构化需求条目
原始陈述往往是口语化、模糊甚至矛盾的，例如“无人机最好别在人多的地方掉下来”。结构化就是把它转成可验证、可追踪、单一含义的条目。推荐使用以下转换规则：
- 识别需求类型：功能需求、性能需求、接口需求、约束需求、质量属性需求。
- 补全主体与条件：谁在什么条件下、对什么对象、执行什么动作、达到什么结果。
- 量化判据：把“快”“安全”“可靠”换成可测量的阈值或判定条件。
- 拆分复合句：一条需求只表达一个可独立验证的意图。
- 标注来源与理由：关联到具体利益相关者和获取活动，保留原始陈述作为依据。
例如原始陈述“配送要快，客户等太久会投诉”，可转化为：当订单生成且无人机可用时，系统应在10分钟内完成从接单到起飞的全部准备，并将预计到达时间推送给客户。 其中“10分钟”是示例阈值，实际项目需与运营方确认。再如“别在人多的地方掉下来”，可转化为：当检测到下方人员密度超过设定阈值时，无人机应自动爬升至安全高度或改航至备降点，且不得在人员密集区上方执行迫降。
四、建立初始需求库：字段、编号与追踪起点
结构化条目要进入初始需求库，才能被后续系统需求、架构和验证用例引用。需求库的最小可用字段建议包括：需求编号、需求名称、需求描述、类型、来源利益相关者、来源活动、优先级、验收判据、状态、版本。编号建议采用“项目-类别-序号”形式，如UAV-STK-001表示无人机项目利益相关者需求第1条。
需求库不是静态文档，而是追踪链的起点。每条利益相关者需求都应能被后续系统需求引用，并在验证阶段找到对应的验证方法。下面这张图展示了从利益相关者识别到初始需求库建立的完整关系：左侧是角色与获取活动，中间是原始陈述到结构化条目的转换，右侧是需求库字段与追踪起点。
建立初始需求库时，要特别注意两点。第一，不要过早合并或删减。来自不同角色的相似需求可能带有不同约束，例如调度员要“快”，监管方要“合规”，两者可能冲突，但冲突本身是后续权衡的输入，不应在捕获阶段被抹平。第二，每条需求都要有来源。没有来源的需求无法在变更时判断影响范围，也无法在验证失败时回溯到原始期望。
完成初始需求库后，下一步才是把利益相关者需求分解为系统需求，并建立双向追踪。但在此之前，请确认需求库已经具备可追踪的起点：角色清晰、来源可查、条目可验证、编号唯一。这四点决定了后续需求分解与追踪闭环能否真正闭合。