📚 课程目录第4章需求分析与规格定义

4、需求分析与规格定义：飞控系统需求捕获、功能需求与非功能需求、需求可追溯性、需求规格说明书编写要点

飞控系统作为飞行器的核心控制中枢，其开发质量直接决定了飞行安全与任务效能。在基于模型的开发（MBD）流程中，需求分析与规格定义是源头工程，这一阶段的质量缺陷若流入后续设计、实现与验证环节，修复成本将呈指数级放大。本章围绕飞控系统需求捕获方法、功能需求与非功能需求的界定、需求可追溯性机制的建立，以及需求规格说明书（SRS）的编写要点展开系统讲解，帮助工程师建立从“用户意图”到“可验证技术约束”的完整映射能力。

4.1 飞控系统需求捕获：从模糊意图到结构化条目

核心原理：需求捕获的本质是将利益相关方（主机厂、适航当局、飞行员、维护人员、任务规划方）的隐性期望与显性约束，转化为无歧义、可验证、可追踪的系统行为描述。飞控系统需求捕获具有典型的层次性：顶层来自任务需求与适航规章（如CCAR-25部、DO-178C），中间层来自飞机总体设计约束（如气动布局、舵面效率、结构限制），底层来自子系统接口与物理实现约束（如传感器量程、执行机构带宽）。捕获过程必须覆盖全生命周期视角，包括正常飞行包线、故障状态、维护场景和极端环境条件。

操作流程：推荐采用“五步捕获法”构建完整需求池：

利益相关方识别与访谈：建立干系人清单，按影响力和关注维度分类，设计结构化访谈提纲，重点挖掘“隐含需求”（如飞行员对操纵手感的偏好、地勤对自检时间的要求）。
场景与用例建模：使用SysML用例图描述飞行任务场景（正常起飞、巡航、复飞、单发失效、风切变、紧急下降等），每个用例关联前置条件、主流程、备选流程与异常分支。
规章与标准映射：逐条对照适航条款（如§25.671操纵系统、§25.1309设备系统安全）、行业标准（DO-178C软件等级、ARP4754A开发保证）和客户技术规范，提取强制性需求。
原型与仿真验证：通过快速原型（如Simulink桌面仿真）验证需求可行性，识别物理不可实现或成本过高的需求，提前与干系人协商调整。
需求分类与编号：按功能域（导航、制导、控制、健康管理）和需求类型（功能、性能、接口、安全、环境）建立编号规则，如FR-NAV-001、NFR-PERF-002。

  实战案例：某中型无人机飞控系统需求捕获

  背景：某无人机公司承接一款最大起飞重量150kg、续航8小时的察打一体无人机飞控系统开发。初始任务书仅提出“实现全自主起降与航线飞行”。

  捕获过程：团队通过5轮干系人访谈发现关键隐含需求——地面站操作员要求“链路中断后无人机自动返航且返航高度不低于300m”；维护人员提出“飞控计算机自检时间不超过30s，且故障代码可读”；适航工程师指出“需满足GJB 9001C质量管理体系对配置管理的要求”。通过场景建模补充了“单GPS丢失后采用惯性导航+磁罗盘降级模式”的需求。

  结果：最终形成87条功能需求、34条非功能需求、12条接口需求，其中23条来自规章映射，19条来自场景分析，避免了后期设计返工。

常见误区：需求捕获阶段过度依赖客户书面材料，忽视现场观察与操作员访谈；将设计解决方案（如“采用卡尔曼滤波”）误写为需求（应描述为“在GPS信号丢失后30s内保持导航精度≤10m”）；未区分“需求”与“期望”，导致后期需求变更频繁。

4.2 功能需求与非功能需求：定义、量化与优先级

