3. 任务目标到任务需求的结构化转化
在航天器任务分析中，最容易出现也最隐蔽的错误，是把“任务目标”直接当成“任务需求”来使用。例如“实现对某区域的高分辨率成像”是目标，而“在500 km太阳同步轨道上，以0.5 m地面采样距离、幅宽不小于30 km、单圈成像时间窗口不小于8 min完成对目标区域的成像”才是需求。目标回答“为什么做、做成什么样算成功”，需求回答“系统必须满足哪些可验证的条件”。本节围绕任务目标陈述、任务成功准则、任务阶段划分和任务级需求条目化表达四个环节，说明如何把一句笼统的目标，转化为可分配、可验证、可追溯的需求条目，并给出避免目标与需求混淆的实践方法。
一、任务目标陈述：先固定“为什么”和“边界”
任务目标陈述应回答三个问题：任务要解决什么问题、服务对象是谁、在什么约束下完成。它通常来自用户或任务书的顶层意图，允许概括，但必须明确边界，否则后续需求会无限扩张。一个可用的目标陈述模板是：“为[用户/任务背景]，在[时间、经费、平台等约束]下，实现对[对象/区域]的[观测/通信/服务]能力，支撑[应用目标]。”
以某遥感任务为例，目标可写为：“为区域灾害应急监测提供快速光学成像能力，在两年研制周期和500 kg级平台约束下，实现对中纬度目标区域的分辨率优于1 m、重访不超过3天的成像服务。”这句话里已经隐含了分辨率、重访、平台规模等可量化线索，但仍是目标层，不能直接作为分系统设计输入。
二、任务成功准则：把“成功”变成可判定的条件
成功准则用于回答“任务做到什么程度算成功”。它通常由若干条可判定的判据组成，每条判据应包含指标、阈值和判定方式。例如上述遥感任务的成功准则可包括：
- 成像分辨率：在标称轨道高度下，地面采样距离（GSD）≤1 m，以在轨测试图像评估；
- 时间覆盖：对目标纬度带的重访周期≤3天，以轨道仿真和地面站可见性分析判定；
- 数据可用性：单次过境有效成像数据下传成功率≥95%，以在轨数据接收记录统计；
- 任务寿命：在轨正常工作寿命≥3年，以遥测和寿命试验数据评估。
成功准则与目标的区别在于：目标可以定性，成功准则必须可判定。若一条准则无法回答“用什么数据、按什么规则判定”，它就不适合作为成功准则，而应退回目标层继续澄清。
三、任务阶段划分：让需求有“时间坐标”
同一任务在不同阶段对系统的要求不同。阶段划分的作用，是把笼统的目标拆成按时间展开的能力要求，使需求条目能够挂接到具体阶段。典型划分包括发射入轨段、早期轨道段、在轨测试段、任务运行段和离轨处置段。对遥感任务而言，在轨测试段关注成像质量与几何精度，任务运行段关注重访、数据下传和任务规划效率，离轨段关注剩余推进剂与离轨时间。
阶段划分不是简单的时间列表，而应明确每个阶段的进入条件、退出条件和主要验证对象。例如“在轨测试段退出条件”可写为：完成不少于10景典型目标成像，GSD、信噪比和几何定位精度均满足成功准则，且连续3圈数据下传无异常。这样，阶段就成为需求验证的上下文。
四、任务级需求条目化表达：从“一句话”到“一条可执行条目”
需求条目化是把目标、准则和阶段信息固化为可管理对象的过程。一条合格的任务级需求至少包含五个要素：唯一编号、需求描述、关键参数与阈值、验证方法、追溯关系。编号用于管理和追溯，描述用“系统应……”的句式，参数必须带单位和容差，验证方法说明用分析、试验、检查还是演示，追溯关系指向对应的目标或成功准则。
以“重访不超过3天”为例，条目化后应写成：“REQ-COV-02：在标称轨道和地面站配置下，系统对目标纬度带（30°N～45°N）内任意点的重访周期应不大于3天（含3天），以轨道仿真和地面站可见性分析验证，追溯至GOAL-01。”这里“标称轨道和地面站配置”是前提条件，“30°N～45°N”是适用范围，“不大于3天”是阈值，“轨道仿真和可见性分析”是验证方法。缺少任何一项，需求都会在后续分配中产生歧义。
条目化时还要注意区分“任务级需求”和“系统级需求”。任务级需求描述任务要达成的能力，系统级需求描述分系统或单机必须提供的功能性能。例如“重访≤3天”是任务级需求，而“相机幅宽≥30 km”是系统级需求，后者由前者分解而来。混淆两者，会导致任务分析过早陷入部件选型，或让分系统设计失去任务上下文。
五、避免目标与需求混淆的实践方法
实践中可用三条规则快速自检。第一，可判定性检查：如果一条陈述无法用“是/否”或具体数值判定，它更可能是目标而非需求。第二，参数化检查：需求必须包含可测量的参数、阈值和单位，目标可以只给方向。第三，追溯检查：每条需求都应能向上追溯到至少一条目标或成功准则，每条目标也应能向下找到支撑它的需求；若某条目标没有任何需求支撑，说明分解不完整；若某条需求无法追溯，说明它可能是凭空添加的。
此外，建议在需求库中设置“目标—准则—阶段—需求”四列追溯矩阵，并在评审时逐条核对。对于阶段相关需求，可在条目中增加“适用阶段”字段，例如“REQ-DATA-03 适用于任务运行段”。这样，当任务阶段推进或约束变化时，可以快速定位受影响的需求条目，避免目标与需求在版本迭代中再次混淆。
总之，任务目标到任务需求的转化，本质上是把“意图”逐步收敛为“可验证的约束”。目标陈述固定方向，成功准则给出判据，阶段划分提供时间坐标，条目化表达则把这一切固化为可管理、可分配、可追溯的需求对象。掌握这一转化链，后续的功能分解、指标分配和验证规划才有稳定的起点。