做过嵌入式固件开发的人应该都有同感我们拿到的所谓需求很少有哪次是一份干干净净、逻辑闭环的文档。多数情况下需求是散落的——产品经理嘴里有一句、硬件工程师的原理图里藏着一堆、老板的邮件里还有一句跟上次那个项目保持一致。而需求获取这颗扣子如果第一颗就扣歪了后面所有设计、编码、测试都会跟着歪。我这些年做过不少嵌入式项目从8位MCU的传感器采集板到带实时操作系统的电机控制器都碰过踩过的坑多数不是代码写不出来而是需求没挖透。尤其是Eliciting Software Requirements for Embedded Systems这件事它跟互联网后端的需求分析完全是两个物种你要跟硬件抢时序要跟寄存器打交道还要帮客户把他脑子里那句应该很稳定翻译成可以写进测试用例的数字。这篇文章我就从实操角度复盘一下嵌入式系统做软件需求获取时真正要逼问出什么、怎么逼问以及我用哪些办法让模糊想法变成可验证的需求条目。1. 嵌入式需求获取为什么比普通软件需求分析更难1.1 需求不是等着被描述而是藏在六个角落里的信息做网站或App的需求调研核心动作通常是访谈用户、梳理业务流程、画线框图需求的主体基本是人和业务规则。但嵌入式系统不是这样软件需求往往要从六个完全不同的角落去拼客户或产品经理的描述这部分最容易获取但也最粗通常只有要能上报数据响应要快这类话。硬件原理图和PCB设计它决定了你有哪些GPIO、哪些外设、哪些中断源引脚复用冲突在哪。芯片数据手册和参考手册寄存器默认值、时序参数、电气特性、总线协议细节都在这里。现有代码和旧产品行为如果是做升级迭代上一版固件里那些没人敢动的逻辑就是隐藏需求。行业标准和规范比如医疗、汽车、工控领域合规需求不是客户提出来的而是强制要满足的。实际使用环境和运维方式设备装在高温车间还是低温户外现场有没有人维护供电稳不稳定把这六个来源的信息拼起来你才会发现需求真正的全貌。只盯着产品经理那一句话等于拿着地图上的一角去找宝藏能找到才怪。这里最反直觉的一点是嵌入式需求获取的大部分工作不是问人而是读物。我记得有个项目硬件工程师选了一颗带内部上拉的MCU但原理图上外部又加了一颗10kΩ上拉电阻这样做软件的人如果只读原理图而不看数据手册根本不会意识到内部上拉和外部上拉并联之后IO口电平变化时间参数会受影响进而影响按键检测逻辑。这种细节靠访谈是问不出来的必须自己沉到资料里去挖。1.2 说不明确的需求其实是差一道翻译很多人抱怨客户需求不明确我现在的看法是不是不明确是客户描述的是他所在领域的目标而软件需要的是另一个层面的约束。这两者之间差了一道翻译工序而这道工序恰恰是需求获取的核心。举个例子。产品经理说设备在低电量的时候不能丢数据。这句话听起来已经很明确了是吧但对嵌入式软件来说它至少要拆成下面几条才能落地检测到什么电压值算低电量是ADC采集到2.8V还是3.0V要不要用迟滞比较避免来回抖动检测到低电量之后允许系统继续运行多长时间是立刻进入掉电保护流程还是继续运行到最后一个数据写进Flash再关机掉电保护流程中哪些数据需要保存保存顺序是什么Flash写入一半又断电了怎么办重新上电之后怎么判断上次数据是否完整要不要启动时做CRC校验你看看一句不能丢数据背后至少挂着一串十几个问题。这些才是真正的软件需求。所以当有人跟我说需求不明确时我通常会回答需求不是不明确是我们还没有把它翻译成软件能执行的动作和判断条件。这里还有一个技术层面的翻译问题。嵌入式软件要直接跟硬件打交道很多需求必须落到寄存器配置中断行为时序参数这个粒度才有意义。客户永远不会说UART的中断服务程序里要在3字节时间之内读出数据但如果你不把这句话变成代码级需求实际跑起来就会丢字节。因此需求获取的过程本质上是一个不断下钻的过程每一条高层次目标都要追问到谁调用、什么时序、什么异常、什么边界为止。1.3 别让需求获取变成假访谈我见过不少团队所谓的需求获取就是开个会产品经理放一遍PPT大家点点头散会。这种形式主义的访谈除了浪费时间什么也拿不到。嵌入式系统的需求来源多半不在会议室里而在现场和图纸上。有一次我做一个工厂设备的数据采集模块前期跟客户开了三次会需求版本改到第二版感觉应该很稳了。后来我跟着客户去了一趟车间现场才发现设备旁边有一个大功率变频器现场电磁环境非常差而且操作工经常带着手套直接去按面板上的按键。这两个现场细节直接催生了两条新需求一条要求软件对传感器信号做更激进的低通滤波和去抖处理另一条要求触摸按键的有效触发时间放宽避免手套按压接触不良导致误判。如果只在会议室里访谈这两个需求根本不可能出现。所以大家在做需求获取时一定要给自己安排现场观察这个环节。哪怕只是去看看设备安装位置、旁边有什么干扰源、使用者怎么操作这些信息比聊十次微信都值钱。嵌入式系统是长在物理世界里的脱离物理环境谈需求等于蒙着眼睛画地图。2. 挖掘嵌入式需求的三个硬核突破口接口、时序、失败模式2.1 接口需求读芯片手册要读出默认值和边界值接口需求是嵌入式软件需求里最庞大的一类它决定你的代码怎么写、驱动怎么配。所谓接口需求不只是UART波特率9600这种简单描述它至少要包括信号方向、电平标准、上下拉配置数据格式、字节序、位数、校验方式有没有硬件流控、有没有应答机制外设的时钟使能和中断配置引脚复用冲突时的优先级规则上电默认状态和不用的引脚怎么处理。我习惯的做法是把每个主要外设做成一张接口需求表每条都标注来源——是硬件原理图、芯片手册还是客户指定。比如下面这张简化版需求编号外设/接口需求描述验收标准来源I2C-01I2C1总线时钟频率不超过400kHz支持7位地址模式用示波器测量SCL频率在380-400kHz之间芯片手册硬件原理图SPI-02SPI2片选片选信号在每次传输前至少拉低100ns逻辑分析仪测量满足100ns以上硬件工程师确认UART-03UART1接收接收数据在3字节时间内未被读取则置溢出标志连续发送数据软件在3字节时间内读取不丢数据数据手册客户经验读芯片手册的时候我建议大家特别标出两个东西默认值和边界值。默认值决定上电瞬间硬件处于什么状态边界值决定你的软件在极端条件下应该怎么表现。比如某颗MCU的GPIO在上电复位期间默认是浮空输入如果你的负载在这段时间里需要保持确定电平软件就必须尽快配置引脚甚至在硬件上就要加下拉电阻。这条上电瞬间引脚状态的需求十有八九不会出现在需求文档里但它真的是需求。我做过一个电动阀门控制器产品的需求文档里完全没有提到上电瞬间阀门会怎样。但硬件原理图显示阀门的驱动MOS管由MCU的一个GPIO控制而MCU在上电复位期间I/O是浮空输入。我特地在需求获取阶段抓着硬件工程师问了一句这个引脚在上电到固件完成配置之前有没有可能被外部噪声拉到高电平硬件工程师想了想说有可能。就是这一问催生了一条新的软件需求固件启动代码要在最早的阶段把该引脚配置为下拉输出并保持在低电平同时硬件上在门极加了下拉电阻。后来实测发现如果不处理上电瞬间阀门确实会误动作一下。这个案例我一直记着因为它说明接口需求的源头是硬件在软件运行之前的行为而不是配置好之后的行为。2.2 时序需求把得快变成多快、在多差的情况下嵌入式系统里时序需求极其重要但也是最容易被糊弄过去的。响应快延迟低实时性好这类词在需求文档里出现多少次后面的麻烦就有多少。真正可用的时序需求必须包含三个要素起点、终点、约束值。起点是什么事件按键按下、中断到来、报文接收完成、定时器溢出终点是什么动作LED点亮、数据写入Flash、执行器动作、报文发送完毕约束值是多少绝对时间还是相对时间要不要区分最坏情况、典型情况举个例子一个AD采样系统客户说采样要及时。我最后和软硬件两边一起把这句话拆成了三条需求需求编号时序场景需求描述验收标准T_ADC_01采样启动ADC采样周期可配置为1ms/10ms/100ms精度±0.02ms用示波器测量ADC转换完成中断间隔T_INT_01中断响应从ADC转换完成中断产生到DMA搬运完成最长不超过10μs在中断服务程序置位GPIO示波器测量T_CTL_01控制输出从控制器计算完成到执行器PWM占空比更新时间不超过2ms通过调试接口记录时间戳很多时候客户或者产品经理说不出这些数字这不奇怪。需求的数字要从哪里来一是芯片手册和硬件本身决定的上限比如ADC转换需要多少时钟周期DMA搬运要多长时间二是客户对系统行为的期望比如从按下急停按钮到电机停转必须小于100ms这个来自安全要求三是和硬件工程师协商的结果比如有些时序在协议和机械执行上根本做不到那么快。我一般会建议需求获取时做一次最坏情况分析。嵌入式系统跑起来之后最怕的是平均时序满足、最坏时序翻车。比如CAN总线平常发一帧20ms足够了但如果总线负载率一高仲裁和重发会占用大量时间。你要问自己的需求是在最坏负载下最高优先级报文的发送周期还能不能保证如果不能就要列出总线负载超过某个阈值时允许丢帧但不允许错误帧这类带明确条件的需求。还有一个容易踩的坑是中断延迟。中断延迟不只是CPU响应中断的时间还包括你关闭中断保护临界区的时长。有些项目在需求里写了要求系统实时性高但代码里有一个长达5ms的临界区所有中断都被关掉。这种问题在需求获取阶段就该被问出来哪些中断是绝对不能延迟超过多少时间的临界区的长度上限是多少问出来之后团队成员写代码时才有据可依而不是凭感觉。2.3 失败模式需求获取的高地写给系统坏了之后的行为如果只能提高一个需求获取的段落我会选失败模式需求。功能需求是让你知道系统应该做什么失败模式需求是让你知道系统不该做什么、坏了之后做什么。嵌入式系统的可靠性很大程度上是由后者决定的。失败模式需求从哪来我的经验是三个来源安全意识。硬件和系统可能出现的故障比如电源跌落、晶振停振、通信中断、外部看门狗复位、Flash读写失败、传感器信号开路/短路。现场经验。老员工会告诉你这个板子有时候会莫名其妙复位这种玄学背后往往藏着真正的故障需求。行业标准。比如工控行业会要求故障时设备必须进入安全状态并停止输出。在需求获取访谈中我问得最多的一个问题就是如果这个功能在执行到一半的时候系统断电了/被干扰了/输入数据乱掉了你希望它怎么做这个问题一抛出去现场往往是沉默但沉默之后挖出来的东西都是宝贝。举个实际例子。我们做过一个数据记录仪要求把传感器数据每隔5分钟写入一片外部Flash。正常功能需求很简单写进去、下次开机读出来。但我在需求获取阶段反复追问如果写Flash写到一半断电怎么办最终得到了一条非常重要的需求写入采用双备份机制先写主区再写备份区启动时检查两个区的CRC哪个有效读哪个如果都无效格式化并重新开始记录但必须置一个数据异常标志。这条需求一旦缺失设备在现场掉电一次所有历史数据就全没了用户肯定会投诉。下面是我整理的一个失败模式问题清单做嵌入式需求获取时可以直接拿过去用系统上电时某外设没有就绪是等待还是报错通信连续失败多少次之后需要执行什么动作看门狗超时复位之后是要恢复到之前的状态还是回到安全初始态传感器读数超过量程上限或低于量程下限算有效还是无效要不要报故障写内部Flash半途断电下次启动如何识别数据损坏外部接口直接短路或接反设备会不会损坏软件怎么防护电池电量耗尽前系统还剩多少时间完成关键数据保存这些问题不需要都问但你必须根据项目特点挑出最关键的几个。做低功耗电池产品的重点关注掉电流程做工业通信的重点关注通信故障重试做电机控制的重点关注安全停车路径。需求获取的功力很大一部分就体现在这里在别人觉得没问题的地方多问一句有问题怎么办。3. 一次嵌入式需求获取的完整操作链路3.1 开工前要备齐的物料与角色很多人把需求获取理解成开会但实际上它更像一次多方参与的联合勘察。开工前我会确保下面这些物料到位硬件原理图、PCB版图、芯片数据手册这是接口需求的底稿旧产品代码或竞品实物如果有的话用于反推需求尤其是那些客户描述不清的细节需求记录模板我通常用统一的Excel或表格每行一条需求字段包括编号、来源、描述、验收标准、优先级、负责人、状态已识别的场景清单比如正常上电、正常关机、应急停机、通信中断、固件升级等录音笔或笔记本访谈一定要留底但录音前先征得对方同意。参与角色方面除了软件工程师和产品经理至少要把硬件工程师、测试工程师拉进来。硬件工程师能解答为什么这个引脚这么接这个外设能不能这样操作测试工程师能在需求还没定型时就发现这条需求根本没法测。我现在特别看重测试工程师在需求阶段的价值因为一个可测试性差的需求在开发阶段几乎一定会在返工时炸开。这里有个小提醒需求获取时最好让写代码的人和做需求的人尽量是同一批人或者至少有软件工程师全程参与。嵌入式需求获取的很多信息是非语言的比如硬件工程师画波形图时的某个细节、FAE在电话里随口说的一句这个外设有点坑。这些信息如果通过二手转述往往会被过滤掉关键成分。3.2 需求获取会议怎么开提问清单和现场观察需求获取的正式会议我一般不按照逐页读PPT的形式走而是分成三个环节先听再问再验。先听让客户或产品经理完整描述他们想要的功能和场景不打断、不反驳。这个环节的目的是捕捉原始表述比如希望电池能用一年想能在手机上查看设备状态。这些原始表述后面都要翻译成需求先别急着纠正。再问按我前面说的方向去挖掘。我常用的问题模板有你说的XX具体在什么使用场景下发生发生的时候周围还有什么设备在运行如果XX达不到你能接受的底线是什么这个功能之前有没有类似产品当时最不满意的是什么设备出故障时你希望看到什么现象有没有绝对不能发生的情况再验把初步整理出的需求条目当场复述给对方特别是把含糊的词语替换成具体数字问我这样理解对不对。比如对方说数据要尽快上报你回一句如果我们把要求定为从数据采集到云端收到数据最迟不超过10秒可以接受吗对方如果说可以或者不行要更快你就拿到了有效信息。这个过程我总是反复确认至少确认两遍才不会在后期被一句我可没这么说噎住。现场观察也建议在需求获取阶段做。我自己的经验是现场观察能发现很多连客户自己都没意识到的问题。比如某个操作工为了省事没有按规定先关设备再拔通信线而是热插拔这个行为就会衍生出一条通信接口要支持热插拔并自动重连的需求。你不去现场永远也想不到。3.3 把零散记录转成需求规格的翻译三原则访谈结束后几十条原始记录摆在那里怎么变成一份像样的需求规格我在实践里形成了三个翻译原则分享给大家参考。原则一动词加对象加条件加数字。每一条需求描述都要包含明确的动作、动作对象、执行条件和量化边界。如果某一条需求里出现了快速稳定尽可能适当这类词就必须重新改写直到所有形容词都能被数字替代。原则二区分系统要做什么和软件要做什么。有些需求其实应该由硬件实现比如滤波可以放在硬件RC电路上也可以放在软件里。在需求阶段就明确分工能避免后续扯皮。我的做法是每一条需求在翻译时都标注实现域软件、硬件、软硬件协同。软硬件协同的需求要特别注明双方接口比如硬件提供上升沿中断软件在中断服务程序中去抖并置事件标志。原则三为每条需求写下可验证的验收标准。验收标准可以是测试用例的输入输出描述、测量仪器的预期数据、或者对特定操作步骤的预期响应。如果没有验收标准这条需求就是欠考虑的。比如系统应检测到超温验收标准应该是将热敏电阻置于95℃环境中LED在2秒内点亮并上传告警帧。举个翻译前后的例子方便大家对照原始表述来自客户这个设备得能在断电的时候保存好参数。翻译之后REQ-A-01当输入电压低于3.0VADC采样值对应电压时系统在100ms内产生掉电中断并进入掉电保存流程。REQ-A-02掉电保存流程应在50ms内完成参数区写入操作写入内容包含设备地址、校准系数、累计工作时长。REQ-A-03参数区采用双备份存储写入顺序为先备份区后主区写入完成后校验CRC。REQ-A-04若在写入过程中发生二次断电上电恢复时检测到主区或备份区CRC异常则使用有效区数据并置参数恢复标志。看见没有一句话最终变成四条需求每条都有明确的触发条件和验收方向。这样做出来的需求规格软件工程师拿到手可以直接开始设计测试工程师拿到手可以直接写用例整个过程几乎不需要猜。4. 让需求立得住编号、可测试性、评审和追溯4.1 强制给每条需求编号并配上验收标准需求规格一定是结构化的文档不是一篇散文。嵌入式项目的需求条目我建议按功能区划分编号前缀例如前缀含义FUNC-功能性需求TIME-时序性需求IF-接口需求ERR-异常/故障处理需求RES-资源需求Flash、RAM、功耗SEC-安全与合规需求OTH-其他需求每条需求一个唯一编号后续的代码注释、测试用例、变更记录里都要引用这个编号。这样做的价值在项目后期会体现得淋漓尽致客户说我要改一下那个上报逻辑你只要查到对应的需求编号就能顺藤摸瓜找出相关的代码模块和测试用例评估影响范围。每条需求必须包含几个固定字段需求编号、需求描述、验收标准、来源、优先级、状态草稿/评审通过/已实现/已验证、变更历史。我个人还会加一个实现域字段标明是软件、硬件还是软硬件协同这个字段对排计划帮助很大。有人觉得这套流程太重小项目没必要。我的体会是哪怕只有二十条需求也值得模板化。因为没有编号的需求在评审会上根本没法讨论没有验收标准的需求在测试阶段就是无头公案开发说我实现了测试说我觉得没实现吵半天没结果。一套轻量的编号加验收标准机制能省掉太多这样的内耗。4.2 需求追踪矩阵怎么搭才有实际作用需求追踪矩阵RTM这个词听起来很庞大但在嵌入式项目里它的本质就是一张需求到哪里去了的对照表。对我而言RTM至少有四列需求编号、设计/代码模块、测试用例、硬件接口。需求编号代码模块/文件测试用例关联硬件接口TIME-01adc_driver.c, control_loop.cTC_ADC_TIMING_01ADC1, DMA1IF-02uart_driver.c, protocol.cTC_UART_FRAME_01UART2, RS-485ERR-03flash_save.c, watchdog.cTC_FLASH_POWERLOSS_01内部Flash实际建RTM的时候我一般不会在需求阶段就把所有细节填满而是先搭骨架需求编号和硬件接口必须一开始就有代码模块在详细设计阶段填上测试用例在测试计划阶段填上。三个角色各自负责填写自己的那部分谁填谁维护这样矩阵才不会因为没人维护而腐烂。RTM最有价值的用法是变更影响分析。有一次客户要求在通信协议里增加一字节的版本号看起来是小改动。但我通过RTM一查受影响的不只是protocol.c还包括BootLoader的跳转条件、上位机的解析代码、产线测试脚本。这几处如果漏改任何一个都会出线上事故。如果没有RTM你很难在评估阶段就发现这些隐性关联。4.3 评审会宁可慢也要把五个问题问透需求评审是需求获取的收口环节。我参加过太多走过场的评审会主持人一句大家的需求都清楚了吧就散了。真正有效的评审会应该围绕下面五个问题逐一过堂每条验收标准可测量吗有没有出现不能用数字表达的形容词异常路径覆盖了吗特别是上电、断电、复位、通信超时这几个场景。硬件团队确认过接口需求吗每个寄存器、每个引脚的定义有没有歧义将来出问题、需求变更时受影响的范围有多大有没有漏掉关联模块测试团队说能测了吗如果测试团队说某条需求没法验证说明它还不够具体。评审会的主持人最好不是需求撰写者本人因为作者容易带着我已经写清楚了的滤镜。我习惯把硬件工程师和测试工程师都留在评审桌上让他们从各自的角度挑刺。这个环节慢一点没关系需求阶段多花一天开发阶段就能少返工一周。我还发现一个很实用的做法评审时给每条需求标一个信心指数1到5分5分表示完全清楚、完全可测1分表示模糊不清。把信心指数低于3分的需求当场挑出来现场讨论直到所有人都能达成一致。这个操作看起来简单但能把大家以为都懂、其实没人真懂的隐性分歧逼出水面。5. 嵌入式需求最容易漏掉的三类问题及规避经验5.1 上电瞬间、断电瞬间和复位瞬间普通软件需求关注的是系统稳定运行期间的行为而嵌入式系统的大量bug出在状态的转换瞬间上电、断电、复位、从低功耗模式唤醒。这三个瞬间的需求几乎不会有人主动提但少了它就是会出事。上电瞬间要搞清楚的事包括MCU复位期间各引脚是什么电平外部负载会不会被这个电平触发固件配置外设需要多长时间这期间系统处于什么状态如果固件加载时间较长外部电路需不需要额外的复位信号来维持安全状态断电瞬间要搞清楚的事包括电源跌落有没有迟滞触发阈值检测到低电压之后系统还剩多少可用时间需要保存哪些关键数据用什么顺序写才能最大限度地避免数据损坏复位瞬间要搞清楚的事包括看门狗复位和上电复位要不要区分如果是看门狗复位系统是恢复到默认状态还是尝试恢复现场复位之后要不要记录复位原因我这些年几乎在每个项目里都会把状态转换瞬间单独列为一节需求哪怕最后只写出两三条也比完全空白强。5.2 通信协议需求中的沉默与重试通信协议是嵌入式系统里的另一个需求缺口大户。写协议需求的时候大家通常能想到帧格式、波特率、校验方式但很容易漏掉三个东西沉默、超时、重试。沉默设备多久没有收到主站报文就要认为连接断开了这个断线判定时间必须是一个明确定义的数字不能是过一会儿。超时发送一帧请求后等待多久没收到应答算失败失败之后是重发还是报错重发几次重发间隔多少重试连续多少次重发都失败之后系统进入什么状态是继续静默等待还是切换到本地控制模式还是报警停机这些决策每个都很关键因为现场通信环境往往很嘈杂设备动不动就收不到报文。如果没有明确定义的超时和重试策略固件可能陷入无限等待、重复发帧、或者乱报故障的尴尬状态。我举个具体例子。有一个Modbus RTU的项目需求文档里写了从站收到主站请求后应回复但没写如果请求帧本身有CRC错误怎么办。我们团队一开始写了一个很简单的处理接收中断里直接丢弃错误帧。结果现场发现主站软件在恶劣电磁环境下会发出一些残缺帧而从站没有任何提示主站那边死活收不到回应排查了很久。后来我们在需求里补了一条收到CRC错误帧时从站应静默丢弃并记录错误计数同时可通过状态寄存器读取该计数。这样既不影响协议正确性又给排查问题提供了抓手。5.3 兼容性需求不写就是给自己埋雷嵌入式项目的兼容性需求很容易被忽略因为大家都默认新版本应该兼容旧版本。但默认两个字在需求管理里是最危险的。做过量产设备的朋友应该有体会设备卖出去之后有些客户就是不升级固件有些客户的协议停留在旧版有些客户手上还握着旧版的上位机软件。如果你的新固件在需求规格里没有写明必须兼容旧版协议开发人员很可能想当然地改了协议格式然后客户现场炸锅。写兼容性需求时我建议把兼容场景写具体而不是写一句保持兼容就完事。比如REQ-COMP-01固件升级后设备参数区原有校准数据应保留不能因版本升级而丢失。REQ-COMP-02新固件默认仍支持旧版上报协议寄存器地址0x01-0x10同时可通过配置切换为新版协议。REQ-COMP-03BootLoader跳转时如果检测到旧版本应用程序应允许一次升级流程并保留用户配置区。把这些兼容场景逐条写出来开发人员才知道兼容到底要在代码里做到什么程度。哪怕最后实现的时候发现有些场景成本太高、可以不做那也应该是经过讨论后明确砍掉的而不是糊里糊涂漏掉的。6. 工具选型和持续推进的落地心得6.1 中小团队够用的轻量需求管理方案很多人一想到需求管理工具就觉得要上那种重型商业平台。但对中小型嵌入式团队来说最好的方案往往是最轻的那个。我现在常用的组合是需求文档用Markdown或Word写按功能模块拆分文件名带版本号放在Git仓库里和代码一起管理。需求追踪矩阵用Excel或在线表格维护列见前面那张表谁改谁更新。需求变更记录用Git提交历史加ChangeLog任何变更都要留痕写明变更原因和影响范围。评审记录可以直接用Git的Merge Request来做评审意见留在代码仓库里方便追溯。这套组合的好处是零额外成本团队本来就在用Git换工具几乎没有学习成本。缺点是没有自动化的关联提醒变更影响分析要靠人工查RTM。但说实话对一个几百条需求的中小项目人工查表并不费事比起上重工具的管理成本轻量方案效率反而更高。如果是大型项目或者行业有明确合规要求那还是得上专业工具。但我个人的建议是先把自己的需求文档结构和编号规则跑顺再考虑工具而不是指望工具自动帮你解决需求混乱的问题。工具只是放大器不会把混乱变整洁。6.2 需求变更和冻结的节奏怎么控制需求获取不是一次性的整个开发过程中需求都会变。关键是要控制变更的节奏别让需求规格变成一个永不停摆的摇摆钟。我习惯在项目里设两个节点需求基线冻结节点和里程碑变更评审节点。需求基线冻结一般发生在详细设计开始之前冻结之后任何需求变更都要走正式的变更流程提出变更申请、描述变更内容和原因、评估影响范围代码、测试、时间、风险、评审通过后才允许修改需求文档。这里最难的是冻结两个字。总有人想塞新需求尤其客户。我的经验是冻结不代表拒绝需求而是给需求变更一个正式的入口和审查机制。你完全可以答应客户新增需求但要在需求变更单上写明这对进度和成本的影响让客户自己判断值不值。这样做既能维护需求基线又不会把客户得罪光。我还要提醒一点每次需求变更一定要同步更新RTM和测试用例。很多项目的RTM之所以烂掉就是因为它只在写需求的时候更新过一次之后需求变了没人去改矩阵。我的做法是需求变更评审通过的同时RTM的维护任务必须一并立项变更单不关RTM不算完。6.3 给嵌入式团队的一份实操检查清单最后我把自己在需求获取阶段常用的检查清单整理出来分享给大家。它不是标准答案但每次照着过一遍基本能把80%的需求窟窿堵上。芯片手册里所有外设的默认值和边界值是否都已经阅读并转化成了软件需求每个GPIO在上电瞬间的电平状态是否明确是否可能触发外部负载所有尽快稳定适当这类词是否都已经替换成了具体数字每条需求是否都有唯一编号、验收标准、来源和实现域启动、停止、复位、低功耗唤醒这四个状态转换场景是否各有至少一条需求通信协议的帧格式、超时、重试、错误处理是否都有明确定义硬件团队、软件团队、测试团队是否都参加了评审会RTM是否已经搭好骨架并指定了后续更新责任人如果今天需求冻结还有哪个模块会让开发人员在写代码时犹豫超过十分钟我自己每次项目启动时都会打印一份这种清单放在桌上做完一项划一项。它帮我避开了不少坑也让我在需求评审会上更有底气说这条已经问清楚了那条还差两个问题。嵌入式软件的需求获取从来不是一件浪漫的事它更像是在做一个持续逼近真相的过程。很多需求不是一开始就摆在桌面上的而是要靠一只螺丝刀、一块万用表和一堆反问从硬件手册、现场环境和客户那句漫不经心的话里挖出来。挖得越深后面设计和测试就越顺。希望我这些实践心得能帮大家少走一些弯路。