一、需求追踪与验证概述
什么是需求追踪
需求追踪，说白了就是给每个需求发一张「身份证」。
从客户说「我想要一个能自动关机的功能」开始，到设计文档、代码实现、测试用例，再到最终产品验证——每一步都要能对上号。我个人习惯把这个过程叫做「需求的一生」。
举个例子：
客户要求「设备在无操作30分钟后自动关机」。这个需求会变成：
- 需求编号：REQ-001
- 设计文档里：低功耗状态机设计
- 代码里：timer_countdown() 函数
- 测试用例：TC-001 验证30分钟自动关机
- 验证报告：PASS/FAIL
你看，从源头到终点，每个环节都能追溯。这就是需求追踪的核心——双向可追溯。
关键点：需求追踪不是简单的「记录」，而是「关联」。每个需求都要能向前追溯到原始需求，向后追溯到实现和验证。
为什么需要验证
我在项目中遇到过一件事，印象特别深。
有个同事写了段代码，功能看起来完全正常。但到了现场，设备在高温环境下频繁重启。查了两天才发现——代码里有个变量没初始化，常温下碰巧是0，高温下就变成了随机值。
为什么会这样？
因为只做了功能验证，没做边界条件验证。
验证的目的，说白了就是回答三个问题：
- 做对了没有？（功能正确性）
- 有没有做错？（异常处理）
- 能不能稳定跑？（可靠性）
你想想看，嵌入式系统不像手机App，死机了重启就行。医疗设备、汽车电子、工业控制器——这些系统出问题，后果可能是灾难性的。
警告：不要等到产品量产了才发现需求没验证到位。我曾经见过一个项目，因为漏掉了一个时序需求，导致批量生产的5000块板子全部要返工。成本损失超过50万。
嵌入式开发中的痛点分析
做嵌入式这么多年，我总结了几大痛点。嗯，每个都是踩过坑的：
| 痛点 | 具体表现 | 后果 |
|---|---|---|
| 需求模糊 | 「响应要快」——多快？100ms还是10ms？ | 开发与测试标准不一致 |
| 硬件依赖 | 软件写好了，硬件还没回来 | 验证周期被压缩 |
| 环境复杂 | 温度、湿度、电磁干扰、振动 | 实验室能跑，现场就崩 |
| 资源受限 | RAM只有64KB，Flash只有512KB | 测试工具跑不起来 |
| 变更频繁 | 客户今天改需求，明天改接口 | 追踪链断裂 |
我重点说说第一个痛点——需求模糊。
有一次，客户说「按键响应要灵敏」。我们理解成200ms去抖，结果客户要的是50ms。产品做完了，客户说不行。改？硬件已经定型了，软件怎么调都达不到要求。
这就是典型的需求没有量化。
怎么解决？我建议：
- 所有需求必须带数字指标
- 「响应快」→「按键按下到LED亮起不超过50ms」
- 「功耗低」→「待机电流小于10μA」
- 「稳定可靠」→「连续运行72小时无重启」
小技巧：写需求的时候，想象自己是个测试工程师。如果这个需求没法写测试用例，那它就不够具体。我曾经用这个方法，把项目初期的需求返工率从40%降到了15%。
再说说硬件依赖的问题。
很多嵌入式项目是软硬件并行开发的。软件写完了，硬件还没回来。怎么办？
我的做法是：
- 尽早做硬件仿真——用FPGA或者开发板模拟
- 写硬件抽象层——软件不直接操作寄存器，通过HAL层隔离
- 做持续集成——每天自动编译、自动跑单元测试
这样等硬件回来了，软件已经验证了七八成。剩下的就是联调。
最后说说变更频繁的问题。
嵌入式项目最怕的就是需求变来变去。今天加个功能，明天改个接口。追踪链很容易断。
我建议用需求管理工具，比如Jama、Doors或者Polarion。每个需求变更都要走流程：
- 变更申请 → 影响分析 → 评审 → 批准 → 实施 → 验证
别嫌麻烦。我见过一个项目，因为没走变更流程，一个需求的修改导致三个模块的测试用例全部失效。最后花了两个星期才把问题理清楚。
总结一下：需求追踪和验证，不是「做完就行」的事。它贯穿整个嵌入式开发周期。从需求分析到产品交付，每一步都要有据可查。只有这样，才能做出真正可靠的产品。
下一章，我会详细讲怎么搭建需求追踪矩阵。到时候给你看看我实际项目中用的模板。