2. 卫星任务需求捕获与利益相关方分析

卫星任务总体设计的第一步不是画构型、也不是选火箭，而是把"到底要解决什么问题"说清楚。需求捕获的质量直接决定后续轨道、载荷、平台、发射与测控方案是否会被反复推翻。本节围绕用户需求、任务目标、约束条件、需求转化方法、需求跟踪矩阵，以及遥感、通信、导航三类典型任务的需求案例展开。

一、从用户需求到任务目标：三层语言

用户需求通常以"业务语言"出现，例如"希望每周对某流域观测两次""希望为远海船只提供通信""希望区域定位精度优于5米"。这些表述描述的是用户业务效果，而不是卫星指标。总体设计需要把它翻译成两层：

• 任务目标：用可度量的任务级指标描述系统要达成的能力，如重访周期、覆盖区域、通信容量、定位精度、服务可用性。
• 系统需求：把任务目标分解到轨道、载荷、平台、地面、发射等分系统，形成可验证的技术指标。

例如用户说"每周看两次某流域"，任务目标可写成"对目标区域（中心纬度30°N、经度跨度约300 km）实现平均重访≤3.5天、地面分辨率≤10 m、单景幅宽≥60 km"。系统需求则进一步落到轨道倾角、回归周期、相机焦距与像元尺寸、数传速率等。需求转化的本质是把模糊的期望变成可测量、可验证、可追溯的条目。

二、约束条件是需求的"边界"

约束条件不是需求本身，但它限定了需求的可行域。常见约束包括：

• 预算与周期约束：经费上限、研制周期、发射窗口。
• 物理与工程约束：运载能力、整流罩尺寸、平台功率、热控与姿控能力。
• 法规与政策约束：频率协调、轨道位置申报、遥感数据分发政策、出口管制。
• 环境约束：辐射带、空间碎片规避、光照与地影条件。

约束条件必须在需求捕获阶段就显式记录，否则会在方案设计后期以"不可实现"的形式暴露，造成返工。一个实用做法是给每条约束标注类型、来源、影响范围、是否可协商，便于后续权衡。

三、需求转化方法与需求跟踪矩阵

需求转化常用方法包括：目标分解、场景推演、指标映射、权衡分析。以遥感任务为例，从"重访≤3.5天"出发，可推演到轨道高度、倾角、回归周期、侧摆能力，再映射到姿态机动角速度与星上存储容量。每一步都要保留"为什么这样分解"的依据。

需求跟踪矩阵（RTM）是保证需求不丢失、不蔓延的核心工具。它把用户需求、任务目标、系统需求、验证方法、验证阶段一一对应。下表给出一个简化示例（示例数据，仅用于说明结构）：

RTM的价值在于：任何一条系统需求都能向上追溯到用户需求，任何一条用户需求都能向下找到实现与验证路径。当预算或进度受限需要裁剪时，可以快速判断哪条需求可以降级、哪条不能动。

四、典型任务需求案例

遥感任务：核心需求是"看得清、看得勤、传得回"。典型指标包括地面分辨率、幅宽、重访周期、光谱波段、辐射精度、数据延迟。用户可能是国土、农业、应急等部门，需求差异很大：应急要求小时级重访，资源调查可接受天级。

通信任务：核心需求是"覆盖、容量、可用性"。典型指标包括覆盖区域、EIRP、G/T、链路余量、容量、误码率、可用度。用户需求常表现为"为某海域提供宽带服务"，需转化为波束覆盖、频率复用、星上功率与地面终端口径。

导航任务：核心需求是"精度、完好性、连续性、可用性"。典型指标包括定位精度、测速精度、授时精度、完好性告警时间。用户需求"区域定位优于5米"需转化为星座构型、星钟稳定度、播发体制与地面运控精度。

三类任务的共同点是：用户语言必须经过任务目标与系统需求两层翻译，并借助RTM保持可追溯。区别在于指标集与验证手段不同，遥感重覆盖与成像，通信重链路与容量，导航重星座与时空基准。

五、实操建议：需求捕获工作单

在项目启动阶段，建议用一份需求捕获工作单逐条记录，避免口头传递造成遗漏。工作单至少包含以下字段：需求编号、来源（用户/法规/内部）、原始表述、转化后任务目标、对应系统需求、约束条件、验证方法、优先级、责任人、状态。填写时注意：

1. 原始表述尽量保留用户原话，不要提前"技术化"，否则会丢失真实意图。
2. 每条任务目标必须可度量，避免"较高""较快"等模糊词。
3. 约束条件单独成列，并标注是否可协商，便于后续权衡。
4. 优先级用高/中/低或MoSCoW标注，作为裁剪依据。

综上，需求捕获与利益相关方分析的核心是：识别谁提需求、需求背后的业务目标是什么、有哪些硬约束、如何把业务语言翻译成可验证的系统指标，并用RTM保持全链路可追溯。遥感、通信、导航三类任务的指标集不同，但转化逻辑一致。掌握这一节的方法，后续轨道、载荷、平台设计才有稳定的输入基础。