2. 维修性需求来源与利益相关方分析
维修性需求不是设计人员凭经验“拍脑袋”定出来的指标，而是从装备的使命任务、使用方式、维修保障条件以及各类利益相关方的诉求中逐步提炼、协商和固化下来的。理解需求的来源，本质上是要回答三个问题：装备将来要干什么、在什么条件下修、由谁来修以及他们希望修得多快多好。只有把这三条线索理清，后续的定量指标（如平均修复时间MTTR、最大修复时间、故障隔离率等）才有依据，设计评审时也才有可对照的基准。
一、需求的三类主要来源
任务需求是顶层牵引。它来自作战或使用任务剖面，例如某型地面雷达要求“在机动转移后30分钟内恢复主要作战功能”，这一任务约束会直接转化为对关键模块可更换性、备件就位速度和测试可达性的要求。任务需求通常以出动强度、持续工作时间、任务成功率等形式出现，维修性需求要从中提取“允许停机时间”这一核心量。
使用与维修场景决定了需求的现实边界。同一型装备，部署在固定场站与部署在野外机动条件下，其维修性要求差异巨大：前者可依赖固定测试设备和专业维修分队，后者往往要求基层级维修人员用随车工具和内置测试（BIT）完成故障定位与模块更换。场景要素包括维修级别划分（基层级、中继级、基地级）、维修环境（温度、湿度、振动、照明、空间）、可用保障资源（备件、工具、测试设备、技术资料）以及人员技能水平。
利益相关方诉求则把不同角色的关注点带入需求。用户（作战/使用人员）关心的是装备可用度和再次出动速度，希望故障后能快速恢复；维修人员关心的是故障是否容易隔离、部件是否便于拆装、是否需要特殊工具、工作姿态是否舒适；保障部门关心的是备件品种与数量、测试设备通用性、维修人力与培训成本、技术资料的完整性。这些诉求有时相互冲突，例如用户希望模块化快速更换，而保障部门可能担心模块化带来备件种类增加，因此需求捕获过程必须包含权衡与协商。
二、需求捕获的常用方法
需求捕获不是一次性活动，而是一个迭代过程。实践中常用的方法包括：任务剖面分析，把装备全寿命周期内的典型任务阶段拆开，逐段识别可能的故障模式和允许的维修时间窗口；维修场景走查，组织设计、维修和保障人员一起模拟“故障发生—报警—隔离—拆装—更换—测试—恢复”的全过程，记录每一步的耗时和障碍；利益相关方访谈与工作坊，用结构化问题引导用户、维修人员和保障部门表达真实诉求，避免只听到“越快越好”这类模糊表述；历史故障与维修数据统计，从相似装备的维修记录中提取实际MTTR分布、高频故障件和维修瓶颈；相似装备类比，在新装备缺乏数据时，用同类装备的维修性指标作为起点，再根据差异修正；维修性演示与试验，通过样机或虚拟仿真验证拆装可达性和测试性设计；专家评审与权衡分析，在指标冲突时用质量功能展开（QFD）或权衡矩阵辅助决策。
这些方法各有适用阶段。方案阶段以任务剖面分析和利益相关方访谈为主，初步确定维修性定量要求；工程研制阶段则更多依赖维修场景走查、演示试验和相似装备数据，把定性要求转化为可验证的设计特征。
三、典型输入清单及其用途
需求捕获的成果应形成一份结构化的输入清单，作为后续维修性设计、评审和验证的共同基准。清单通常包含以下条目：
- 定量指标：平均修复时间MTTR、最大修复时间、故障隔离率、虚警率、平均预防性维修时间等，并注明统计条件和置信水平。
- 维修级别与任务分配：明确哪些故障在基层级排除、哪些送中继级或基地级，以及各级别的维修时限。
- 基层级可更换单元（LRU/SRU）清单：列出允许现场更换的模块、更换所需时间上限和拆装约束。
- 测试性与BIT要求：故障检测覆盖率、隔离到单个LRU的百分比、BIT自检时间和虚警控制目标。
- 保障资源需求：专用工具、测试设备、备件品种与数量、技术资料形式（纸质/交互式电子手册）。
- 人员与培训需求：维修人员数量、技能等级、培训时长和考核方式。
- 人因与安全要求：维修姿态、照明、空间、防差错设计、危险能量隔离等。
- 验证方案输入：明确哪些指标将通过演示验证、哪些通过分析验证、哪些通过试验验证，以及对应的故障注入方案和样本量。
四、从诉求到指标的转化示例
以某车载通信设备为例。用户提出“故障后30分钟内恢复通信”，这是任务需求；维修场景走查发现，基层级维修人员只有随车工具和内置BIT，没有专用频谱仪；维修人员反映“模块拆装需要拆下整个机柜面板，至少40分钟”。保障部门则担心备件种类过多。综合这些输入，需求捕获团队将顶层要求转化为：基层级可更换单元更换时间不超过15分钟，BIT故障隔离到LRU的覆盖率不低于90%，面板采用快锁结构且无需专用工具，备件清单控制在8种以内。这些指标写入维修性需求清单后，再分配给结构设计、测试性设计和保障性设计分别落实。
这个例子说明，需求捕获的关键在于把不同来源的“愿望”翻译成可测量、可分配、可验证的工程语言。利益相关方分析不是简单罗列角色，而是识别每个角色的核心关切、约束条件和可接受的权衡范围，使维修性需求在用户可用度、维修便捷性和保障经济性之间取得平衡。
完成需求捕获后，应组织一次需求评审，确认清单的完整性、一致性和可验证性，并将其作为维修性设计准则和后续验证计划的输入。下一阶段的设计工作，将围绕这些需求展开功能分配、布局优化和测试性设计。