需求分析复盘：如何精准理解项目需求？
做FPGA项目这么多年，我踩过最大的坑，往往不是代码写错了，而是需求理解偏了。你想想看，辛辛苦苦调了一个月的模块，结果发现客户要的根本不是这个功能——那种感觉，真叫一个欲哭无泪。
今天我们就来聊聊需求分析这件事。说白了，就是怎么把别人嘴里说的、文档里写的，变成你脑子里清晰的、可执行的方案。
一、常见需求理解偏差案例
先讲几个我亲身经历过的案例，你看看有没有共鸣。
案例1：接口时序理解偏差
有一次，客户说“用SPI接口就行”。我心想SPI嘛，简单。结果做完了联调，发现客户用的是SPI模式3，我默认做了模式0。就这一个细节，改版花了三天。
后来我学乖了——凡是接口类需求，必须明确：时钟极性、相位、数据格式、字节序、速率上限。少问一句，后面就是坑。
案例2：性能指标模糊
“这个模块要处理高清视频流。”听起来很明确对吧？但高清是1080p还是4K？帧率30还是60？色彩深度8bit还是10bit？这些不搞清楚，你的带宽计算就是空中楼阁。
案例3：边界条件遗漏
我记得有个项目，需求文档写了“支持数据重传”。我们做了完整的重传机制，结果测试发现，当重传次数超过255次时，计数器溢出了。客户说“我以为你们会考虑无限重传”。嗯，这就是典型的边界条件没说清楚。
二、需求理解的核心方法
怎么避免这些偏差？我个人习惯用三步法：
- 复述确认：听完需求后，用自己的话复述一遍。“我理解您的意思是...对吗？”这一步能过滤掉80%的误解。
- 量化拆解：把模糊的描述变成具体的数字。比如“低延迟”变成“端到端延迟小于5us”。
- 反向提问：主动问“如果...会怎样？”的场景。比如“如果输入数据速率超过最大值，应该丢弃还是缓存？”
小技巧：我习惯在需求沟通时，用一张白纸画时序图。画着画着，很多隐藏的问题就浮出来了。你试试看，比光用嘴说有效得多。
三、需求文档的撰写技巧
好的需求文档长什么样？我总结了几个要点：
| 要素 | 要求 | 反面案例 |
|---|---|---|
| 功能描述 | 明确输入输出、处理逻辑 | “实现数据过滤” |
| 接口定义 | 信号名、位宽、方向、时序 | “用标准接口” |
| 性能指标 | 具体数值、测试条件 | “越快越好” |
| 边界条件 | 异常处理、极限情况 | “正常情况即可” |
| 验证标准 | 通过条件、测试用例 | “功能正确” |
写文档时，我建议用“5W1H”框架：
- Who：谁用这个模块？
- What：输入是什么？输出是什么？
- When：什么时候触发？时序要求？
- Where：在哪个层级实现？
- Why：为什么需要这个功能？
- How：怎么实现？资源约束？
避坑指南：我曾经见过一份需求文档，写了30页，全是文字描述，没有一张时序图。结果开发团队对“上升沿采样”还是“下降沿采样”争论了两天。所以，能用图说清楚的，别用文字。
四、需求评审的实战技巧
评审不是走过场。我参与过几十次需求评审，总结了几条经验：
- 提前发文档：评审会前48小时发出去，让大家有时间消化。会上直接讨论问题，而不是现场读文档。
- 角色扮演：评审时，我习惯让团队轮流扮演“杠精”。专门挑刺、找漏洞。虽然过程有点痛苦，但效果很好。
- 检查清单：准备一份需求检查清单，逐项核对。比如：接口时序是否明确？异常路径是否覆盖？资源估算是否合理？
我的习惯：评审结束后，我会把修改点用红色标注在文档上，然后发一封确认邮件。白纸黑字，后面扯皮的时候这就是证据。别笑，真遇到过客户说“我没说过这个”的情况。
五、需求分析的知识体系
下面这张图，是我自己总结的需求分析流程。每次接新项目，我都会走一遍这个流程：
这张图的核心逻辑是：需求获取 → 量化分析 → 分类拆解 → 文档输出 → 评审闭环。每一步都不能跳，跳了就要付出代价。
六、写在最后
需求分析这件事，说难不难，说简单也不简单。我见过太多项目，代码写得漂漂亮亮，结果方向错了，全白干。
记住一句话：花在需求分析上的时间，永远是最值得的投资。你省下来的那两天，后面可能要花两周来补。
好了，今天就聊到这里。下次我们聊聊模块划分和接口定义——这两个环节做好了，后面的编码就是水到渠成的事。
公众号:蓝海资料掘金营，微信deep3321