一、引言

      需求的目的是建立一种精确、无歧义的沟通契约。它作为连接“问题提出者”与“问题解决者”的核心桥梁，旨在将模糊、主观的期望转化为客观、可量化、可验证的行为约束。一套高质量的需求能确保所有项目干系人对“软件应做什么、不应做什么、做到何种程度”形成一致、可执行的理解，从而为后续的设计、编码、测试以及项目验收提供唯一的、权威的依据，从根本上避免因沟通偏差导致的重构和失败。

      在机载软件（适航）领域中，这个概念被赋予了更严格的安全性与生命周期含义。根据DO-178C标准，需求不再仅是为项目服务，更是为安全负责。它被严格划分为两个层级：高层需求（High-Level Requirements, HLR），其来源于系统需求与安全分析，描述了功能模块或子系统应如何响应输入及防范危险，是连接飞机系统级功能与软件实现的安全桥梁；低层需求（Low-Level Requirements, LLR），则是对高层需求的精确派生与细化，必须细化到能够直接用于代码编写。在适航语境下，需求是构建完整可追溯性链条的基石：低层需求必须能追溯到高层需求，高层需求必须能追溯到系统与安全需求，并最终指向代码和测试用例。

      高层需求作为软件生命周期的起点，是连接系统需求与软件实现的桥梁，其质量直接决定了后续开发、验证乃至最终适航取证的成败。在航空机载软件的适航审定体系中，《机载系统和设备合格审定中的软件考虑》（DO-178C）是全球公认的“金标准”。本文将结合DO-178C的核心要求与工程实践经验，系统阐述如何编写高质量的高层需求。

二、先讲个真实的故事

      几年前，我司对某航空显示机载系统进行验证时，当时接到一项关键需求：“飞行中出现故障告警时，系统应清晰、准确地通知机组。”

      需求工程师将需求写为一句话：“告警信息必须直观易懂，确保机组能第一时间发现问题。”

      开发工程师看完，觉得不难实现。于是在系统代码里加了一段逻辑：“一旦检测到故障，屏幕中央立刻弹出红色大字体的告警提示，同时伴随蜂鸣报警。”

      测试工程师也按流程验证了：模拟故障触发，弹窗确实出现，声音也正常，就认为功能达标了。

      结果系统上机试飞，问题来了——机组反馈告警混乱。

      原来，红色弹窗在白天强光环境下根本看不清，而且只弹一个提示且提示时间比较短，机组分不清这是必须立即处理的A级故障，还是可稍后关注的B级提示。甚至有飞行员误把它当成常规系统提示，差点耽误了处置时机。

      后来我们复盘，发现问题根源：“直观易懂”是主观描述，机器和人对“直观”的理解完全不是一回事。

      于是我们把这条需求，细化成了三条可验证、可执行的明确标准：

      1.故障告警需按DO-178C软件等级分级显示：

         a)A级（灾难性）：屏幕顶部红色闪烁边框+急促蜂鸣，且无法被手动关闭，强制提醒机组；

         b)B级（严重）：黄色常亮提示+短促蜂鸣，允许机组在合适时机确认；

         c)C级（一般）：蓝色文字提示，仅记录在故障日志，不干扰主飞行操作。

      2.告警信息必须包含3个核心要素：

         a)故障类型（如“发动机温度异常”）；

         b)风险等级（明确标注“A级”“B级”）；

         c)处置建议（如“立即下降高度至3000米”）。

      3.系统需通过结构覆盖验证：

         a)所有告警逻辑的语句覆盖、判定覆盖达到100%，确保每一条告警的触发条件、显示逻辑都经过测试，无遗漏；

         b)非激活告警代码（如备用传感器故障提示）需单独标识，并通过分析证明不会误触发。

      修改需求后，这套系统通过了适航审定，试飞和实际运营中再也没出现过告警不清、误判的问题。

      原来做适航系统和做其他产品一样：只有把模糊的要求，变成精准、可量化的标准，才能真正保证飞行安全。

      这件事让我明白：好的需求，本质上是把模糊的人类语言，翻译成机器和团队都能执行的动作。

