3. 系统需求分析与验证指标分解
星地通信系统的集成与验证，起点不是设备，而是需求。需求分析做得好，后续的测试用例、验证矩阵和验收判据才有依据；需求分析做得差，往往会出现“设备都正常、系统却不达标”的尴尬局面。本节围绕任务需求捕获、功能性能指标分解、验证需求映射和可验证性设计原则四个环节展开，重点说明如何把一句模糊的任务描述，逐步转化为可测量、可追溯、可判定的验证指标。
一、任务需求捕获：从任务语言到工程语言
任务需求通常来自用户或总体单位，表述偏任务化，例如“在指定区域内为地面终端提供连续数据回传服务”。这类描述包含任务意图，但缺少频段、速率、可用度、时延等工程约束。需求捕获的任务，就是把这些任务语言翻译成工程语言，并识别出隐含约束。
捕获过程建议从四个维度提问：任务场景（覆盖区域、轨道类型、终端数量）、业务特征（数据速率、业务连续性、时延敏感度）、环境约束（可用度、抗干扰、天气影响）、接口边界（与地面网、测控网、运控系统的接口）。以某低轨数据回传任务为例，捕获结果可整理为：轨道高度约 550 km、单星覆盖半径约 1000 km、地面终端 EIRP 不低于 30 dBW、单次过顶时长约 8 min、要求日回传数据量不低于 2 GB。这些数值属于示例性假设，用于说明捕获粒度，实际项目应以任务书和链路预算为准。
捕获阶段还要区分“需求”与“愿望”。例如“希望链路余量尽量大”不是需求，而是设计偏好；可转化为“在仰角 10° 以上时链路余量不低于 3 dB”这样的可验证表述。
二、功能性能指标分解：把系统指标落到分系统
捕获到的任务需求是系统级指标，必须逐层分解到分系统、单机乃至接口。分解的核心逻辑是：系统指标 = 分系统指标的组合与约束。以“日回传数据量不低于 2 GB”为例，可分解为：
- 单次过顶可用通信时间 ≥ 6 min（扣除捕获与切换开销）；
- 有效信息速率 ≥ 5 Mbps（2 GB ≈ 16 Gbit，16 Gbit / 6 min ≈ 44 Mbps，考虑编码与重传开销后取 5 Mbps 为示例下限）；
- 误帧率 ≤ 1×10⁻⁵（对应可接受的重传比例）；
- 链路可用度 ≥ 99%（含雨衰、遮挡与设备故障）。
继续向下分解，5 Mbps 信息速率可映射到调制编码方式、符号速率、带宽和接收门限；误帧率可映射到编码增益、解调门限和同步性能；可用度可映射到发射功率、天线增益、接收 G/T 和冗余配置。分解时要注意指标之间的耦合：提高速率可能降低链路余量，提高可用度可能增加功率或带宽需求。因此分解不是单向拆分，而是带约束的迭代过程。
三、验证需求映射：每条指标都要有验证方法
指标分解完成后，必须回答“这条指标怎么验证”。验证需求映射就是把每条指标与验证方法、验证层级、判据和所需资源对应起来。常用验证方法包括：分析（链路预算、覆盖分析）、仿真（系统级或链路级）、测试（单机、分系统、系统级）、演示（端到端业务演示）。
以“有效信息速率 ≥ 5 Mbps”为例，映射结果可以是：验证层级为分系统级，方法为误码率测试加吞吐量测试，判据为连续 10 min 内平均吞吐量 ≥ 5 Mbps 且误帧率 ≤ 1×10⁻⁵，所需资源包括信道模拟器、误码仪和协议分析仪。再以“链路可用度 ≥ 99%”为例，验证方法以分析加长期监测为主，判据为统计周期内不可用时间占比 ≤ 1%，资源包括雨衰模型、监测日志和故障记录。
映射时容易出现两类问题：一是“有指标无方法”，例如只写了“抗干扰能力强”却没有定义干扰场景和判据；二是“有方法无判据”，例如只写“进行测试”却没有给出通过阈值。这两类问题都会导致验证无法闭环。
四、可验证性设计原则
可验证性不是验证阶段才考虑的事，而应在需求设计阶段就嵌入。核心原则包括：
- 可测量：指标必须能通过仪器、日志或分析手段获得数值，避免“良好”“稳定”等定性词。
- 可判定：每条指标必须有明确的通过/不通过阈值，阈值应来自任务书、标准或链路预算。
- 可追溯：从任务需求到系统指标、分系统指标、测试用例，应保持双向追溯，任一环节变更都能评估影响范围。
- 可复现：验证条件（频点、功率、仰角、温度、干扰样式）应记录完整，使不同人员在不同时间能得到一致结论。
- 可分解：复杂指标应能拆成若干可独立验证的子指标，避免“整机联调才能测”的被动局面。
下面这张图给出从任务需求到验证判据的映射关系，重点表达“需求—指标—验证”三层之间的追溯链，以及可验证性设计原则对每一层的约束。
回到实践层面，需求分析与指标分解的成果通常体现为三份相互关联的文件：需求规格说明（记录任务需求与系统指标）、指标分解表（记录分系统/单机指标及分解依据）、验证矩阵（记录每条指标的验证方法、层级、判据和资源）。三份文件之间应保持编号一致，任何一条需求变更都能沿编号追溯到对应的指标和验证用例。
最后需要强调，可验证性设计原则中的“可分解”与“可追溯”是相互支撑的：可分解保证指标能落到可测试的层级，可追溯保证分解过程不丢失任务意图。只有把这两点做扎实，后续的系统集成与验证才能从“凭经验调”转向“按指标判”，这也是星地通信系统集成与验证课程贯穿始终的方法论。