有一次评审会我拿到一块信号处理板的“板级需求规格书”。打开第一页产品概述三行字术语表倒是写了两页到了“主要功能”部分就是一句“本板完成中频信号采集、预处理和输出”。整份文档加上封面目录一共十二页。评审现场最尴尬的问题不是“板卡能不能做到”而是“你到底要让这块板子干什么”没人能当场回答。这个场景大概能说明需求工程在军用信号处理板的板级需求规格书编写中为什么总被忽略又为什么值得认真做。作为系列课程的一讲这篇内容想把一件事讲透需求工程的方法论如何真正落地成一份能指导设计、能支撑验收、能贯穿全寿命周期的军用信号处理板级需求规格书。适用读者不只是需求工程师还包括硬件负责人、系统总体设计师、FPGA/DSP开发甚至测试人员。因为规格书是所有后续工作的源头源头偏一寸下游跑偏一公里。1. 需求工程与板级规格书的真实关系这不是软件专属方法论1.1 板级规格书不是“技术协议复述稿”我见过太多军工硬件团队的规格书死法就两种。第一种是“抄”。把总体单位下发的技术协议逐条搬进规格书连标点都不改只是在封面上换个标题。第二种是“躲”。凡是暂时说不清楚的地方一律写“由后续详细设计确定”“以上指标待与总体协商”好像规格书是一份免责声明而不是设计输入。这两种做法的根子都是没有把需求工程当成一回事。很多人潜意识里觉得需求工程是软件工程的分支是写代码之前画的用例图跟硬件板卡没有关系。但军用信号处理板恰恰是需求工程最容易产生价值、也最需要需求工程的领域。为什么因为一块板卡的开发要经过总体论证、方案设计、原理图设计、PCB设计、FPGA逻辑开发、DSP软件开发、单板调试、系统联试、环境试验、设计定型等十几个环节。这些环节之间的信息传递主要靠文档。而板级需求规格书就是最上游的输入文档。上游只要有一个歧义下游就可能多一轮改版一次改版在军工流程里意味着什么做过的人都懂。1.2 军用信号处理板“特殊”在哪需求维度远超普通板卡从需求维度看普通商用板卡的规格书通常只需要覆盖功能、性能、接口、功耗、尺寸这五类内容。而军用信号处理板在这五类之上至少还要叠加四类需求环境适应性需求工作温度、存储温度、湿热、盐雾、霉菌、振动、冲击、低气压。电磁兼容性需求CE101、CS101、RS103、RE102这些几百兆赫兹范围内的传导发射和辐射敏感度要求。可靠性与维修性需求MTBF平均故障间隔时间指标、MTTR平均修复时间指标、寿命剖面、任务剖面。测试性需求BIT机内测试覆盖率、故障检测率、故障隔离率、测试点设置要求。再加上军用信号处理板本身的技术特征——多通道高速ADC/DAC、FPGADSP异构计算、光纤或SRIO高速互连、多板级联同步、外部触发和定时接口——这就导致板级需求规格书的需求条目可以轻松超过两百条。没有一套工程化的方法来组织这些条目靠“感觉”写文档必然漏洞百出。1.3 需求工程的四步流程在板级开发中怎么对应很多技术团队对需求工程的理解停留在“写文档”这个动作上其实需求工程是一套完整的流程。我把它拆成四步对应到板卡开发中是这样的需求获取这里不是坐在办公室里编而是去访谈总体设计师、结构设计师、软件负责人、测试负责人去翻历史型号的图纸和故障报告去现场看联试过程。需求分析对收集到的原始需求做澄清、归类、冲突消解、可行性判断划分优先级把模糊的定性描述变成确定的定量描述。需求规格化按统一的编号规范、术语定义、格式模板写成结构化的规格书让每一条需求都有唯一标识、可验证方法、优先级。需求确认与验证组织评审验证需求的完整性在设计完成后逐条追溯确认每条需求都被设计覆盖、被测试验证。这四步走完板级需求规格书才真正完成了从“文档”到“工程资产”的转变。下面展开讲每一步在军用信号处理板上怎么落地。2. 动笔之前先把四张“底图”铺好写规格书最忌讳一上来就打开Word开始敲标题。经验是动笔之前先做四件准备工作对应四张底图。底图没铺好后面写得越多返工越大。2.1 利益相关方地图每条需求都对应一个“人”军用信号处理板的利益相关方比很多人想象的多。我把常见角色和他们在规格书上的关注点整理成了一张表利益相关方在规格书中重点关注的内容总体设计师功能是否覆盖系统分配的全部任务指标是否满足分系统要求结构设计师尺寸、重量、安装方式、散热方式、连接器选型和布局限制FPGA开发人员逻辑接口定义、时序要求、时钟关系、FPGA资源预留软件/DSP开发人员寄存器配置方式、中断类型、启动流程、加载方式硬件设计人员电源时序、电平标准、信号完整性要求、可测性设计测试人员每条需求的验证方法、测试点、BIT功能、故障注入方式工艺人员三防涂覆要求、可制造性、可维修性、焊接工艺约束质量管理人员需求追溯关系、设计输入闭环、问题归零依据这张图的用途是写完任何一条需求问自己一句“这个需求是给谁写的谁会在意它”如果一条需求没有任何相关方在意它就不应该出现在规格书里。反过来说如果某个相关方提出过真实约束规格书里却没有体现那就是需求获取的遗漏。2.2 使用场景清单把“能用”变成“在什么情况下能用”军用信号处理板的使用场景往往有很强的特殊性不能拿商用产品的思维去套。以一块典型的雷达信号处理板为例至少要梳理这些场景上电自检与BIT启动、任务参数加载、多板同步采集、长时间连续值守、外触发异常中断、故障上报与恢复、低温冷启动、振动环境下的电气性能保持。每个场景都要往下追一层。比如“低温冷启动”不是一句“工作温度满足-40℃”就完了还要回答板卡在低温箱内存放几小时达到热平衡上电后电源模块的启动时序是否符合要求时钟芯片在低温下的锁定时间是否有指标约束板卡从低温恢复到常温工作是否需要重新加载配置这些追问就是需求获取的过程。每追一层规格书里就会多出几条真实需求而不是只有一句空泛的“使用环境温度范围”。2.3 接口需求清单把通信边界全部结构化接口需求是板级规格书里最不能出错的部分。原理图一旦投板接口定义想改就是真金白银的改版费用和研制周期延误。接口需求至少分成四类来梳理电气接口光纤接口速率、PCIE通道数和协议版本、SRIO速率和链路宽度、LVDS电平标准、RS422/RS485接口定义、同步脉冲的电平与极性。逻辑接口FPGA侧的数据位宽、字节序、帧格式、握手协议、寄存器偏移地址映射。机械接口板卡规格、连接器型号、锁紧条位置、导冷结构、散热面平面度。软件接口DSP加载方式、引导模式、PCIe枚举配置、中断信号路由。如果这块板卡需要与其他型号板卡互连接口清单还要核对到对方板卡的详细设计不能只看系统框图。很多联试现场“对不上点”的问题根源都在需求阶段接口梳理不到位。2.4 标准与规范约束清单把“军标怎么用”写成明确条目军用产品绕不开标准但标准不是拿来说嘴的是要落成具体需求条目的。我在项目里通常以列表形式维护一份约束清单内容包括标准编号、标准名称、版本年份、适用范围和裁剪说明。例如环境试验按GJB 150A执行就要具体到每个试验项目的方法号高温试验用GJB 150.3A低温试验用GJB 150.4A温度冲击用GJB 150.5A振动试验用GJB 150.16A湿热试验用GJB 150.9A。如果只是笼统写一句“环境试验满足相关国军标要求”后续做试验大纲时试验人员根本不知道该按哪个项目执行容易漏项。标准清单还要注明版本和裁剪。同一个GJB标准老版本和新版本在试验条件、判定准则上可能差别很大。工业级产品和军用产品对元器件要求也不同。把这些约束提前列清楚能避免后续很多扯皮。3. 板级需求规格书的核心板块每个板块该怎么写才不是空话铺好底图之后正式开始搭规格书的骨架。这里不列模板因为每个单位有自己的模板习惯但内容板块和责任要求是共通的。我把军用信号处理板规格书的高频板块拆成六个每个板块都有具体的写法要求。3.1 功能需求板块从“能做”到“做到什么程度”功能需求不是写板卡有哪些功能而是把每个功能的行为边界和行为结果定义清楚。反面写法是“板卡支持多通道数据采集”。一句话写完设计人员看了不知道要采几路、什么格式、触发方式是什么。正面写法应该是板卡应支持8通道同步数据采集单通道采样率不低于1 GSPS采用12位ADC。板卡应支持外部触发、内触发和软件触发三种采集模式触发源可通过寄存器配置。板卡在触发信号到达后从触发沿到首样本可用的传播时延应不大于2个采样时钟周期。每条都写了主语、行为、约束条件。功能需求还要注意把FPGA、DSP、接口各模块的职责边界写清楚避免后续联试时出现“我以为你做了你以为我做了”的经典事故。3.2 性能指标板块量化、量化、再量化性能指标板块是整个规格书里评审专家看得最细的部分也是最容易暴露问题的地方。我的原则是性能指标里禁止出现“高”“好”“强”“优秀”这类形容词也禁止出现“尽量”“左右”“约”这类模糊词。以一块中频信号处理板为例性能指标至少覆盖ADC有效位数ENOB、无杂散动态范围SFDR、通道间幅相一致性、通道隔离度、输入信号带宽、信号处理时延、DAC输出幅度精度、本振频率稳定度、采样时钟抖动等。写法示范在输入信号频率为10 MHz、幅度为满量程以下1 dBFS条件下ADC有效位数应不小于11.5 bit。在相同输入条件下任意两通道之间幅度一致性应不大于0.5 dB相位一致性应不大于3度。从数据帧进入光纤接口到处理结果从光纤接口输出的整链路时延应不大于50微秒。每条指标都要给出测试条件。条件不同同一数值的意义完全不同。没有条件的指标就是没有标准的空头支票。3.3 接口与结构需求板块除了管脚还有热量和重量接口需求不可以只写功能性的接口定义还要写全物理层面的约束。结构需求举例板卡应为6U VPX架构外形尺寸符合相应标准板卡重量含散热器、连接器和紧固件应不大于2.5 kg板卡应支持导冷散热方式导冷安装面的平面度应不大于0.05 mm板卡功耗在典型任务模式下应不大于60 W在峰值任务模式下应不大于80 W。很多人写接口需求就只写信号连接器忽略了电源和地。军用板卡供电通常有严格的电压域和时序要求。规格书里应该明确各电压域的上电时序关系比如核心电压应先于IO电压完成上电时序偏差应在100 ms以内否则可能造成逻辑器件闩锁。这类需求如果漏了单板调试时极大概率烧片子。3.4 环境适应性与可靠性需求板块把“能扛”写清楚环境适应性需求要写清楚“在什么条件下应能正常工作”和“经历什么条件后仍能正常工作”这两类状态。一字之差设计方法完全不同。“在-40℃条件下板卡应能正常启动并完成自检”和“板卡经过-55℃存储24小时后恢复常温应能正常工作”后者对材料和连接的考核重点不同。规格书中要同时覆盖工作条件和非工作条件。可靠性需求则要落到可考核的指标上MTBF指标、使用寿命、大修周期。我强调一点MTBF是可靠性设计输入不是算出来的结果。规格书里把MTBF指标写成“不小于10000小时”硬件设计时就要启动降额设计元器件要优选功耗要控制热设计要留余量。这些动作应该在需求阶段就明确而不是等可靠性预计报告出来再去调整设计。3.5 可测试性需求板块给生产调试和用户维护留好“后门”可测试性需求是硬件规格书里最容易被“砍掉”的板块砍掉的理由通常是“先保证功能实现测试后面再说”。但等样机出来测试性不足导致的定位困难、返工判读消耗的时间远超写需求时多花的半天功夫。可测试性需求应该包括板卡应提供JTAG边界扫描链路支持对FPGA和ADC/DAC器件的边界扫描测试板卡BIT功能应覆盖电源电压监测、关键时钟失锁检测、光模块接收光功率告警、温度传感器读数BIT故障检测率应不低于90%故障隔离率应不低于80%应预留不少于10个可测量的内部测试点并在技术说明书中标注位置与信号名称。写可测试性需求的时候我习惯邀请测试负责人一起参加评审。测试人员的现场判断往往能发现设计人员根本想不到的测试场景。3.6 文档与交付物需求板块把“项目怎么验收”写进需求这一板块写的是交付物清单和管理性要求应交付原理图、PCB、位号图、装配图、BOM清单等技术文件应交付FPGA工程源码、约束文件、版本说明应交付嵌入式软件源码、固件镜像、烧写工具应交付板卡技术说明书、使用维护说明书、测试报告、环境试验报告、质量证明文件所有文件和代码的版本应与硬件版本一致可追溯。这看起来像是商务条款但写到需求规格书里有个重要作用它给项目验收提供了依据。很多军工项目在验收阶段因为交付物不齐而卡流程根源就是需求阶段没有明确交付物清单。4. 指标怎么定到“可验证”量化需求和验收判据设计的实战方法规格书的生命力在于“可验证”。一句写得好听但无法证明的需求在评审时可以被专家放过在验收时一定会被用户代表盯上。这一章是全文最核心的方法论部分。4.1 条件、数值、容差可验证指标的“三要素”我审规格书时判断一条需求是否合格就看它有没有同时包含三要素条件、数值、容差。“ADC有效位数不低于12 bit”这句话没有条件缺少输入频率、输入幅度和温度范围没法测量。补全之后是在环境温度25℃±5℃、ADC输入频率为10 MHz正弦波、输入幅度为满量程-1 dBFS条件下ADC实测有效位数应不小于11.5 bit且测试结果取5次测量平均值。这一下就清楚了条件是什么、要求多少、容差怎么算。我做技术评审时凡是满足不了三要素的需求条目一律打回这已经成了团队的默认规则。4.2 需求条目必须给验证方法A、D、T、I的选用GJB标准里定义了四种需求验证方法分析Analysis、演示Demonstration、测试Test、检查Inspection分别用A、D、T、I表示。在板级需求规格书里每条需求后面都应该标注至少一种验证方法。拿需求条目举例需求编号需求描述验证方法REQ-BD-1001板卡在典型模式下的功耗应不大于60 WT测试REQ-BD-1002板卡应支持通过PCIe接口加载FPGA配置文件T测试 D演示REQ-BD-1003板卡元器件降额设计应符合相关降额准则A分析 I检查REQ-BD-1004板卡应支持外触发采集模式D演示为每条需求指定验证方法有两个实际作用。一是在需求阶段就暴露不可验证的需求——如果一条需求说不清用什么方法验证它大概率是含糊需求。二是给后续测试大纲编写提供直接输入测试项从规格书里长出来而不是测试人员自己拍脑袋。4.3 从系统指标到板级指标的分解逻辑这是需求工程中最需要功力的一步。总体单位给的通常是系统级指标比如“系统对某类信号的检测概率不低于90%”。这个指标不能直接写进板级规格书需要分解到板卡可测的物理量上。分解逻辑大概是这样的检测概率受信噪比影响信噪比由接收链路噪声系数、ADC量化噪声、动态范围、处理损耗决定。系统级检测概率指标就分解成了板卡噪声系数不大于多少dB、ADC位数不低于多少、处理损耗不大于多少dB等板级指标。这里要提示一点分解不是做算术题还要考虑余量分配。系统指标是板卡、天线、机箱、线缆共同作用的结果板级指标通常在系统指标要求之上预留3~6 dB余量。余量留小了联试时系统参数一波动就击穿指标余量留太大成本又控制不住所以工程经验在这里非常重要。4.4 关键指标的“掐死”与“放开”不是所有指标都要往死里写严。我总结了两个原则对于影响系统核心任务的指标——采集通道数、最大采样率、处理时延、同步精度、功耗上限、工作温度范围——必须写死不给任何模糊空间。这些指标一旦放水系统性能就失去保障。对于不影响核心功能的特性可以留宽松一点甚至写成“推荐值”或“参考值”。比如板卡丝印内容、指示灯颜色、连接器的品牌范围这些没必要写成硬性需求否则会给自己和供应商增加无谓的约束成本。知道什么该紧、什么该松是需求工程师从“会写”走向“会判断”的标志。5. 实际编写过程中的典型翻车场景与纠正方法理论讲完分享几个我在实际项目中踩过或见过的翻车场景。这些场景几乎每个硬件团队都会遇到提前知道能省很多返工。5.1 接口需求写得太简略导致的“原理图僵局”有一块板卡规格书里写“支持VITA 57.1 FMC接口”——就这一句。等到设计人员画原理图时发现FMC接口有数百个引脚不同厂商的FMC子卡在使用LPC还是HPC引脚、是否存在差分对方向差异、电源域分配规则上都有差别。规格书一句话原理图设计人员反推了三天最后还要找总体确认。更麻烦的是连接器的机械高度、子卡限高、散热结构都没有界定PCB结构设计也一起卡住了。反例说明了什么接口需求不是接口名称列表而是接口行为的完整定义。参考的协议版本、引脚用法、电气属性、机械配合、供电分配都应该在需求阶段给出够用的细节无需写到Register级但不能停在接口名字级。5.2 规格书写得比总体“还严”导致的设计困局有一种情况属于过度设计。总体协议里写的是“处理时延不大于100微秒”规格书编写人员为了给用户代表留好印象把指标写成“处理时延不大于30微秒”。评审是顺利过了但设计人员为了实现30微秒的指标把算法抽样率降了、把数据块缩小了、把滤波器阶数砍了最后系统性能反而劣化。这个错误的方向和“留余量”正好相反。需求工程师要有能力判断哪些指标是军令状必须严格满足哪些指标是尽量项写得比总体严反而有害。军用产品追求的不是指标炫技是系统可靠。盲目加严毫无意义。5.3 需求颗粒度太粗导致无法追溯有一次我审查一份外包板卡的需求规格书发现全篇没有一条需求有编号。测试报告里引用需求时只能写“关于采集功能测试通过”。这种写法在归档和归零时非常痛苦——一旦出现质量事故追查设计依据和测试依据都不知道该查哪一条。纠正方法需求编号体系要规范一个需求编号对应一条原子需求。我常用的格式是“REQ-板卡缩写-顺序号”例如REQ-SIG-0001。一条原子需求只表达一个行为、一个指标、一个约束不把两件事揉在一起。5.4 “后续再议”式需求导致的研制延期“具体接口协议待与总体单位协商”“加载方式由软件设计定义”“外形尺寸以结构图为准”——这些写法是规格书里的合法内容但不能用在不该用的地方。我的经验是每写一个“待定”都要在需求跟踪表里登记一个编号、一个责任人和一个计划确认时间节点由专人负责跟踪闭环。否则所有“待定”都会在项目最忙的时候变成炸弹不是电话会议反复拉通就是投板前技术状态无法闭环。6. 需求评审与追溯链规格书只是起点不是终点规格书写完、评审通过在很多人看来工作就算结束了。但对有经验的需求工程师来说真正的需求管理才刚开始。6.1 评审会要请对的人问对的问题板级需求规格书评审我建议至少邀请这些角色到场总体部主管设计师、结构设计师、硬件负责人、FPGA负责人、软件负责人、测试负责人、工艺和质量代表。评审不是走过场评审意见要落实到规格书修改中。我习惯在评审会上重点引导三类问题需求覆盖是否完整对照任务书和使用场景逐项确认指标是否可验证逐条检查三要素和验证方法需求之间是否存在冲突例如环境温度范围与所选元器件的温度等级是否匹配功耗指标与散热方式是否矛盾。会后评审意见要分类处理修改类、补充类、讨论类。每条意见都要闭环确认不能只写在会议纪要里。6.2 需求追溯矩阵把设计、测试都挂在需求上需求追溯矩阵RTM听着很高大上实际操作起来就是用一张表把需求的“出生到验证”全链路串起来。我维护的追溯矩阵包含这些列需求编号、需求描述、来源文件及条目号、设计实现文档、设计责任人、测试用例编号、测试结果、验证状态。需求编号需求描述来源设计实现测试项状态REQ-SIG-00108通道同步采集总体协议4.2条原理图AD芯片连接TS-10-01通过REQ-SIG-0011通道间相位一致≤3度总体协议4.2条布局布线等长约束TS-11-01待测追溯矩阵的价值体现在两个时刻。一是设计评审阶段看每条需求是否都有设计响应防止需求悬空。二是转段评审和验收阶段逐条过状态让用户代表清楚地看到需求的落位与验证情况。Excel维护足够了不是必须用昂贵的专业工具。6.3 需求变更不可怕可怕的是口头变更需求变更是所有项目的常态。军用信号处理板的生命周期长从初样、试样到定型总体方案的调整、元器件国产化替代、系统指标的优化都会传导到板级需求规格书的变更。变更管理的底线是“凡是变更必有记录”。口头沟通、微信消息、评审会议口头确认后改了设计却不更新规格书这是技术状态失控的最大隐患。规格书的每次变更都应走正规流程填写变更申请、说明变更内容与影响分析、经评审批准后升版、在版本变更记录表中登记。升版后的规格书要分发到所有设计、测试人员手里同时回收作废版本。我经历过最惨痛的一次教训是一位硬件设计人员根据电话确认的口头需求改了电源设计但没有更新规格书三个月后另一位新加入的工程师接手设计时照着旧版规格书重新计算了一遍电源余量结果按错误假设重做了一版白白浪费了两周时间。从此以后团队里所有硬件相关需求变更必须落到规格书升版上口头沟通只作为讨论记录不作为设计依据。还有一个实用习惯分享给大家每次升版规格书都保留一个变更记录页列出本次修改的条款编号、修改前内容、修改后内容、修改理由、修改人和日期。这个记录页在后续设计定型审查时会节省大量时间不用翻git记录就能说清楚版本的来龙去脉。回到这篇文章的题目需求工程落地到军用信号处理板的板级需求规格书本质上不是把软件工程的概念硬套到硬件上而是把“严谨定义需求、验证需求、管理需求”的思维方式融入军工硬件的研制流程里。需求工程是那只“看不见的手”它负责在设计的源头把所有模糊的东西变得清晰把所有无法验证的东西变得可考核。个人经验是写出一份高质量规格书的核心能力不是文字功底而是系统思维——你要在动笔那一刻就看到板卡从生到死的全过程。另一个小技巧是写完每一条需求都问自己一句如果这块板子已经做出来了我能不能用一次实测或者一项分析来证明“这句话”成立如果答案是“不能”那这条需求就得重写。这句话帮我把无数条看着漂亮、实则无效的需求挡在了稿纸之外。