第一章：需求分析与规格定义——如何读懂一份PRD

做数字IC设计这么多年，我见过太多项目死在第一步。

需求没搞清楚，后面所有工作都是白费。今天咱们聊聊怎么把一份PRD（产品需求文档）转化成我们IC工程师能用的技术规格书（Spec）。

1.1 PRD到底是什么？

PRD，全称Product Requirements Document。说白了，就是产品经理写给研发看的「愿望清单」。

但问题在于——产品经理的思维和工程师的思维完全不同。他们关心的是「用户要什么」，我们关心的是「电路怎么实现」。

我遇到过最夸张的一次，PRD上写着「低功耗设计」。结果一开会，产品经理说的低功耗是待机0.1mW，我们理解的是1mW。差了一个数量级，整个架构都得重来。

1.2 如何拆解PRD？

拿到一份PRD，我建议按这个顺序来读：

1. 先看功能列表——芯片要干什么
2. 再看性能指标——做到什么程度
3. 最后看接口定义——怎么跟外界通信

嗯，这里要注意。很多新人上来就盯着接口看，结果功能理解偏了，接口再对也没用。

1.3 模糊需求的「翻译」技巧

产品经理最爱说模糊话。我总结了一套「翻译对照表」：

PRD原文	工程师需要确认	我的经验
「高性能」	具体频率？吞吐量？	问清楚是峰值还是持续性能
「低功耗」	功耗预算？工作模式？	要区分动态功耗和静态功耗
「兼容性好」	兼容哪些协议？版本？	最好列出具体测试用例
「实时性要求高」	延迟上限？抖动容忍？	我曾经被「实时」坑过，后来发现是软实时

1.4 从PRD到Spec的转化流程

这一步是核心。我一般分四步走：

第一步：提取关键参数

把PRD里所有数字、范围、协议名称摘出来。比如「支持1080p@60fps视频输入」——这里的关键参数是：分辨率1920x1080，帧率60fps，像素时钟大约148.5MHz。

第二步：补充隐含需求

PRD不会告诉你「需要多少存储空间」「需要多少带宽」。这些得自己算。我习惯画个数据流图，标出每个模块的吞吐量。

第三步：定义接口时序

这是最容易出问题的地方。PRD说「支持I2C接口」，但没说是标准模式还是快速模式。我建议直接写进Spec：「I2C接口支持100kHz/400kHz两种速率」。

第四步：设定设计边界

比如工作温度范围、电压波动、工艺角。这些PRD通常不提，但Spec里必须写清楚。

1.5 知识体系框架

下面这张图是我自己总结的「需求到规格」的转化流程。每次做新项目，我都会先过一遍这个框架：

1.6 实战案例：一个视频处理芯片的需求转化

拿我最近做的一个项目举例。PRD原文是这么写的：

「本芯片用于智能摄像头，需要支持1080p视频采集，
内置AI识别功能，功耗要低，成本要控制。」

你看，全是模糊词。我是这么转化的：

第一步：跟产品经理确认

• 1080p是30fps还是60fps？——答：30fps就够了
• AI识别是实时还是离线？——答：实时，延迟不超过100ms
• 功耗具体多少？——答：整芯片不超过1W
• 成本目标？——答：BOM成本控制在$5以内

第二步：写进Spec

技术规格书（节选）：
1. 视频输入：1080p@30fps，MIPI CSI-2接口，4-lane
2. AI加速：支持CNN推理，延迟<100ms（典型场景）
3. 功耗：典型工作模式<800mW，待机<50mW
4. 工艺：40nm LP，芯片面积<25mm²
5. 封装：QFN-48，满足BOM成本目标

1.7 常见误区与避坑指南

做需求分析这么多年，我总结了几条血泪教训：

• 别信「参考设计」——产品经理说「参考XX芯片」，但参考设计往往只覆盖80%的场景。剩下的20%才是坑。
• 别忽略测试需求——PRD很少写测试相关的内容。但Spec里必须定义：怎么测？用什么测？通过标准是什么？
• 别忘记版本管理——需求一定会变。我习惯在Spec开头加个修订记录表，每次变更都写清楚原因和时间。

好了，关于需求分析和规格定义，今天就聊这么多。记住一句话：Spec写得越细，后面流片越稳。

---

公众号:蓝海资料掘金营，微信deep3321