搞硬件的兄弟们应该都有同感画板子、调时序、改代码这些活再难也有章可循真正让人头大的往往是需求本身说不清楚。尤其是军用信号处理板这种项目系统端抛过来一句话“要能处理宽带阵列信号”底下做板级的人直接懵掉——带宽多少通道数几个处理延迟容忍多少接口用什么协议这些不掰扯清楚后面每走一步都是坑。我这些年参与过好几型信号处理板的研制踩过不少“需求模糊导致返工”的雷之后才慢慢体会到需求工程不是流程上的花架子它是能实实在在救命的。所谓板级需求规格书说白了就是把系统级需求逐层拆解落到一块具体的信号处理板上形成一份可检查、可验证、可追溯的书面约定。它解决的核心问题就一个让做硬件、做FPGA、做软件的人和提需求的总体单位在动工之前就对“做什么、做到什么程度”达成一致。这篇文章我不打算讲那些教科书里的理论框架重点分享我在军用信号处理板项目里把需求工程落地成板级需求规格书的实际经验包括怎么拆需求、怎么写条目、怎么把非功能指标写成能验证的话、以及怎么用追溯矩阵把这份文档盘活。适合正在做雷达、电子战、通信类信号处理板卡的硬件工程师、FPGA开发、系统工程师以及刚接触军用型号研制的朋友参考。1. 需求工程在军用信号处理板上到底要解决什么问题1.1 军用信号处理板的特殊性很多人觉得需求工程是个管理问题跟技术关系不大这就大错特错了。拿民用板卡来说需求相对清晰性能指标可以从产品手册和使用场景里直接推出来需求分析更多是确认“选什么器件、用什么架构”。但军用信号处理板完全不同它处在整个装备系统的信息中枢位置前端连着天线和射频通道后端连着显控和数据链侧面还要跟电源管理、健康管理、时间同步等多个分系统交互。这种角色决定了它的需求有三个鲜明特点。第一是需求来源高度复杂。一条板级需求可能来自系统总体对整机战技指标的要求可能来自算法团队对数据精度和吞吐量的要求可能来自结构设计对板卡尺寸和散热的约束还可能来自使用维护部门对故障隔离和更换便捷性的要求。这么多渠道的需求汇到板卡这一级如果不做系统的收集和梳理漏掉任何一条都可能在后期变成大问题。第二是指标之间强耦合。军用信号处理板的处理能力、功耗、体积、散热通常是互相打架的。想要更高的运算吞吐就要上更大规模的处理芯片功耗和散热立刻上去想要宽温工作芯片选型和降频设计就受限。需求工程的职责之一就是把这堆矛盾摆在台面上通过权衡分析确定合理的指标基线而不是等板子做出来才发现压不住温度。第三是验证环境特殊。板卡最终要在振动、湿热、高低温、强电磁干扰等恶劣环境下稳定工作很多需求不是实验室里测一遍就能证明满足的需要专门的试验方法和工装。如果需求条目本身写得模棱两可后面做验证时连判据都没有质量部门想把关都无从下手。正因为有这些特殊性板级需求规格书才不能简单照抄系统需求必须经过真正的“需求工程”加工一层层落到可以设计、可以测试的颗粒度。1.2 不做板级需求规格书的真实代价我见过不止一个项目跳过板级需求规格书直接进入详细设计觉得“反正板子嘛原理图一画、PCB一布、代码一写就完事”。前期的确看起来省了不少时间但几乎无一例外在后面某个节点以更惨烈的方式把时间还了回来。最典型的翻车场景是接口定义不清。板卡上用哪个Bank的LVDS、谁做主谁做从、数据对齐方式是什么样、错误处理怎么触发这些如果没在规格书里写清楚硬件工程师和FPGA工程师各自按照自己的理解做联调时就是一场灾难。两个人拿着逻辑分析仪对着波形一点点比对最后发现是某一端的时序理解和需求文档差了一个时钟周期。这种问题改起来不难但定位起来非常耗时。还有一种翻车更隐蔽——非功能需求被遗忘。比如某块信号处理板要求平均故障间隔时间不低于多少小时结果设计时压根没做降额分析器件选型余量不足高温摸底试验直接挂掉这时候再改设计PCB要重新布局结构散热要重新仿真成本完全失控。需求工程的价值就在于此它强制你在投入真金白银做硬件之前先把脑子里的想法变成白纸黑字的、可检查的约定。磨刀不误砍柴工这句话用在需求阶段再合适不过。2. 落地第一步需求来源、干系人与捕获方法2.1 干系人清单谁的需求算数开始写规格书之前第一件事不是动笔而是列干系人清单。军用信号处理板的需求干系人远不止“总体单位”这一个角色。我习惯把干系人分成四个层级。第一层是系统总体或用户代表他们提出的是装备层面的使用需求比如探测距离、处理帧率、工作模式切换时间。这些需求通常不会直接写“板卡需要什么”需要做层层分解才能落地到板级。第二层是分系统设计师包括雷达总体、电子战总体、通信总体里负责信号处理分系统的人他们往往已经给出了初步的算法分解和处理资源估算这是板级指标的重要输入。第三层是板卡的使用维护方他们会告诉你外场使用时的真实场景比如板卡要支持快速更换、故障指示灯怎么设计、测试接口放哪里方便。第四层是内部团队成员包括硬件工程师、FPGA工程师、嵌入式软件工程师、结构工程师、工艺工程师他们的意见直接决定了需求在实现层面的可行性。列这份清单有个实际作用避免“需求唯一来源”的错觉。军用项目里指令链长中间任何一层都有可能对需求做自己的解读。把干系人摆出来逐个确认他们对板卡的期望和限制才能保证需求池是完整的。作为需求工程师还需要特别关注那些“不会主动提需求”的干系人。比如生产车间的工艺人员他们关心的可制造性、可测试性需求往往要到投产时才会爆发比如售后维修人员他们关心的模块级隔离和故障定位便利性经常被设计阶段忽略。把这些人的经验前置到需求阶段比后面反复改设计划算得多。2.2 捕获需求的高效手段不只是开会需求捕获最土但最有效的办法是结构化的干系人访谈。别一上来就问“你对板卡有什么要求”这种开放式问题得到的信息多半泛泛而谈。我常用的做法是带着问题清单去访谈清单上按主题分类列好问题比如“前端ADC采集支持哪些采样率”“数据输出的峰值带宽需求是多少”“脉压系数是存在板内还是由上位机加载”。问题越具体对方越容易给出可操作的答复。除了访谈还有一个很值得投入的手段是场景分析。找使用方要几个典型任务剖面把板卡在任务中的角色一步步走一遍每个环节涉及什么功能、需要什么资源、产生什么约束就全浮出来了。比如一个典型的雷达信号处理任务剖面可能包含搜索、截获、跟踪、识别几个阶段每个阶段对处理板的需求都不一样。搜索阶段强调大范围数据吞吐跟踪阶段强调低延迟输出识别阶段可能强调大存储和大模型加载能力。这些差异不通过场景推演很难被完整挖掘出来。原型验证也是需求捕获的重要辅助手段。有些指标光靠讨论说不清楚比如“数字波束形成支持多少波束”这跟运算资源和数据流设计强相关不如搭一个简化的算法原型在现有平台上跑一遍实测一下资源占用和时间消耗用数据来反推合理指标。这种做法在信号处理板需求阶段特别实用能避免拍脑袋定指标也能让后续设计阶段的可行性更有保障。捕获到的原始需求必须原原本本记录不要急着整理和筛选。哪怕是听起来很不靠谱的一条也要先进需求池里待着后面再通过评审、权衡、排序来决定去留。需求捕获阶段最忌讳的事情就是在源头就筛掉“自认为不现实”的需求因为你对背景信息的掌握很可能不如提需求的人全面。3. 板级需求规格书怎么写结构、条目与质量属性3.1 可直接复用的规格书章节结构板级需求规格书没有强制统一的模板但根据我在多个型号项目里的经验一套好用且容易通过评审的结构大概是这样章节内容要点1 范围规格书适用范围、板卡代号、与系统/分系统需求的关系2 引用文件系统需求规格书、接口控制文件、相关军用标准3 术语和缩略语统一术语避免同一概念多种叫法4 板卡概述板卡功能定位、工作原理简述、对外接口总览5 系统级约束供电、尺寸、环境、可靠性的顶层要求6 功能需求按信号处理功能域划分的需求条目7 接口需求外部接口(电源、时钟、数据、控制等)的详细约定8 非功能需求性能、环境适应性、可靠性、维修性、测试性、安全性、EMC等9 设计约束器件选型、国产化率、降额要求、热设计约束等10 验证要求每个需求的验证方法和验证阶段11 需求追溯板级需求与上层需求的追溯矩阵12 附录计算书、仿真报告、风险分析等支撑材料这个结构不是我拍脑袋想的它的逻辑是“先立边界、再讲功能、再抠接口、再补非功能、最后管验证”。评审专家拿到这份文档能很快找到自己想看的内容。实际项目里我还会根据具体板卡类型做微调比如ADC/DAC资源比较复杂的板卡会把“模拟接口需求”单独提成章节避免混在数字接口里讲不清楚。3.2 需求条目的五要素写法比结构更重要的是需求条目的写法。板级需求规格书动不动上百条需求如果每条都写得含含糊糊那份文档就是一堆废纸。我总结了一套五要素写法写每一条需求时都对照检查。第一条是“唯一标识”。每条需求必须有唯一编号一般用“需求类别缩写序号”的格式比如BRD-F-001表示板卡功能需求第1条。别小看这个编号它是后续追溯矩阵、评审意见、变更控制的基础。没有编号的需求评审时专家提了意见你都不知道说的是哪一条。第二条是“需求陈述”。用一句完整的话说清楚“板卡应当具备什么能力”或“板卡应当满足什么约束”。这里要特别注意用词规范“应”表示强制要求“宜”表示建议要求“可”表示可选要求三种词性不能混用。我见过不少需求文档把“应”和“宜”混着写评审时被专家拎出来点名批评。第三条是“理由/来源”。写清楚这条需求是从哪一层需求分解来的或者来自哪个干系人的哪条原始诉求。这个信息对后期追溯和变更影响分析极其重要。比如某条数据吞吐需求来自系统总体对扫描周期的要求将来如果扫描周期指标调整就能顺着追溯关系快速评估对板卡吞吐量的影响范围。第四条是“验证方法”。说明这条需求用什么方法来验证一般包括分析、演示、检查、测试四类。写验证方法的好处是倒逼需求写得更可度量。如果一条需求连怎么验证都说不清那它很可能本身就是模糊的。第五条是“优先级和来源”。标明这条需求属于“必选”还是“可选”在资源冲突时谁是首先被妥协的对象。军用项目中优先级排序需要经过评审确认不能由需求工程师一个人拍板。我用一个实际例子说明五要素的写法。不要写“板卡应能处理宽带信号”这种话听起来像需求实际没法设计也没法验证。应该写成标识BRD-F-017需求陈述板卡应在单通道接收带宽不低于200MHz、采样率不低于500MSPS的条件下实时完成1024点脉冲压缩处理处理输出延迟不大于50微秒。理由/来源来源于系统需求SR-SP-023对最小可检测信噪比的分解及算法分系统对脉压延迟的约束。验证方法使用标准测试向量注入板卡对比输出结果与Matlab参考模型的偏差使用示波器测量输入触发到输出有效之间的延迟。优先级必选。这样一条需求写下来硬件工程师知道前端采集带宽和采样率要求了FPGA工程师知道脉压点数和输出延迟要求了测试工程师知道怎么验收了所有人看到的都是同一句话理解上不会有歧义。4. 功能性需求分解实例从系统需求到信号处理板配置4.1 一个信号处理链路需求的分解实例功能性需求的分解是板级规格书里最见功力的部分。拿一个典型的相控阵雷达信号处理板来举例。系统层面只给了一句话完成多波束回波的数字波束形成和脉压处理。这句话距离“能做板子”还差着十万八千里。第一步要分解“多波束”。多波束是几个波束每个波束对应多少通道阵元数是多少如果系统说“支持16个波束每波束64通道”那板级就要算一笔账64通道的数据进来每通道采样率多少、位宽多少16个波束是同时计算还是分时计算数据总吞吐量是多大。这一步一算ADC通道数、FPGA资源规模、DSP处理器数量基本就定了。第二步要分解“回波”的数据格式。回波数据是ADC直接采出来的中频信号还是经过下变频后的基带I/Q数据这两种情况对板卡的前端接口设计要求完全不同。前者需要板卡自带变频和滤波电路后者则可能直接从数字中频接口接入。很多接口需求的分歧恰恰出在这个层面上没有对齐。第三步要分解“脉压处理”的细节。脉压的点数是多少窗函数有没有特殊要求是时域卷积还是频域相乘输出需要保留原始数据还是只保留处理结果脉压系数怎么加载和更新这些问题每一个都能影响处理资源的估算和存储结构的设计。经过这几层分解一句系统需求就能变成一张清晰的板卡功能清单ADC采集模块需要支持什么采样率预处理FPGA需要完成什么抽取滤波和格式转换信号处理FPGA或DSP需要实现多少点的脉压、并行处理几条链路输出接口需要以什么帧率把结果送给显控。每一条功能再按照五要素写法落成需求条目板级规格书的主体框架就搭起来了。分解过程中我发现一个特别值得注意的点一定要把“数据流”画清楚但不要画成架构设计图而是画成数据流图。需求规格书里讲的是“什么数据从哪来到哪去、经过什么处理”而不是“用哪片FPGA、挂在哪个总线上”。确定用FPGA还是DSP、用A家还是B家芯片那是方案设计阶段的事需求阶段过早陷入实现细节反而会限制设计空间。4.2 接口需求的描述规范和时序约束接口需求是板级规格书里最容易被写坏的部分也是联调阶段最容易出问题的部分。我见过太多需求文档里写“与外部系统接口满足相关协议要求”等于什么都没写。板级接口需求至少要覆盖四块内容电气接口、逻辑接口、时序接口、异常处理。电气接口描述的是电平标准、阻抗要求、驱动能力、供电电压范围。比如LVDS接口要写明是标准的LVDS还是Bus LVDS匹配电阻放在哪一端共模电压范围是多少以太网接口要写明是千兆还是万兆用铜缆还是光模块支持哪些自协商模式。逻辑接口描述的是数据格式和控制协议。数据是并行还是串行字长多少字节序是大端还是小端帧头是什么有效标志位怎么拉高拉低。控制协议用什么命令字格式地址映射如何分配读写时序有什么要求。这些内容最好做成一张接口列表加上详细的文字说明必要时配简单的波形示意。时序接口是军工项目中经常被忽略、但联调时最容易扯皮的部分。数据建立时间和保持时间要求什么量级接口时钟频率多少数据相对于时钟的相位关系是什么多板卡之间级联时同步信号怎么对齐这些必须量化到具体数值。比如“FPGA输出的同步脉冲上升沿与输入数据帧头对齐抖动不超过±2ns”这种描述才是有工程约束力的。异常处理则常被遗忘在角落。链路断开怎么上报、数据越界怎么处理、接口超时怎么恢复、外部复位信号和内部看门狗的关系是什么。这些需求平时看着不显眼一旦外场出了问题工程师翻遍文档找不到约定只能临场拍脑袋。需求阶段多花一小时把这些写清楚调试阶段可能省下好几天。5. 非功能需求军用板卡的“隐藏生死线”5.1 环境适应性、可靠性与维修性功能需求是板子的骨架非功能需求是板子的免疫系统。军用信号处理板的环境适应性需求直接决定板卡能不能在真实战场环境下活着完成任务这部分指标必须逐条明确。环境适应性包括工作温度范围、存储温度范围、振动冲击条件、湿热盐雾要求等。这些指标可以引用相关标准但不能只写“满足GJB相关要求”要把具体等级和条件写清楚。比如工作温度是−40℃~65℃还是−55℃~70℃振动条件是第一类还是第二类随机振动还是正弦扫频量值多少。不同等级对应完全不同的器件选型、散热设计和结构加固方案需求清晰了设计才好开展。可靠性需求在军用项目里的关键指标是MTBF即平均故障间隔时间。比如要求MTBF不低于5000小时设计人员就要针对关键器件做降额设计对功耗大的器件做热仿真对单点故障环节做冗余设计。可靠性不只是个数字它会实实在在影响原理图的每一个器件选型。另外还要注意可靠性分配的问题整机的MTBF分配到各个分机、再分到板卡每一级都要认领自己的指标板级规格书里要引用清楚分配结果。维修性需求常常被硬件设计人员当成“别人的事”实际上维修性设计直接落在板卡上。板卡外形尺寸能不能单手插拔、测试点是否预留、故障指示灯是否可见、关键器件是否便于更换这些都是维修性需求的具体表现。外场更换一块处理板理想情况是拧两颗螺钉、拔下光口和电源、几秒钟搞定。如果需求阶段不考虑这些设计出来一个需要拆12颗螺钉、还藏在机箱最深处的板卡后面的使用维护成本就大了。5.2 测试性、安全性与电磁兼容测试性需求的核心是内建自测试(BIT)能力。军用信号处理板一般都要求具备上电BIT、周期BIT和维护BIT等不同层次的测试功能。规格书里要明确哪些模块需要纳入BIT覆盖比如ADC自检是不是用内部测试码、FPGA的逻辑资源自检覆盖率要求多少、对外通信链路能不能自发自收。这些需求会直接影响板卡上的硬件资源分配比如要不要为BIT功能单独设计信号回路、要不要预留测试接口位置。安全性需求关注的是设备和人员安全。板卡在故障状态下不能引起火灾、不能冒烟、不能对操作人员造成伤害关键电路要有过流保护、反接保护、热保护措施。有些信号处理板要处理高压模拟信号输入通道的保护要求比如防浪涌、防过压、防静电等级就必须在需求阶段明确。这些需求同时影响原理图设计和PCB布局布线。电磁兼容性(EMC)是军用信号处理板的老大难问题。高速数字信号处理板本身就一个“污染源”高频时钟、高速串行数据会往外辐射能量同时又容易受外部电磁场干扰。板级规格书里要明确传导发射、辐射发射、传导敏感度、辐射敏感度的指标要求还要根据安装位置确定是否需要加固设计比如外壳要不要导电密封、连接器需不需要屏蔽处理。关于EMC有一个很重要的经验EMC需求必须是板级的、可测的不能只抄系统级指标。系统整机过了EMC试验不代表单板同样满足要求反过来单板的EMC指标也不能简单地取整机指标需要留出一定余量。需求阶段就要和试验方确认清楚板卡在什么状态下进行EMC测试加不加散热器带不带外壳这些条件不同结果可能差很多。6. 需求验证与追溯把规格书变成闭环的起点6.1 需求验证矩阵建立方法规格书写完不是终点只是起点。如果没人去验证需求有没有被实现、拿什么证明被实现那这份规格书迟早沦为评审会上专家翻一翻、之后锁进柜子里的装饰品。需求验证矩阵(RVM)就是解决这个问题的工具。建立RVM的第一步是把规格书里的每一条需求按编号放进表格里。然后为每一条需求选定验证方法一般有四类分析通过计算、仿真、类比来证明演示通过实际操作演示功能满足要求检查通过查阅设计文档和外观检查来确认测试通过仪器设备对板卡进行定量或定性测试。对于军用信号处理板测试类验证占大头但不是所有需求都要等到板卡实物出来再验。有些需求在设计阶段就能通过分析和仿真提前确认比如FPGA资源占用率是否满足要求可以通过综合报告提前验证热设计是否满足要求可以通过热仿真提前验证。把这些验证点前置能大大降低后期实测试的风险和成本。RVM的行是需求条目列是验证方法、验证时机、验证条件、验证结果、验证记录编号、责任人。建立这个矩阵的过程也是再次审视每条需求是否可验证的过程。如果某条需求在RVM里怎么都找不到合适的验证方法那就要回头改写需求本身了。6.2 从需求变更到回归测试的闭环军用项目中需求变更是常态最怕的是漏改或者改了这头忘了那头。需求追溯矩阵在这里的价值就体现出来了。所谓追溯就是建立“系统需求—板级需求—设计实现—测试用例”之间的双向关系。从任何一条系统需求出发能查到它分解到哪些板级需求对应到哪个模块的设计最后用哪个测试用例来验证反过来说从任何一条测试用例出发也能反查到它验证的是哪条板级需求、跟哪条系统需求相关。变更管理时这个追溯关系就是导航图。比如系统需求里把波束数量从16改成24通过追溯矩阵一查就能立刻找到受影响的板级需求、需要改动的FPGA模块、需要增加的测试项。没有这个关系网就只能靠项目成员的个人记忆力漏掉一两个关联项几乎不可避免。需求追溯矩阵可以做成文档形式也可以用DOORS等专用需求管理工具来做。工具不是关键关键是把关系维护好。我见过不少项目用Excel做追溯矩阵照样运行得很好因为团队真正在维护它。也见过上了商业工具但没人更新里面的链接关系最后照样形同虚设。在整个开发流程里我建议把需求评审和需求确认做成多个节点的活动不要指望着一次评审就结束。需求阶段内部评审是一轮和硬件、软件详细设计之间的衔接评审是一轮板卡联调完成后的需求确认试验又是一轮。每一轮都回归到规格书本身看看有没有遗漏、有没有歧义、有没有做不到的地方。这样滚动下来规格书才真正成为项目的活文档。7. 需求管理工具与团队协作的一些心得工欲善其事必先利其器。项目规模小、需求条目两三百条的时候Excel完全够用透视表和筛选功能就能做基础的追溯和统计。但需求超过五百条、变更频繁的时候建议上专业的需求管理工具。我实际用过的DOORS、Polarion等工具核心优势不是“存放需求”而是把需求变更后的影响分析变成自动化的过程改一条上游需求所有关联的下游条目都会被标红提醒。不过工具归工具需求工程最关键的还是人的协作。我观察到一个规律需求工程做得好的团队开会讨论的往往是“指标合不合理、验证怎么开展、冲突怎么权衡”做得不好的团队开会基本都在互相指责“你没说清楚、我没理解对”。前者是流程和规格书在起作用后者是文档质量撑不住场面。在军用项目里还要特别重视评审专家的作用。板级需求规格书的评审不只是走流程专家们往往能从各自的专业视角指出盲区——做结构的老法师会提醒你连接器安装方式的细节做可靠性的会帮你把关降额系数做试验的会告诉你某项指标现在这个写法根本没法定级。把评审意见认真整理进需求条目和RVM规格书的含金量就能提高很多。另外还有一条经验需求条目要有“状态管理”。从初始起草到评审通过到被设计基线锁定再到后续可能的变更每个阶段要有明确状态标识。我习惯用“草稿、已评审、已基线、已变更、已废弃”这样的生命周期状态来管理每一条需求。这样任何时候翻开文档都能准确看出哪条需求是有效的、哪条已经被替代了不会出现“文档里同时存在两个互相矛盾的版本”这种混乱。最后再说一个具体的实操技巧写板级需求规格书一定要趁早把测试人员拉进来。很多团队是需求写完了才找测试部门要意见结果测试提了一堆“这没法测”“那缺条件”的问题需求文档又得返工。让测试人员在需求阶段就参与评审从可测试性的角度挑毛病返工成本最低。这招我用了好几年屡试不爽。