三、好需求的五个特征

      不管是写一个功能需求、一个接口需求，还是一整套系统的需求，通常都有以下五个共同特征：

      1.Clear：清晰无歧义，每个人读到的都是同一个意思；

      2.Logical：逻辑完整，正常路径、异常路径、边界条件都覆盖；

      3.Atomic：原子的，每条需求只描述一个独立、不可再分的行为（不使用“并”、“且”、“同时”等连接词捆绑多个动作）；

      4.Verifiable：每一条需求都必须能被客观地测试或验证，能写出明确的“通过/不通过”标准；

      5.Traceable：软件需求必须能向上追溯到系统级需求，向下关联到设计，形成完整的追溯链。

      下面将逐条展开聊一聊。

1.Clear：清晰无歧义

      清晰 ≠ 详细，清晰 = 无歧义。先看两个示例：

      错误示例：

      系统应快速响应用户操作。

      正确示例：

      用户点击按钮后，界面在 200ms 内给出视觉反馈（按钮状态变化）；完整操作结果在 2 秒内返回并显示。

      用量化代替模糊词。“快速”、“友好”、“强大”、“易于使用”——这些词在需求里几乎都是“坑”。

2.Logical：逻辑完整

      完整 ≠ 冗长，完整 = 覆盖所有路径。

      大多数人只写“快乐路径”（Happy Path）：用户正常输入 → 系统正常返回。

      但真正让项目延期、线上出事故的，往往是那些“不快乐”的路径。

      写每一条需求时，多问三个问题：

      a)如果用户不按套路来呢？（输入非法格式、重复提交、中途取消。）

      b)如果外部依赖出问题呢？（网络超时、数据库锁、第三方接口挂了。）

      c)如果并发/极限情况呢？（同时1000人操作、数据量巨大。）

      把这些回答写进需求，你的需求文档价值翻三倍。

3.Atomic：原子的

      原子性 ≠ 简单，原子性 = 单一行为。先看两个示例：

      错误示例：

      系统应检测到火警信号并自动启动灭火装置，同时向驾驶舱发出声光告警，并将事件记录到非易失存储器中。

      正确示例：

      1.当检测到火警信号时，系统应在 100ms 内向驾驶舱发出红色闪烁告警灯和连续蜂鸣声。

      2.当检测到火警信号时，系统应在 200ms 内自动启动灭火装置。

      3.当灭火装置启动后，系统应在 500ms 内将事件（时间、火警源、动作）写入非易失存储器。

      需求原子性，可带来三个好处：可验证性增强、追溯性明确、变更管理清晰。原子性要求每条需求只描述一个且仅一个系统行为。实践中，应尽可能减少“并”、“且”、“同时”、“以及”等连接词的使用，提升需求的原子性。

4.Verifiable：可验证

      可验证 = 自带“裁判标准”。一条好需求，应该能直接变成测试用例。

      推荐一个我用了很久的模板：Given-When-Then：

      a)Given（给定），明确了运行环境与配置，排除干扰项；机载显示系统处于正常飞行状态。

      b)When（当），精准定义了触发条件（与 DO-178C 的判定覆盖对应）系统检测到主传感器数据连续 3 帧无效或超时（即判定条件触发）。

      c)Then（那么），列出了可观测的结果，测试人员可通过仿真设备逐一验证，避免“主观判断”引发适航争议。

      根据这个模板，你可以把任何适航相关需求转化为可直接用于测试和审定的标准。

5.Traceable：可追溯

      可追溯 = 不让需求“断线”；追溯不是做给审查人员看的，而是为了回答两个问题：

      a)这个需求到底实现了没有？（正向追溯：需求 → 设计 → 代码 → 测试）

      b)这段代码/这个测试是为了哪条需求？（反向追溯：代码/测试 → 需求）

      最简单的做法：给每条需求编号（比如 REQ-LOGIN-01），在设计、代码注释、测试用例里引用这个编号。

四、为什么要写好需求？

      需求是机载研发与适航取证的源头基线、是机载系统研发与适航取证的根本依据。依据DO178C要求，设计、开发、测试、验证及追溯工作，全部围绕需求展开。精准、完整、可验证的需求，能够统一上下游研发标准，明确功能、安全、接口与失效约束。

      若需求定义粗糙、表述模糊、缺少安全考量，会导致设计偏差、开发返工、测试失效，还会造成追溯断裂，引发适航审查整改。做好需求管理，可从源头规避缺陷，减少迭代整改，控制项目周期与人力成本，是保障产品安全合规、高效完成适航取证的核心关键。

