前阵子参加一个军用信号处理板的需求评审会项目组把系统级的需求说明文档摊开对着里面的功能条目逐条讲板卡怎么实现。讲了大半场评审专家忽然问了一句“你这条‘支持高速数据采集’速度到底多高什么条件下测用什么东西判合格”全场沉默了好几秒。那一刻我就知道这份所谓的板级需求规格书本质上还是一份设计说明加功能列表离真正意义上的“需求规格”差得很远。这一讲我们就专门聊一件事需求工程到底怎么落到军用信号处理板的板级需求规格书Board Level Requirements Specification上。它不是把系统需求复制粘贴下来也不是给设计文档换个封面而是一份真正能用来指导设计、支撑验证、做变更管理、陪板卡走完整个生命周期的工程基线。你会看到怎么分析输入、怎么搭需求架构、怎么把模糊的描述变成可验证的参数也会看到我在实际项目里踩过的坑和总结出来的避坑方法。适合系统工程师、硬件工程师、嵌入式软件工程师以及所有被需求评审折磨过的项目管理、质量管理人员参考。1. 为什么板级需求规格书是信号处理板“落地”的最后一公里1.1 板级需求规格书在需求工程链条里的位置需求工程讲起来是一个完整的体系需求获取、需求分析、需求规格化、需求验证、需求管理。但在具体型号项目里最薄弱的往往不是最顶层的系统需求也不是最底层的编码和电路设计而是中间那一层“承接层”。顶层有系统需求规格书定义了整个分系统的任务和指标底层有软硬件的详细设计定义了寄存器、引脚、代码模块、原理图。可是从系统指标到板卡实现之间如果缺了一份清晰的板级需求设计师就只能靠个人经验去理解你说东他理解成西最后做出来的板和总体想要的不是一回事。板级需求规格书就是补上这个缺口的。它是连接总体需求和板卡软硬件设计实现之间的桥梁。对军用信号处理板来说这个层级尤其关键因为板卡往往是一个可独立交付的配置项外部接口复杂内部又同时涉及FPGA逻辑、DSP软件、高速模拟前端、电源、时钟、结构散热等多个专业方向。没有一份统一的板级需求这些专业方向之间根本没法对齐。你可以把它理解成装修时的“施工图”而不是“效果图”。系统需求是效果图看着好看但没法直接施工设计文档是工人的手艺活每个细节都靠个人发挥板级需求规格书则是把每个房间的尺寸、插座位置、水管走向都定死的施工图。没有施工图效果图再漂亮装修出来也一定是到处返工。1.2 军用信号处理板给需求建模带来的特殊考验通用板卡的板级需求可能相对简单一个盒子、几路IO、跑个Linux应用就算完事。但军用信号处理板完全不是这个量级。这类板卡的核心工作常见的是AD采集、数字下变频、滤波、FFT变换、波束形成、特征提取、目标检测这些任务硬件架构上典型的是FPGA加DSP再加高速ADC/DAC然后通过RapidIO、PCIe、千兆网或者自定义总线跟外部系统交互。这种板卡有几个非常突出的特点每个特点都直接影响到需求建模的方式。第一是高吞吐、强实时。信号处理链路一旦跑起来数据是连续不断流的几百MB甚至上GB每秒的吞吐量是常态。时延指标不是“尽量快”而是硬性的、必须保证的。需求规格书里如果没有明确帧率、处理时延、丢点率这些参数后面联试的时候必吵架。第二是接口耦合极强。ADC的采样时钟、触发同步、多板卡之间的数据分发这些细节哪怕差几个时钟周期整个系统就工作不正常。第三是环境适应要求极其苛刻。军用板卡要面对高低温、振动、湿热、盐雾、低气压这些环境而且往往是多项环境条件叠加不是实验室里那种恒温恒湿的舒适环境。第四是生命周期长软件硬件都要长期维护。板卡今天定型明天还要考虑未来几年的产品升级和维修保障有没有预留资源余量就成了很重要的需求。这些特点决定了板级需求规格书不能是系统需求文档的删减版而必须是围绕板卡这个层级重新组织、重新细化、重新量化的一份独立工程文档。1.3 一份“落地”的规格书应该具备的三个标志我判断一份板级需求规格书是不是真的“落地”了通常看三个标志。第一个标志是每条需求都能在验证矩阵里找到对应的验证方法而且这个方法具体到可以由第三方独立执行而不是写需求的人自己说了算。这个第三方的说法很重要因为如果验证方法只有设计者自己看得懂那评审的时候专家一定会追问。第二个标志是双向可追溯。往上每条板级需求都能追溯到系统级需求里的某一条或某几条往下每条板级需求都能追踪到设计里的某个模块、某段代码或者某个测试用例。丢了任何一个方向这份规格书就只是挂在墙上的文档。第三个标志是需求冻结之后软硬件可以并行开工。如果板级需求写得足够清晰硬件工程师和软件工程师不需要频繁互相确认就能各自干活那这份需求就算真正立住了。如果写完需求大家还是天天开会对齐说明需求还有大量的隐含信息没写出来。2. 动手之前先把三类输入和需求架构理清楚2.1 输入源分析不把输入理清后面全是糊涂账写板级需求规格书的人经常犯的第一个错误就是拿到一份系统需求文档就开始写。实际上板级需求规格书的输入至少有三大类少看任何一类写出来的文档都会有明显的盲区。第一类是系统级需求包括用户需求说明、系统需求规格书、总体技术方案、接口控制文件等等。这些文档决定了板卡“要完成什么任务”“对外怎么交互”。比如接口控制文件里定义了板卡和背板之间的信号定义那板级需求里对应的接口需求就必须跟它完全一致连电平标准、极性定义都不能含糊。第二类是硬件和实现约束。器件选型情况、功耗预算、结构尺寸、散热条件、研制周期、成本上限这些都属于约束类输入。它们虽然不直接定义“要做什么”但决定了“能怎么做”。比如结构上已经定了3U板卡尺寸那需求里写“支持16路同步采集”的同时就必须考虑采集通道的隔离间距、连接器针脚数量是否放得下。忽略实现约束的需求往往会写在纸面上很美落地才发现物理上根本做不到。第三类是标准和规范要求。行业里的各类工程规范、质量体系要求、文档编写规范、环境试验标准等决定了需求必须覆盖哪些非功能属性。军用市场尤其重视这一点可靠性的MTBF指标怎么提、测试性的BIT覆盖率怎么提、环境适应性按哪些条件考核都是有标准依据的不能拍脑袋乱编。实操上我的建议是动笔之前先做一张输入文件清单把文件名、版本号、获取日期、责任人都列清楚。这一步很简单但能避免后面大量麻烦。2.2 需求架构维度设计别只盯着功能需求很多项目组写板级需求规格书最习惯的方式就是按功能模块堆需求采集板写几条采集功能处理板写几条处理功能完事。这种把功能需求当全部的做法是需求漏项的最大根源。我建议把需求架构至少切成六个维度功能需求、性能需求、接口需求、环境适应性需求、六性需求可靠性、维修性、测试性、保障性、安全性、可生产性与可维护性需求。每个维度都在文档里单独成章、单独编号后期维护才清晰。为什么要切这么细因为每个维度对应的责任专业不同、验证方法也不同。功能需求主要靠演示和试验验证性能需求往往要靠分析加试验环境适应性需求靠环境试验可靠性需求靠分析计算和加速试验接口需求主要靠一致性测试。如果不切分这些不同性质的验证要求混在一起验证矩阵根本没法组织。以一块典型的信号处理板为例功能需求管的是“能不能完成FFT”“能不能生成触发脉冲”性能需求管的是“FFT 1K点处理时延不超过多少微秒”“输出杂散抑制不低于多少dBc”接口需求管的是“对外采用什么连接器、什么电平标准”环境适应性需求管的是“在-40℃到70℃范围内指标不降级”六性需求管的是“整板MTBF不低于多少小时”“故障检测覆盖率不低于百分之多少”。这样一拆整个需求空间的覆盖面就完整了。2.3 从“系统需求”到“板级需求”的分解方法这里说一个很多人做不好的环节需求分解。系统级需求写得比较粗放板级需求要细化、量化但不是说把系统需求的每句话都翻译成板级语言就完了而是要“分配”加“细化”两步走。分配的意思是明确这条系统需求由哪块板卡负责。细化则是在板卡层面把这个模糊的目标变成可操作、可验证的具体指标。举个例子系统级需求里写“信号处理分系统应能对中频信号进行实时处理”。这句话落到板级就要拆成如下信息输入中频信号的频率范围是多少、电平范围是多少、信号通过什么接口进入板卡实时性怎么定义是端到端时延不超过多少毫秒还是在多少帧率下不漏帧处理结果以什么格式输出、通过什么接口输出这些功能和性能在全温范围和全寿命期内都要满足还是只在地面常温条件下满足最后还要为这样的指标预设验证方法。每做一次这样的拆分其实就是把模糊变清晰的一次过程。执行的时候可以用需求分解矩阵纵向是系统需求横向是板卡功能模块在交叉格子里写上板级需求条目编号一张表就能看清每个系统需求被分解到了哪里以及有没有被漏掉的系统需求。3. 板级需求规格书的章节骨架与条目撰写规范3.1 一套可以直接套用的模板骨架我经常被同事问板级需求规格书到底按什么结构写比较好。这里给出一套我在项目里实际使用过、也被多次评审验证过的章节骨架你可以根据具体项目做裁剪。章节章节名称主要内容1范围说明文档适用对象、适用范围、与哪些系统关联2引用文件列出所有输入文档、标准、规范注明版本3术语与缩略语统一文中的术语解释避免歧义4总体描述板卡功能概述、组成框图、工作模式、外部接口概览5详细需求按功能、性能、接口、环境、六性、可生产性等维度展开6验证需求与验证矩阵说明每类需求采用的验证方法给出完整验证矩阵7需求追踪矩阵建立与系统需求、设计实现的追溯关系8交付物与支持需求交付的技术文档、测试报告、保障资源要求9附录补充计算过程、分析依据、特殊说明这套骨架的关键是第5章和第6章。第5章是需求本身第6章是验证要求两章必须一一对应否则需求写了没有验证方法验证做了没有需求依据评审的时候一定会被抓出来。另外一个原则是规格书里不要写“怎么实现”。很多项目组写着写着就把需求规格书写成了设计说明在下面加一句“本需求通过FPGA内部双口RAM实现”这句话放在需求规格书里面就是多余的设计信息会限制设计人员的发挥空间。设计约束应该放到设计文档里去描述。需求规格书里只管要什么标准、什么指标、怎么验收不管用什么手段做到。3.2 一条合格需求条目的四要素很多新人在写需求条目的时候写出来的东西更像愿望清单而不是工程需求。一条合格的板级需求至少应该包含四个要素唯一编号、需求陈述、验证方法、追溯信息。唯一编号是需求的身份证建议带前缀便于识别。比如BRS-FUNC-001代表板级规格书功能需求第1条BRS-PERF-023代表性能需求第23条。编号一旦发布不要因为中间的插入而随意重排可以留出增量区间避免后续编号全乱掉。需求陈述要遵循“主语加条件加行为加约束加量化指标”的结构确保没有歧义。用生活化的语言说就是谁、在什么情况下、干了什么、达到什么标准缺一个都不算完整。验证方法要写清楚用什么方法验证是检查、分析、演示还是试验以及判定合格的依据是什么。这个我们下一章详细展开。追溯信息要写明本条需求的来源比如对应系统级需求里的哪一条优先级是什么级别当前状态是草稿还是已批准还是已实现。有了这些信息后续做需求追踪矩阵就很方便。我举一个正反两个例子放在一起看。反面写法是“系统应支持高速数据采集”正面写法是“板卡在全工作温度范围内应支持不少于16路同步模拟输入单通道采样率不低于125MSPS采样分辨率不低于16位模拟输入带宽不低于500MHz输入阻抗为50Ω±5%验证方法为注入标准单音信号用频谱分析仪测试各通道幅度和频率误差均不超过标称值的±1%”。哪一种能在评审中过关一目了然。3.3 需求参数从哪来从定性到定量的推导方法写需求的人最怕的就是定参数怕定错了后面实现不了怕定严了成本飙升怕定松了被总体打回来。实际上参数来源是有规律可循的主要有五个途径。第一个途径是系统需求直接给定。总体的指标文件里明确写了采样率不低于多少你直接照搬并细化到工作条件即可。第二个途径是从任务场景仿真得到。通过仿真软件把典型场景模型跑一遍统计得到处理时延、吞吐量的分布然后给出带余量的指标。第三个途径是从接口协议计算。接口文件的传输速率、帧格式、同步时序都确定了板卡的数据吞吐需求就能算出来。第四个途径是工程经验和行业惯例。比如FPGA逻辑资源利用率一般建议不超过70%这既是为了留升级余量也是为了布线时序收敛。第五个途径是预算分配。这是系统工程里最常用的手段比如整个系统的时延预算是200ms需要在传感器、采集板、处理板、输出链路之间分配板卡分到多少就写多少。以时延需求为例信号处理板端到端时延通常包括AD转换时延、FPGA预处理时延、数据传输时延、DSP算法处理时延、输出接口排队时延。把这几个时延项逐个估算、预算分配最后得出总时延指标而不是随便写一个“不大于1秒”。这样写出来的参数在评审的时候你有计算依据可讲专家也不会轻易挑战你。4. 可验证性设计让每条需求都能被验收4.1 四类验证方法与适用场景需求规格书里最常见的败笔是写了需求却没有验证方法或者验证方法写得很模糊比如“经过测试验证”。到底怎么测、测什么指标、判合格的标准是什么一句话都没说。要解决这个问题必须引入工程上最常用的四类验证方法并且做到条条需求有对应。检查法适用于那些不需要通过实际测试来验证的需求主要是文档和配置类需求。比如需求“板卡应提供完整的用户手册和调试说明”验证方法就是检查交付文档是否完整、是否符合模板要求。分析法适用于可以通过计算、仿真、建模来验证的需求。比如资源余量需求不需要等板卡做出来再测在综合实现工具里跑一遍布局布线读资源利用率报告就可以判定是否符合。再比如可靠性MTBF指标可以通过可靠性预计计算来验证。演示法适用于功能层面的需求通过操作演示证明功能实现。比如“板卡应支持远程升级FPGA程序”这条需求现场通过上位机软件下发升级文件观察升级是否成功即可。试验法适用于必须通过实测数据来验证的需求尤其是那些涉及具体性能指标、环境适应性的需求。比如采样率、处理时延、误码率、高低温性能等都必须按照规定的试验方法实际测量。军用信号处理板里功能需求多用演示或试验性能指标多用试验或分析接口需求多用检查加试验环境需求基本全靠试验。4.2 验证矩阵的构建方法验证矩阵说白了就是一张大表把需求编号、需求描述、验证方法、验证时机、验证级别、通过准则这几列拉平最终做到每一条需求都在表里有一行。需求编号需求描述验证方法验证时机通过准则BRS-PERF-023单通道采样率不低于125MSPS试验单元测试阶段实测采样率≥125MSPS且无漏码BRS-ENV-011-40℃~70℃正常工作试验环境鉴定试验阶段全温范围内功能正常指标不降级BRS-REL-005整板MTBF不低于20000小时分析设计定型阶段可靠性预计报告结论≥20000小时BRS-INT-008对外接口符合ICD-XXX-RevC检查试验联试阶段电气特性和协议帧格式逐项比对一致构建验证矩阵的过程反过来是对需求的再一次审查。你会发现有些需求没法验证那要么是需求写得不够具体要么是需求本身压根不需要写。我在项目里做过一次统计大约三分之一的初始需求条目在构建验证矩阵的过程中被改写或删除剩下的需求才真正值得保留。关于通过准则我的忠告是能量化就一定量化。写“功能正常”等于没写要写“输出数据符合约定的帧格式CRC校验无误码”“处理时延不超过规定值”这类可以客观判断的语句才能作为验收的最终依据。4.3 实测案例从需求条目到测试用例的完整路径用一个真实场景来演示验证设计怎么落地。某项目要求信号处理板支持16路同步采集板级需求写成“板卡应支持16路同步模拟输入单通道采样率不低于125MSPS16位分辨率通道间同步偏差不超过1个采样周期验证方法为试验。”拿到这条需求测试人员的动作应该是这样的。先搭环境用信号发生器产生标准单音信号经过等长射频线缆分成16路接到板卡的16个输入通道保证各路输入信号是同一源的等幅同相关系。接着配置板卡工作设置采样率为125MSPS连续采样一段时间。然后把采集数据导出对16路数据的起始点做互相关分析计算通道间的时间偏差判定是否在1个采样周期以内。最后再逐通道测幅度和频率判定是否满足标称值允许误差。整个过程下来需求里的每一个量化指标都有了一个明确的测试步骤和判定方法。这条需求就算通过验证了。如果当初需求里只写“支持同步采集”不提同步偏差是多少测试的人根本不知道该拿什么标准去判评审专家也一定会揪住不放。再举一个FPGA资源余量的例子。需求写成“FPGA逻辑资源利用率在综合实现后不超过70%RAM资源利用率不超过70%DSP计算单元利用率不超过60%验证方法为分析。”这条需求的验证手段就非常轻量逻辑工程师在Vivado或Quartus里跑完综合实现直接读报告就能判定。但是请注意验证时机要写清楚是“使用最终版本代码、在典型配置条件、完成布局布线之后”否则在早期综合阶段看的资源数据跟最终实现结果差很多拿去糊弄验收会见光死。5. 需求追踪、基线与变更管理让文档“活”起来5.1 需求追踪矩阵的搭建与维护很多项目组的需求追踪矩阵是评审前临时补的评审一过就没人再动。这样的追踪矩阵只能算一张应付检查的表格起不到真正的作用。我建议的搭建方式是字段里同时包含向上追踪和向下追踪两部分。向上追踪解决的是“这条板级需求从哪里来”。规格书里的每一条关键需求都应该能找到对应的系统级需求条目。向下追踪解决的是“这条需求到哪儿去”也就是设计实现和测试验证里谁能证明这条需求被满足了。一个实用的追踪矩阵字段可以这样设计需求编号、需求描述摘要、上级需求编号、实现对象比如ADC驱动单元、FPGA采集模块、DSP算法模块、设计文档编号、验证方法、验证时机、测试用例编号、当前状态。维护频率上我建议每次迭代结束、每次基线评审之前强制更新一次。不要等季度总结再做到那个时候你根本记不清状态只能瞎填。维护是做配置管理的人、系统工程师、测试经理一起干的不是某一个角色单打独斗。追踪矩阵一旦出现空白或者对不上就说明需求链条有了断点要第一时间查清楚是需求被删了还是设计没跟上。5.2 变更控制的实操流程与注意事项需求变更是常态怕的不是变更而是不受控的变更。军用信号处理板的一个特点是后期软硬件并行开发周期长中间必然有大量因为系统联试、算法调整、接口适配带来的需求改动。如果没有一套规则今天改一个参数明天又改回来最后谁也不知道当前版本到底算不算数。标准的变更流程听上去不复杂提交申请、影响面分析、评审批准、修改文档、更新追溯关系、补充验证、发布新基线。难点在影响面分析这一步。分析变更影响的时候至少要回答四个问题这条需求改动后跟它有依赖关系的其他需求要不要跟着改对外接口有没有变化变化后跟连接的另一端能不能对齐验证方法和测试用例要不要重新做要重做多少对研制进度和成本影响多大。在实际操作中我发现最容易漏的是“验证回归”这一步。很多人改完需求文字就宣布完成完全不考虑原有测试用例是否需要更新、已经完成的试验是否需要补做。这是很大的隐患。需求改了意味着验收标准改了之前的通过判据可能已经失效如果不重新明确到交付验收的时候就是一笔糊涂账。5.3 基线与配置管理的常见做法板级需求规格书一旦评审通过就应该纳入配置管理并且只有受控版本才能作为设计和验证的依据。常见的做法是设置几个关键基线节点需求冻结基线、设计定型基线、生产定型基线。每个基线对应一个正式版本中间所有的修改都以受控变更单的形式记录。版本命名上我习惯用V1.0代表首个评审通过的正式基线V1.1表示小修订V2.0表示重大变更后的新基线。草稿阶段一律在文件名里加“DRAFT”标识不能对外发布。这个习惯能非常有效地避免“你说的是哪一版需求”这种内部扯皮。配置管理还有个容易被忽视的细节就是历史版本的归档保留。有人认为新版发布了旧版可以丢掉了其实这是错的。现场在用哪个版本、和客户签的技术协议对应哪个版本这些追溯关系都要靠历史版本支撑。所以哪怕新版发布一年半载了旧版文件也应该原样封存在配置库里不能物理删除最多做状态标记。6. 常见问题与排查技巧实录6.1 评审时最容易被挑战的六类问题做需求评审多了你会发现专家们的提问套路其实相当固定。把这些高频问题提前自查掉评审会会顺畅非常多。常见问题典型表现解决建议1. 需求含糊出现“尽量”“及时”“支持”等无量化词逐条审查把模糊词替换为可量化指标和条件2. 需求不可验证写了功能没写验收方法和通过准则构建验证矩阵无法验证的要么细化要么删除3. 需求重复矛盾不同章节里同一件事说法不一致评审前做一次交叉一致性检查重点查接口、指标4. 异常和边界缺失只写了正常流程没写异常处理增加专门的异常与边界需求章节覆盖上电时序、数据溢出、通信中断等场景5. 非功能需求漏项只有功能性能环境、六性、可生产性缺失按六个维度逐项过一遍需求架构表格6. 追溯关系断裂板级需求找不到上级来源或下级实现定期维护追踪矩阵禁止出现空白单元格以“异常和边界缺失”为例这是我最常被抓的问题之一。比如需求写了正常采集流程却没有写“当输入信号超过ADC满量程时板卡应执行抗饱和处理且恢复时间不超过多少毫秒”。这样的需求缺失在联试阶段才会暴露到那个时候改起来代价就非常大了。6.2 五个独家实操心得最后分享几个我自己在项目里摸爬滚打总结出来的实操心得这些内容在教科书和标准文档里都不会写。第一个心得是“先写验证方法再写需求正文”。很多人习惯先写需求再想怎么验证结果写出来的需求根本没法验证。把顺序反过来先想清楚用什么方法、判合格的标准是什么再倒推需求正文怎么表述需求质量和可验证性会同时上一个台阶。第二个心得是“一条需求只描述一项能力”。有些同事写需求喜欢合并同类项一条里面写好几个要求表面看着整洁实际上后期追踪、验证、变更都非常被动。一条需求改动要连带影响其他要求测试用例也没法独立设计。拆开写、独立编号短期看文档长一些长期维护轻松很多。第三个心得是“评审前用负面清单自查”。所谓负面清单就是专门整理一份“禁止出现的措辞和表达”比如“尽可能”“相关”“一定范围内”“视情况而定”这类不可验证的词。评审前逐条扫一遍看到就改掉。这个方法特别适合需求量大的项目机械执行反而高效。第四个心得是“让测试人员提前介入需求评审”。这是被验证过最有效的一条。测试人员天然带着“可不可以验证”的思路看需求他们对模糊表达极其敏感往往一眼就能看出需求里没写清楚的地方。我见过太多项目测试组到最后才拿到需求规格书再来提一堆需求歧义问题那时候改的代价已经翻了不知道多少倍。第五个心得是“每次变更都要顺手更新需求条目状态”。不要相信人的记忆力。今天这条需求还在设计中明天改了后天又调整你如果不随手在需求条目里更新状态过两个星期再来看谁都说不清楚当前真实进展。我知道这很繁琐但这是需求规格书能“活”到最后的根本保证。我从第一次写板级需求规格书到现在最大的体会其实就一句话这份文档真正要服务的不是评审表而是后面至少三五年里所有照着它做设计、做测试、做维修保障的工程师。与其把它写得花团锦簇不如实实在在地写成一份可查、可测、可追溯的工程基线。需求工程说了那么多方法论落到板级需求规格书上核心就是这么朴素的几条原则。希望这一讲的内容能帮你在下一次写规格书或者开评审会的时候少走一点我走过的弯路。