4. 航天器任务需求与功能基线建立

航天器研制中，任务需求与功能基线是后续所有设计、验证和状态控制的源头。任务需求回答“用户要航天器完成什么任务、达到什么指标”，功能基线回答“系统由哪些功能构成、功能之间如何分配与接口”。两者一旦冻结，就成为技术状态管理的基准，任何变更都必须走评审与审批流程。本节围绕任务需求分析、系统功能分解、功能基线文档构成和需求可追溯性矩阵的建立方法展开。

一、任务需求分析：从用户期望到可验证条目

任务需求分析不是简单抄录用户文件，而是把模糊的期望转化为可量化、可验证、可追溯的需求条目。典型输入包括任务书、用户指标、运载与测控约束、空间环境条件、经费与进度边界。分析过程通常按“任务目标—任务阶段—使用场景—功能/性能需求—约束需求”逐层展开。

以某低轨遥感卫星为例，用户提出“每天对某区域成像一次，地面分辨率优于2 m”。分析后应拆解为：轨道高度约500 km、降交点地方时约10:30、相机地面像元分辨率≤2 m、幅宽≥30 km、数传码速率≥450 Mbps、星上存储≥512 Gbit、姿态指向精度≤0.05°等条目。每条需求必须给出唯一编号、来源、验证方法和验收判据。例如“GND-RES-002：地面像元分辨率≤2 m（在500 km轨道高度、太阳高度角≥30°条件下），验证方法为分析+测试，判据为设计报告与成像试验结果”。

需求分析中要区分三类需求：功能需求（做什么）、性能需求（做到什么程度）、约束需求（边界条件）。同时要识别需求之间的冲突，例如高分辨率与大幅宽、高码速率与低功耗，需在权衡后形成基线。需求条目应避免“尽量”“较高”等不可验证表述，所有指标必须可测量。

二、系统功能分解：从任务到分系统

功能分解是把任务需求逐级分配到系统、分系统、单机，形成功能树或功能框图。常用方法是功能流法：先识别任务阶段（发射、入轨、在轨运行、成像、数传、离轨），再为每个阶段定义输入、输出、控制与支撑功能。

以成像任务为例，顶层功能为“获取目标区域图像并传回地面”。分解为：姿态机动与稳定、相机成像、图像压缩与存储、数传发射、电源供给、热控保障、测控与数管。每个功能再向下分解，例如“相机成像”可分解为光学系统、焦平面、驱动与温控、图像采集。分解结果应满足：功能不重叠、不遗漏，每个功能有明确输入输出和性能指标，且能追溯到上层需求。

功能分解的深度以“可分配给一个承制单位或一个单机”为原则。分解完成后，需进行功能接口分析，明确机械、电气、热、信息接口，例如相机与数管之间的图像数据接口、相机与热控之间的散热接口。接口一旦确定，即成为功能基线的一部分。

三、功能基线文档构成

功能基线是经评审确认的功能需求与功能分解的集合，通常由以下文档构成：任务需求规格书、系统功能规格书、功能分解图/功能树、接口控制文件（ICD）、需求可追溯性矩阵、验证计划。任务需求规格书描述用户级需求；系统功能规格书描述系统级功能与性能；功能分解图展示层级关系；ICD规定接口参数；可追溯性矩阵建立需求与功能、验证之间的映射；验证计划说明每项需求的验证方法。

功能基线冻结后，任何需求或功能变更都需提交变更申请，经技术状态控制委员会评审。变更影响分析要覆盖性能、接口、进度、成本、验证状态。例如若将分辨率从2 m提高到1.5 m，需评估相机口径、平台稳定度、数传码速率、功耗和热控的连锁影响，并更新可追溯性矩阵和验证计划。

四、需求可追溯性矩阵的建立方法

需求可追溯性矩阵（RTM）是功能基线管理的核心工具，用于确保每条需求都有来源、有分配、有验证。建立步骤如下：

1. 为每条需求分配唯一编号，格式建议“类别-序号”，如“MIS-001”“PER-003”“CON-005”。
2. 记录需求来源，如用户任务书第3.2条、上一级需求编号、约束文件。
3. 将需求分配到功能或分系统，填写功能编号或分系统名称。
4. 为每条需求指定验证方法：分析（A）、检查（I）、演示（D）、测试（T）。
5. 记录验证状态与验证证据编号，如测试报告、分析报告。
6. 建立双向追溯：正向从需求到功能与验证，反向从功能与验证回到需求。

以下为示例矩阵片段（示例数据，仅用于说明格式）：

RTM建立后，应定期检查“孤儿需求”（无来源或无分配）和“孤儿功能”（无需求驱动），确保基线完整。在评审前，用RTM核对每条需求是否都有验证方法，避免遗漏。

五、建立过程中的常见问题与检查要点

实际工程中，需求分析容易出现的偏差包括：指标不可验证、需求遗漏、需求冲突未识别、功能分解与需求脱节。建议在功能基线评审前完成以下检查：每条需求是否有唯一编号和来源；每条需求是否分配到至少一个功能；每个功能是否至少追溯到一条需求；每条需求是否指定验证方法；接口是否覆盖机械、电气、热、信息四类；变更影响是否已分析并记录。

综上，任务需求分析把用户期望转化为可验证条目，系统功能分解把需求分配到可实现的层级，功能基线文档把这些结果固化并受控，可追溯性矩阵则保证需求、功能、验证三者之间双向可查。四者共同构成航天器技术状态管理的起点，为后续设计、试验和状态控制提供依据。