1.减少返工，大幅降低成本（最直接）：

      需求是全流程的工作基准。低质需求极易造成设计理解偏差、开发逻辑反复调整。若问题流转至集成测试与适航取证阶段才暴露，涉及整改的范围广、修复代价极高，从测试用例到需求，将会引发大规模返工。

      高质量需求提前识别风险与接口问题。在前期锁定设计边界，减少后期变更与缺陷修复，降低回归测试工作量，规避适航审查整改，有效压缩人力投入与项目周期，从源头大幅控制研发与取证成本。

      适航项目的返工成本远高于普通项目，避免或者减少返工，就是降低成本的直接表现。

      在航空适航工程DO-178C体系下，所有设计、编码、测试、取证工作都必须完全基于需求开展，需求是全项目的源头根基。适航行业有公认工程规律：问题在需求阶段整改成本最低，一旦流入开发、测试乃至取证环节，返工成本会成倍暴涨，而优质需求能从源头减少或杜绝后续隐患。

      比如某机载告警软件初期需求只写“异常情况及时报警”，没有明确报警阈值、触发时序、失效降级逻辑。开发完成后才发现告警时机不符合机载运行要求，不仅要重构代码逻辑，还要重做所有测试用例、补全适航追溯矩阵，临近取证阶段被迫大范围整改，耗费数倍人力和工期。

      简单来说，好需求可以避免大多数后期推倒重来式返工的可能，大幅减少重复测试、整改取证的额外开销，是适航项目降成本、控周期、稳取证最核心、最高效的手段。

2.满足DO‑178C规定，通过适航审查（强制性）

      好需求 = 直接满足适航审计要点，不用反复补文档、补测试、补追溯。

      DO-178C软件适航审查的核心核查目标，不是代码功能好坏，而是需求合规性与全链路追溯有效性。适航审查所有检查条目，全部围绕需求的完备性、可验证性、可追溯性展开，需求质量直接决定审查通过概率。

      DO-178C强制要求：每条需求必须清晰无歧义、可量化、可测试，覆盖正常情况、异常情况与安全降级逻辑，且实现需求、设计、代码、测试用例双向完整追溯。好的需求，从编写阶段就严格贴合DO-178C要求，前期把功能指标、接口定义、安全约束、失效处理全部写明确，通过需求评审提前消除矛盾、缺失和模糊表述，让后续开发和测试有据可依，全程按适航标准基线推进。

      需求质量差是审查不通过的头号原因。例如某机载控制软件，早期需求写的笼统，未明确故障响应时序和失效安全逻辑，也无法拆解对应测试项。到局方审查阶段，审查员直接判定需求不可验证、追溯链断裂，开具整改项，必须重写全套需求、重做所有测试、重建追溯矩阵，导致取证停滞、项目严重返工。

      反之，高质量需求前期一次性把DO-178C合规要求固化到位，全流程追溯链路天然闭环，无审查卡点、无后期整改。做好需求，就是从源头满足DO-178C硬性规定，是软件一次性顺利通过适航审查最根本、最关键的保障。

3.提升软件安全性，避免机载事故（根本目的）

      好需求 = 把安全写进源头，从根上避免危险行为。

      绝大多数机载软件安全隐患和飞行事故隐患，根源都不是代码bug，而是前期需求缺失和安全逻辑遗漏。DO178C核心宗旨就是通过严控需求基线，从源头杜绝系统性安全风险，保障机载软件在任何工况下都不会引发危险失效。

      好的需求，不仅定义正常功能，更强制覆盖故障检测、故障隔离、安全降级、失效安全保护等高危场景，把所有极端飞行工况、软硬件异常、人机交互边界全部提前量化写入需求。开发和测试人员严格按照安全需求设计和验证，软件遇到异常时会按预设安全逻辑兜底，不会出现失控、误判、误操作等情况，从根本上提升机载软件运行安全性。

      反之，需求写得粗放、只重功能不重安全，会埋下致命隐患。例如某机载飞控辅助软件，早期需求只要求“正常计算姿态数据”，未定义数据异常、数据丢包和超限保护需求。试飞测试中传感器瞬间数据跳变，软件没有安全处置逻辑，直接输出错误控制指令，险些引发飞行姿态偏移险情。事后整改核心就是补充安全防护类需求，增加超限判断、数据校验、故障降级保护，彻底消除安全风险。

      机载软件安全靠后期改代码补救远远不够，只有前期需求把安全边界、失效防护、兜底策略全部定义到位，才能从源头规避致命缺陷，杜绝机载软件导致的飞行安全事故。

