有一次评审会，我拿到一块信号处理板的“板级需求规格书”。打开第一页，产品概述三行字，术语表倒是写了两页，到了“主要功能”部分，就是一句“本板完成中频信号采集、预处理和输出”。整份文档加上封面目录一共十二页。评审现场最尴尬的问题不是“板卡能不能做到”，而是“你到底要让这块板子干什么”，没人能当场回答。这个场景大概能说明，需求工程在军用信号处理板的板级需求规格书编写中，为什么总被忽略，又为什么值得认真做。作为系列课程的一讲，这篇内容想把一件事讲透：需求工程的方法论，如何真正落地成一份能指导设计、能支撑验收、能贯穿全寿命周期的军用信号处理板级需求规格书。
适用读者不只是需求工程师，还包括硬件负责人、系统总体设计师、FPGA/DSP开发甚至测试人员。因为规格书是所有后续工作的源头，源头偏一寸，下游跑偏一公里。
1. 需求工程与板级规格书的真实关系：这不是软件专属方法论
1.1 板级规格书不是“技术协议复述稿”
我见过太多军工硬件团队的规格书，死法就两种。
第一种是“抄”。把总体单位下发的技术协议逐条搬进规格书，连标点都不改，只是在封面上换个标题。第二种是“躲”。凡是暂时说不清楚的地方，一律写“由后续详细设计确定”“以上指标待与总体协商”，好像规格书是一份免责声明，而不是设计输入。
这两种做法的根子，都是没有把需求工程当成一回事。很多人潜意识里觉得，需求工程是软件工程的分支，是写代码之前画的用例图，跟硬件板卡没有关系。但军用信号处理板恰恰是需求工程最容易产生价值、也最需要需求工程的领域。
为什么？因为一块板卡的开发要经过总体论证、方案设计、原理图设计、PCB设计、FPGA逻辑开发、DSP软件开发、单板调试、系统联试、环境试验、设计定型等十几个环节。这些环节之间的信息传递，主要靠文档。而板级需求规格书就是最上游的输入文档。上游只要有一个歧义，下游就可能多一轮改版，一次改版在军工流程里意味着什么，做过的人都懂。
1.2 军用信号处理板“特殊”在哪：需求维度远超普通板卡
从需求维度看，普通商用板卡的规格书，通常只需要覆盖功能、性能、接口、功耗、尺寸这五类内容。而军用信号处理板，在这五类之上至少还要叠加四类需求：
- 环境适应性需求：工作温度、存储温度、湿热、盐雾、霉菌、振动、冲击、低气压。
- 电磁兼容性需求：CE101、CS101、RS103、RE102这些几百兆赫兹范围内的传导发射和辐射敏感度要求。
- 可靠性与维修性需求：MTBF（平均故障间隔时间）指标、MTTR（平均修复时间）指标、寿命剖面、任务剖面。
- 测试性需求：BIT（机内测试）覆盖率、故障检测率、故障隔离率、测试点设置要求。
再加上军用信号处理板本身的技术特征——多通道高速ADC/DAC、FPGA+DSP异构计算、光纤或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 W | T（测试） |
| 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-0010 | 8通道同步采集 | 总体协议4.2条 | 原理图AD芯片连接 | TS-10-01 | 通过 |
| REQ-SIG-0011 | 通道间相位一致≤3度 | 总体协议4.2条 | 布局布线等长约束 | TS-11-01 | 待测 |
追溯矩阵的价值体现在两个时刻。一是设计评审阶段，看每条需求是否都有设计响应，防止需求悬空。二是转段评审和验收阶段，逐条过状态，让用户代表清楚地看到需求的落位与验证情况。Excel维护足够了，不是必须用昂贵的专业工具。
6.3 需求变更：不可怕，可怕的是口头变更
需求变更是所有项目的常态。军用信号处理板的生命周期长，从初样、试样到定型，总体方案的调整、元器件国产化替代、系统指标的优化，都会传导到板级需求规格书的变更。
变更管理的底线是“凡是变更必有记录”。口头沟通、微信消息、评审会议口头确认后改了设计，却不更新规格书，这是技术状态失控的最大隐患。规格书的每次变更都应走正规流程：填写变更申请、说明变更内容与影响分析、经评审批准后升版、在版本变更记录表中登记。升版后的规格书要分发到所有设计、测试人员手里，同时回收作废版本。
我经历过最惨痛的一次教训是：一位硬件设计人员根据电话确认的口头需求改了电源设计，但没有更新规格书，三个月后另一位新加入的工程师接手设计时照着旧版规格书重新计算了一遍电源余量，结果按错误假设重做了一版，白白浪费了两周时间。从此以后，团队里所有硬件相关需求变更必须落到规格书升版上，口头沟通只作为讨论记录，不作为设计依据。
还有一个实用习惯分享给大家：每次升版规格书，都保留一个变更记录页，列出本次修改的条款编号、修改前内容、修改后内容、修改理由、修改人和日期。这个记录页在后续设计定型审查时会节省大量时间，不用翻git记录就能说清楚版本的来龙去脉。
回到这篇文章的题目，需求工程落地到军用信号处理板的板级需求规格书，本质上不是把软件工程的概念硬套到硬件上，而是把“严谨定义需求、验证需求、管理需求”的思维方式，融入军工硬件的研制流程里。需求工程是那只“看不见的手”，它负责在设计的源头把所有模糊的东西变得清晰，把所有无法验证的东西变得可考核。个人经验是，写出一份高质量规格书的核心能力不是文字功底，而是系统思维——你要在动笔那一刻，就看到板卡从生到死的全过程。另一个小技巧是，写完每一条需求都问自己一句：如果这块板子已经做出来了，我能不能用一次实测或者一项分析来证明“这句话”成立？如果答案是“不能”，那这条需求就得重写。这句话帮我把无数条看着漂亮、实则无效的需求挡在了稿纸之外。
