3、需求拆解核心概念：需求层次、用户需求、任务需求、系统需求、功能需求与性能需求的定义与区别

在无人机任务场景的需求拆解工作中，最大的障碍往往不是技术实现，而是需求表述的混乱。用户说“我要一架能巡河的无人机”，研发说“需要一款续航90分钟、抗风5级的四旋翼”，工艺说“机臂快拆结构要承受2000次插拔”，这三句话其实指向完全不同的需求层次。如果不加区分地混在一起讨论，必然导致方案反复、成本失控甚至项目失败。因此，在进入任何任务场景分析之前，必须首先建立一套统一的需求语言体系，明确六个核心概念：需求层次、用户需求、任务需求、系统需求、功能需求与性能需求。本章将逐一给出定义、判别标准、拆解方法与典型误区，帮助学员在后续章节中能够准确地将模糊的任务意图转化为可设计、可验证、可追溯的工程需求。

上图展示了需求拆解的整体逻辑框架：从顶层的用户需求出发，逐层细化到任务需求、系统需求，最终落地为功能需求与性能需求。每一层之间不是简单的“翻译”，而是经过分析、取舍、量化和验证的工程过程。下面逐一展开六个核心概念的定义与区别。

3.1 需求层次：从“为什么”到“做到什么程度”

核心原理：需求层次描述的是需求从抽象到具体的纵向结构。在无人机系统工程中，通常划分为四个层次：战略层（用户需求）、任务层（任务需求）、系统层（系统需求）、实现层（功能需求+性能需求）。每一层回答不同的问题：用户需求回答“为什么做”，任务需求回答“做什么事”，系统需求回答“需要什么能力”，功能与性能需求回答“具体怎么实现、做到什么标准”。层次划分的核心价值在于：让不同角色的干系人（用户、任务规划者、系统工程师、软硬件设计师）在各自的关注层面上进行沟通，避免跨层讨论造成的混乱。

判断方法：判断一条需求属于哪个层次，可以使用“提问法”——不断追问“为什么”和“怎么做”。如果一条需求还能继续追问“为什么”，说明它偏向上层；如果还能继续追问“怎么做”，说明它偏向下层。例如：“无人机需要具备夜间巡检能力”属于用户需求；“夜间巡检时需在光照低于0.1 lux环境下识别10cm×10cm障碍物”属于性能需求。另一个判断标准是可验证性：用户需求通常不可直接验证，而性能需求必须具有明确的测试方法和通过准则。

3.2 用户需求：业务意图与价值期望

核心原理：用户需求是需求的源头，描述的是用户希望通过无人机系统实现的业务目标、使用意图和价值期望。它不关心技术实现方式，只关心“最终得到什么结果”。用户需求通常以自然语言表述，带有主观性和模糊性，需要经过分析才能转化为工程语言。例如“提高巡检效率”是用户需求，但“效率”的定义（是时间缩短？还是人力减少？还是覆盖率提升？）需要与用户确认。

操作流程：用户需求获取通常遵循以下步骤：

1. 干系人识别：确定谁是真正的用户（直接使用者、决策者、维护者、受影响的第三方）。
2. 场景访谈：让用户描述典型工作场景，包括当前痛点、期望改进点、成功标准。
3. 目标量化：将模糊目标转化为可度量的业务指标（如“巡检时间从4小时缩短到1小时”）。
4. 优先级排序：区分“必须有”（Must）、“应该有”（Should）、“可以有”（Could）三个级别。
5. 确认签字：形成用户需求说明书，由用户代表确认。

3.3 任务需求：任务剖面与作业流程

核心原理：任务需求描述的是无人机在特定场景中需要完成的具体任务动作序列，包括任务剖面（飞行路径、高度变化、速度剖面）、作业内容（侦察、测绘、投送、通信中继等）、环境条件（风速、温度、电磁干扰、地形）以及任务成功标准。任务需求是连接用户需求与系统需求的桥梁——它把“为什么要做”转化为“具体要做什么事”。

任务需求拆解方法：常用的工具是任务剖面分析法。以“山区电力巡线”为例：