4.团队高效协作，减少沟通成本

      需求不仅是技术规格，更是跨角色协作的“通用语言”。当每条需求都清晰、原子、可验证时，产品、开发、测试以及适航审定人员对同一句话的理解将完全一致，从而显著降低沟通摩擦。

      产品/开发/测试/适航审定 理解完全一致

      一份好的需求消除了自然语言中的主观解释空间。例如，“系统应快速响应用户操作”会让产品经理认为“越快越好”，开发理解为“可能几百毫秒”，测试设定“1秒内算快”，而适航审查员无法判断其符合性。相反，“用户点击按钮后，界面在200ms内给出视觉反馈”这一表述，四类角色无需讨论即可获得相同结论。

      不用开会吵架“你说的直观易懂是什么”

      模糊词汇（如“友好”、“合理”、“适当”）是跨团队争论的根源。为了避免反复开会澄清，需求中应直接写出可量化的指标。

      需求即合同，所有人按标准执行

      在机载软件研制中，需求是设计、编码、测试和适航审定的法定依据。一旦需求被确认，它就具备“合同”效力：开发人员必须实现它，测试人员必须验证它，适航审查员必须审核它。任何一方都不能随意解释或修改。这种“契约化”的工作模式，从根本上杜绝了“我觉得”、“我以为”带来的返工和争议，使团队协作真正转向基于事实和标准的执行。

五、工程示例

      光说不练假把式，接下来我们看一下具体示例。

1.实例1：清晰无歧义

      错误示例：

      当飞机速度较快时，软件应调整燃油流量。（条件和输出均不清晰，未量化）

      正确示例：

      [HL-001]：当空速大于400节时，软件应增加燃油流量10%，以维持推力平衡。

      [HL-002]：当空速小于等于400节时，软件应恢复燃油流量至基准值。

      （条件清楚，逻辑清晰，没有歧义）

2.实例2：逻辑完整

      错误示例：

      [HL‑001]：当油温＞120℃时，软件应点亮“超温”红色指示灯并输出警告报文。（问题：逻辑不完整，缺少油温≤120℃的处理逻辑）

      正确示例：

      [HL‑001]：当油温＞120℃时，软件应点亮“超温”红色指示灯并输出警告报文。

      [HL‑001]：当油温≤120℃时，软件应点亮“超温”绿色指示灯。

      （明确了所有条件下软件的处理逻辑→ 逻辑完整）。

3.实例3：原子的

      错误示例：

      [HL‑001]：当油温＞120℃时，软件应点亮“超温”红色指示灯、输出警告报文、向航电系统反馈油温过高警告。

      （问题）

      正确示例：

      [HL‑001]：当油温＞120℃时，软件应点亮“超温”红色指示灯。

      [HL‑002]：当油温＞120℃时，软件应输出警告报文。

      [HL‑003]：当油温＞120℃时，软件应向航电系统反馈油温过高警告。

4.实例3：可验证

      错误示例：

      软件应快速响应指令。（没有量化指标，不具备验证性）

      正确示例：

      软件在接收到输出指令后，应在50ms内输出响应数据。

5.实例4：可追溯

      错误示例：

      系统需求[SYS‑001]：软件应在高度＞10000ft 时触发警告。

      高层需求[HL-001]：软件应根据高度数据，发出提示。

      （[HL-001]未体现10000ft、未体现警告类型、未体现触发条件 → 不符合系统要求）

      正确示例：

      系统需求[SYS‑001]：软件应在高度＞10000ft 时触发警告。

      高层需求[HL‑001]：当座舱高度＞10000ft 且持续≥2s，软件应向警告面板发送“高度警告激活”指令（来源：SYS‑001）。

六、总结

      写需求不是写小说，而要像写合同——清晰一致、可执行、无歧义。

      好需求的本质，是把模糊的自然语言，转化为机器可执行、团队无争议、审定可采信的标准化工程规则，是机载系统研发与适航取证的源头基线与核心依据。

      异常路径与安全边界是需求质量的真正考验，把失效、降级、边界与异常处理写进需求，比堆砌正常流程更具工程价值。高质量需求从源头降低返工成本、保障适航合规、筑牢安全底线、提升协同效率，直接决定项目交付质量、研发周期与取证成败。

      好的需求，既是写给研发与测试的工程执行手册，也是写给适航审查的合规证明文件，更是保障飞行安全不可替代的关键工程资产。