核心原理：功能需求描述系统“做什么”，包括控制律计算、模式切换、故障检测、数据记录等行为；非功能需求描述系统“做得怎么样”，涵盖性能、可靠性、安全性、可维护性、环境适应性等质量属性。飞控系统的特殊性在于非功能需求往往比功能需求更关键——一个控制律功能完全正确但实时性不达标的系统，可能导致灾难性后果。因此，非功能需求必须量化到可测试的指标，并分配合理的容差范围。

关键量化方法：

需求类别	典型指标	量化示例	验证手段
实时性	周期、抖动、延迟	控制周期1ms，抖动≤50μs；传感器数据延迟≤5ms	逻辑分析仪、时序分析
可靠性	MTBF、失效率	MTBF≥2000h；单通道失效率≤1e-5/h	可靠性预计、加速寿命试验
安全性	失效概率、容错等级	灾难性失效概率≤1e-9/飞行小时	FTA、FMEA、故障注入测试
精度	稳态误差、超调量	姿态角稳态误差≤±0.5°，超调≤10%	HIL测试、飞行试验
环境适应性	温度、振动、湿度	-40℃~+70℃工作；振动5g@10-500Hz	环境试验、振动台测试

优先级划分策略：采用MoSCoW方法（Must have, Should have, Could have, Won't have）结合Kano模型。飞控系统中“Must”类需求包括安全关键功能（如失速保护、地形规避）和适航强制条款；“Should”类包括任务增强功能（如自动避障、编队飞行）；“Could”类包括舒适性功能（如平滑起降控制）。优先级划分需与客户确认，并记录在需求管理工具中作为变更控制依据。

经验提醒：非功能需求量化时避免使用“高”“快”“稳定”等模糊词汇。例如“响应速度快”应改为“从传感器数据更新到舵面指令输出，端到端延迟≤10ms”。同时，需明确测试条件（如“在满负载、双GPS失效、风速12m/s条件下”），否则验证阶段无法判定是否满足。

4.3 需求可追溯性：建立全生命周期关联网络

核心原理：需求可追溯性是指需求与其上游来源（客户需求、规章条款）、下游产物（设计模型、代码模块、测试用例、验证结果）之间建立双向关联。其价值在于：变更影响分析（当某条需求变更时，快速定位受影响的组件）、覆盖率验证（确保每条需求都有对应的设计与测试）、适航审查支持（向审查方证明需求被完整实现）。飞控系统通常要求100%的需求追溯覆盖率，即每条需求至少关联一个设计元素和一个测试用例。

追溯矩阵构建方法：

正向追溯：从需求出发，追踪到架构设计（如Simulink模型中的子系统）、代码实现（如C文件中的函数）、测试用例（如HIL测试脚本）。使用工具链（如DOORS、Jama Connect、Simulink Requirements）自动生成追溯链接。
反向追溯：从测试结果或缺陷报告出发，回溯到原始需求，验证需求是否被正确实现。反向追溯常用于故障定位和需求变更后的回归分析。
层级追溯：建立“系统需求→子系统需求→组件需求→设计元素→代码→测试”的多层追溯链，每层之间保持一致性。例如，系统级需求“具备自动着陆能力”分解为子系统需求“高度低于50m时启动拉平控制”“侧风≤8m/s时允许自动着陆”等。

  案例拆解：需求变更的追溯分析

  某飞控项目在HIL测试阶段发现，原需求“滚转通道带宽≥5Hz”在实际飞行中导致舵面高频抖动。客户提出将带宽需求调整为“≥3Hz且≤4Hz”。

  追溯分析过程：通过RTM定位到该需求关联的控制律设计模型（Simulink中的滚转控制器）、代码模块（roll_control.c中的PID参数）、测试用例（TC-HIL-ROLL-003）。评估影响：控制律参数需重新整定，代码中增益参数需修改，测试用例的通过判据需更新。同时发现该需求与“舵机寿命≥5000次循环”存在冲突，需同步调整舵机选型。

  结果：变更实施耗时3周，涉及5个设计文档、2个代码文件、3个测试用例更新。若无追溯矩阵，该变更可能导致遗漏测试用例，造成飞行安全隐患。

