2. 航天任务需求来源与利益相关方分析

航天任务需求分析的第一步，不是急着写指标，而是把“谁在提要求、要求从哪里来、谁有权拍板”这三件事弄清楚。一个典型的对地观测或通信卫星任务，需求往往同时来自任务发起方、最终用户、载荷研制方、平台研制方、测控与运控系统，以及发射、测控站网、地面数据接收与处理等外部支持单位。这些角色对同一颗星的关注点差异极大：用户关心重访周期与图像质量，载荷方关心口径、谱段与定标精度，平台方关心质量、功耗与姿态稳定度，测控与运控方关心可见弧段、遥测帧格式与指令时延。若不在早期识别清楚，后期指标冲突会以“设计反复”的形式集中爆发。

角色识别：从“谁受益”到“谁负责”

角色识别建议分两层做。第一层是受益与提出层，包括任务发起方（如国家主管部门、行业用户、商业公司）和最终用户（如测绘、农业、应急、通信运营商）。他们提出的是任务级需求，通常以任务目标、覆盖区域、时效性、服务寿命等形式出现。第二层是实现与保障层，包括载荷方、平台方、测控方、运控方、发射方和地面数据系统。他们提出的是约束级与接口级需求，例如载荷质量包络、平台供电能力、测控频段与调制方式、数传码速率、指令响应时间等。

识别时可用一张“角色—关注点—需求类型”对照表来梳理，避免遗漏。例如某遥感任务中，应急管理部门作为用户提出“灾害发生后 6 小时内获取影像”，这属于任务级时效需求；载荷方据此提出“幅宽不小于 60 km、地面分辨率优于 2 m”，属于载荷级指标；平台方则需评估“是否具备 6 小时内侧摆成像与数传能力”，属于平台与运控约束。三者之间是逐层传递、相互制约的关系，而不是彼此独立。

需求获取渠道：正式与非正式并行

需求获取不能只靠一份任务书。常见渠道包括：任务书与研制总要求、用户需求调研会、载荷与平台接口协调会、测控与运控系统对接会、历史型号数据复用、仿真推演与专家评审。其中，任务书给出的是顶层目标，而接口协调会往往才能暴露出真正的约束细节，例如测控站可见弧段不足、数传窗口与成像窗口冲突等。

实际操作中，建议把获取到的需求按“来源—原始表述—初步归类—待确认项”记录。例如用户说“要看得清”，不能直接写成“分辨率优于 1 m”，而应追问：目标尺寸、识别等级、光照条件、是否允许侧摆。只有把模糊表述转化为可验证的参数，需求才具备向下分解的基础。

冲突与优先级初步处理

利益相关方需求冲突是常态。典型冲突包括：用户要求高分辨率与宽幅宽，但载荷质量与平台功耗受限；运控方要求指令简单可靠，但载荷方希望灵活调整工作模式；测控方希望减少测控弧段，但用户要求快速响应。处理冲突不能简单“谁大听谁”，而应建立初步的优先级判据：任务成功准则、安全性、法规与频轨约束、用户时效、成本与进度、技术可实现性。

一个实用的做法是采用“必须—应该—最好”三级分类。必须项是不可妥协的底线，如轨道高度、频段合规、测控安全；应该项是任务核心指标，如分辨率、重访周期；最好项是增强性需求，如多谱段扩展、在轨重构。分类后，对冲突项进行权衡分析，形成初步优先级清单，并明确哪些需求需要用户确认、哪些可由设计方自主权衡。

图中展示了从任务发起方到用户、载荷方、平台方，再到测控与运控方的需求传递路径，以及最终汇聚到需求池并形成优先级清单的过程。左侧与右侧的冲突框提示了最常见的两类矛盾：性能与资源、时效与保障条件。实际项目中，这些冲突往往不会一次性暴露，而是在接口协调和仿真推演中逐步显现，因此需求分析是一个迭代过程。

从需求到可分解指标的初步整理

完成角色识别与冲突处理后，应形成一份可向下分解的需求基线。基线中每条需求至少包含：需求编号、来源角色、原始表述、转化后的参数化描述、优先级、验证方式、待确认项。例如“灾害后 6 小时内获取影像”可转化为“成像响应时间 ≤ 6 h（含任务规划、测控、数传、处理）”，验证方式为仿真推演与地面联试。只有达到这种粒度，后续的指标分解才有明确输入。

综上，本节的核心是建立一张“角色—渠道—冲突—优先级”的初步关系网。它不追求一次性完美，而是确保所有关键声音都被听见、所有硬约束都被记录、所有冲突都有初步处理方向。这张关系网将直接作为后续任务需求分析与指标分解的输入基线。