2. 航天器任务与系统级需求分析

航天器研制中，需求分析不是把用户的话抄一遍，而是把任务目标逐层“翻译”成可设计、可验证的工程语言。任务目标通常来自任务书或用户需求，例如“实现对某区域每24小时一次的重访观测，地面分辨率优于5 m，数据在观测后2小时内下传”。这句话里既有任务级指标（重访周期、分辨率、时延），也隐含了轨道、载荷、数传、测控等多专业约束。需求分析的核心工作，就是把这些目标分解到系统级、分系统级，并在每一层识别出V&V需求的来源。

一、需求层次与分解逻辑

航天器需求一般分为四层：任务需求、用户需求、系统需求、分系统/单机需求。任务需求描述“为什么做”，用户需求描述“用户要什么”，系统需求描述“航天器系统必须做到什么”，分系统需求描述“各分系统必须提供什么”。分解时遵循三条原则：一是可追溯，每条下层需求必须能追溯到上层需求；二是可验证，每条需求必须能用分析、试验、演示或检查中的一种方法验证；三是不重复、不遗漏，避免同一指标在多处矛盾。

以“重访周期≤24 h”为例，它分解到系统级会变成轨道高度、倾角、回归特性等参数约束；再分解到分系统，则涉及姿态机动能力、能源供给、热控能力等。分解过程中，V&V需求来源主要有四类：用户明确提出的指标、任务书隐含的约束、上级系统接口要求、以及法规与标准强制条款。识别这些来源，是后续编写验证矩阵的前提。

二、可验证需求条目的编写方法

一条合格的需求条目应包含五个要素：条件、主体、动作、指标、验证方法。常见错误是写成“载荷应具有高分辨率”，这既无量化指标，也无验证方法。正确写法如：“在轨道高度500 km、太阳高度角大于30°的条件下，相机应实现星下点地面分辨率优于5 m，通过分析计算与在轨成像测试确认。”这里条件、指标、验证方法都明确。

编写时还要注意：指标必须可测量，避免“尽量”“大约”等模糊词；验证方法要与指标匹配，分辨率可用分析加测试，寿命可用分析加试验；每条需求应有唯一编号，便于追溯。例如系统级需求编号SR-001，分系统需求编号SSR-001，验证矩阵中一一对应。

三、验证矩阵雏形的构建

验证矩阵是需求与验证活动的对应表，雏形阶段至少包含四列：需求编号、需求描述、验证方法、验证阶段。验证方法通常有四种：分析（A）、试验（T）、演示（D）、检查（I）。验证阶段可分为方案阶段、初样阶段、正样阶段、在轨阶段。以“重访周期≤24 h”为例，验证方法为分析加在轨测试，验证阶段为方案阶段分析与在轨阶段测试。

构建矩阵时，先列出所有系统级需求，再逐条判断验证方法和阶段。若某条需求找不到合适验证方法，说明需求本身可能不可验证，需要重新分解或补充约束。矩阵雏形不追求一次完整，但必须保证每条需求都有验证路径，这是后续V&V策划的基础。

四、从需求到V&V策划的衔接

需求分析完成后，V&V策划才有依据。系统级需求决定验证项目，分系统需求决定验证层级，验证矩阵决定验证顺序和资源分配。实际工程中，需求分析往往与V&V策划迭代进行：需求分解时同步考虑验证可行性，验证方法确定后反向修正需求表述。这种迭代能避免后期出现“无法验证”或“验证成本过高”的问题。

总之，任务与系统级需求分析的关键在于：把任务目标逐层分解为可量化、可追溯、可验证的工程需求，识别V&V需求来源，并形成验证矩阵雏形。这一过程直接决定后续验证活动是否有的放矢，是航天器系统验证与确认策划的起点。