常见误区：追溯矩阵只做“需求-测试”单向关联，忽略设计中间层；追溯信息手工维护，版本更新后未同步；追溯覆盖率仅统计数量，未验证关联的有效性（如测试用例是否真正验证了需求的全部场景）。

4.4 需求规格说明书（SRS）编写要点

核心原理：SRS是需求工程的核心交付物，是设计、实现、验证、适航审查的共同基准。一份高质量的飞控SRS应具备完整性（覆盖所有功能与非功能需求）、一致性（无相互矛盾条款）、可验证性（每条需求可测试）、可修改性（结构清晰便于变更）和可追踪性（每条需求有唯一标识）。SRS的编写不是简单的需求罗列，而是对需求进行结构化组织、冲突消解和优先级排序后的正式文档。

SRS标准结构（参考ARP4754A与IEEE 29148）：

引言：编写目的、系统范围、术语定义、参考资料。
总体描述：系统环境、用户特征、运行场景、设计约束（如处理器性能、内存限制）。
功能需求：按功能域分组（导航、制导、控制、健康管理、任务管理），每条需求包含唯一ID、描述、优先级、来源。
非功能需求：性能、可靠性、安全性、可维护性、环境适应性、电磁兼容性。
接口需求：外部接口（传感器、执行机构、地面站）和内部接口（模块间通信协议）。
验证需求：每条需求的验证方法（检查、分析、演示、测试）和验证等级。
附录：需求追溯矩阵、术语表、假设与依赖。

编写要点与质量检查：

使用“应”（shall）表示强制性需求，“宜”（should）表示推荐性需求，“可”（may）表示可选需求。避免使用“等等”“类似”等模糊词汇。
每条需求只描述一个行为或属性，避免复合句。例如“系统应检测GPS信号丢失并切换至惯性导航模式”应拆分为“系统应检测GPS信号丢失（FR-NAV-001）”和“系统应在GPS丢失后切换至惯性导航模式（FR-NAV-002）”。
需求描述应包含可测量的性能指标，如“在风速≤15m/s条件下，自动着陆的接地垂直速度≤2m/s”。
明确需求来源与优先级，便于变更控制时评估影响。
编写完成后进行同行评审，邀请设计、测试、适航工程师共同参与，使用检查单逐条核对完整性、一致性和可验证性。

经验提醒：SRS编写过程中应同步建立需求管理基线，任何需求变更必须通过正式变更控制流程（CCB评审），并更新追溯矩阵。建议使用需求管理工具（如DOORS）而非Word文档，以便自动生成追溯报告和变更影响分析。对于飞控系统，建议将SRS与Simulink模型关联，实现“需求-模型”的实时同步验证。

  实战复盘：某通航飞机飞控SRS评审发现的问题

  评审中发现以下典型缺陷：①需求“系统应具备自动配平功能”未定义配平精度和响应时间，导致设计阶段无法确定执行机构规格；②非功能需求“系统应满足DO-178C DAL B要求”未分解为具体的软件过程需求（如测试覆盖率≥90%修正条件判定覆盖）；③接口需求中未定义与自动驾驶仪的握手协议，导致集成阶段通信故障；④追溯矩阵中3条需求未关联测试用例，适航审查时被列为不符合项。

  整改措施：补充配平精度指标（配平误差≤0.1°舵面偏角，响应时间≤2s）；将DAL B要求分解为12条可验证的软件需求；补充接口协议文档并增加集成测试用例；补齐缺失的追溯链接并增加自动检查机制。

需求分析与规格定义是飞控系统开发中最具杠杆效应的阶段。通过系统化的需求捕获、严谨的功能与非功能需求定义、全链路追溯机制以及高质量的SRS编写，能够显著降低后期设计变更成本，提升适航审查通过率，并为基于模型的开发流程奠定坚实的输入基础。工程团队应将需求工程视为持续迭代的过程，在项目全生命周期中保持需求的鲜活性与一致性。