• 任务阶段划分：起飞→爬升→沿线路巡航→悬停检测→返航→降落。
• 每个阶段的环境参数：海拔2000m、阵风8m/s、温度-5℃、电磁场强度（靠近高压线）。
• 每个阶段的关键动作：巡航时需保持对导线±0.5m的横向偏差；悬停时需稳定在0.3m精度内。
• 任务成功标准：全程无需人工干预，识别出至少95%的缺陷点，数据实时回传。

3.4 系统需求：能力与约束的工程化表达

核心原理：系统需求是将任务需求转化为系统级能力描述，它定义了无人机系统（包括飞行平台、任务载荷、地面站、数据链路、保障设备）需要具备的总体能力以及外部接口和约束条件。系统需求不指定具体实现技术，但必须明确“需要什么能力”和“在什么约束下工作”。例如任务需求是“在暴雨中执行搜索”，系统需求则表述为“飞行平台需具备IP54防护等级，任务载荷需在雨滴直径≤2mm、降雨强度≤10mm/h条件下正常工作”。

系统需求分类：

3.5 功能需求与性能需求：实现层的“做什么”与“做到什么程度”

核心原理：功能需求描述系统必须执行的行为或动作，回答“做什么”的问题；性能需求描述这些行为必须达到的量化水平，回答“做到什么程度”的问题。两者是成对出现的——没有性能指标的功能需求无法验证，没有功能载体的性能需求没有意义。例如“飞控系统应支持航点飞行”是功能需求，“航点飞行时位置误差≤±1m”是性能需求。

功能需求拆解方法：通常采用用例驱动法。以“无人机自主巡检”为例：

1. 识别主要用例：起飞、巡航、目标检测、悬停拍摄、自动返航。
2. 每个用例分解为功能步骤：例如“目标检测”包括图像采集→预处理→目标识别→结果标注→数据存储。
3. 每个功能步骤定义输入/输出/触发条件/异常处理。
4. 为每个功能步骤附加性能指标。

性能需求量化要点：性能指标必须满足SMART原则（Specific具体、Measurable可测量、Achievable可达成、Relevant相关、Time-bound有时限）。例如“图像传输延迟低”不是合格的性能需求，应改为“图像传输端到端延迟≤200ms（在10km距离、无遮挡条件下，测试方法为时间戳比对法）”。

3.6 案例拆解：从“河道巡检”到可验证的需求体系

场景背景：某市水务局提出需求：“我们需要一套无人机系统，用于每周对辖区内35km河道进行巡查，重点发现非法排污口和水面漂浮物。”这是典型的用户需求，模糊且不可直接设计。

需求拆解过程：

第一步：用户需求分析。与水务局沟通后明确：巡查频率每周1次，每次作业时间不超过3小时（含准备和撤收），需要覆盖河道全段，重点关注排污口（直径≥20cm的管口）和漂浮物（面积≥0.5m²的物体）。成功标准：每次巡查后24小时内输出问题清单及坐标。

第二步：任务需求定义。任务剖面为：从河道中段起降点起飞→沿河道双向飞行各17.5km→飞行高度30m→速度8m/s→在疑似排污口位置悬停10s进行详查→返航。环境条件：夏季最高气温38℃，冬季最低-10℃，最大风速6级（10.8~13.8m/s），河面宽度20~80m。

第三步：系统需求推导。

• 航程需求：单次飞行需覆盖17.5km（单向），考虑返航和余量，航程≥40km。
• 续航需求：以8m/s巡航，17.5km需约36min，加上悬停和返航，续航≥60min。
• 载荷需求：需同时识别排污口（静态目标）和漂浮物（动态目标），建议可见光+多光谱双光载荷。
• 定位精度：排污口坐标误差≤±3m，以便地面人员快速找到。
• 数据链路：需实时回传视频流，且支持断点续传。

第四步：功能与性能需求落地。

结果与复盘：按照上述需求体系，最终选型为：六旋翼平台（航程45km、续航65min）、双光吊舱（可见光2000万像素+多光谱5波段）、RTK定位模块（精度±2cm）。项目验收时，所有性能指标均通过实测验证。复盘经验：需求拆解的关键在于“每一条用户需求都必须有对应的任务场景支撑，每一条任务需求都必须有对应的系统能力承接，每一条系统需求最终都要落到可测试的功能和性能指标上”。任何一层断裂，都会导致后期设计返工。

3.7 总结：需求拆解的核心逻辑