第二章：项目需求分析——市场调研、竞品分析与需求文档撰写
大家好，我是你们的老朋友。今天咱们聊聊红外探测器项目里最容易被忽视、却又最要命的一环——需求分析。
很多人一上来就画原理图、选芯片，恨不得明天就出样机。我见过太多这样的团队，忙活半年，做出来的东西市场根本不买账。为什么？因为需求没搞清楚。
说白了，需求分析就是回答三个问题：卖给谁？凭什么卖？做成什么样？
这一章，我把自己踩过的坑、总结的方法，全部分享给你。
核心观点：需求分析不是写文档，而是做决策。每一个需求点，都对应着成本、性能、时间的取舍。
2.1 市场调研方法——别拍脑袋，去现场
我刚开始做产品时，也犯过「我觉得市场需要这个」的错误。结果呢？样机做出来，客户说「这玩意儿我们早有了」。尴尬不？
市场调研，说白了就是搞清楚三件事：
- 目标市场有多大？——是千亿级还是千万级？决定了你的投入力度。
- 用户是谁？——工业用户、安防用户、还是消费电子？需求天差地别。
- 痛点是什么？——现有产品哪里不好用？哪里贵？哪里容易坏？
我个人习惯用「三源法」做调研：
- 一手源：直接拜访客户，看他们怎么用现有产品。我记得有一次去一个化工厂，发现工人把红外探测器用胶带缠在管道上——因为原装支架太贵了。这就是需求！
- 二手源：行业报告、展会资料、专利分析。别全信，但能帮你建立全局观。
- 数据源：电商平台评论、论坛吐槽、售后维修记录。这些是真实的「用户声音」。
小技巧：调研时多问「为什么」。用户说「我要更远的探测距离」，你要追问「你现在多远不够用？什么场景下不够？」。很多时候，用户说的需求只是表象。
2.2 竞品分析——知己知彼，百战不殆
竞品分析不是抄作业，而是找差距、找机会。
我一般从三个维度拆解竞品：性能、成本、尺寸。这三个维度互相制约，你想想看——性能做高了，成本必然上去；尺寸做小了，散热可能出问题。
下面是我做的一个真实竞品对比表（数据已脱敏）：
| 参数项 | 竞品A | 竞品B | 竞品C | 我们的目标 |
|---|---|---|---|---|
| 探测距离（m） | 50 | 80 | 120 | 100 |
| 视场角（°） | 30 | 45 | 60 | 50 |
| 响应时间（ms） | 200 | 150 | 100 | 120 |
| BOM成本（元） | 85 | 120 | 180 | 110 |
| 外形尺寸（mm） | 60×40×25 | 50×35×20 | 45×30×18 | 48×32×20 |
| 防护等级 | IP54 | IP65 | IP67 | IP65 |
看到这个表，你会怎么定目标？
我的做法是：不追求每一项都第一，而是找到「最优性价比区间」。比如竞品C性能最好但太贵，竞品A便宜但性能差。我们卡在中间，用110元的成本做到100米探测距离，这就是差异化。
避坑指南：我曾经犯过一个错——只盯着头部竞品。结果产品做出来，发现市场已经被无数小厂用低价产品吃掉了。记住，竞品分析要覆盖高中低三个档次。
2.3 用户需求文档（URD）撰写——把「想要」变成「需要」
URD是给产品经理、市场、销售看的。它回答的是「用户到底要什么」。
我写URD有个习惯：先写场景，再写功能，最后写约束。
举个例子，一个工业测温型红外探测器：
- 场景：化工厂管道巡检，工人每天走2万步，需要快速检测异常温升。
- 功能：非接触测温、超温报警、数据记录、蓝牙上传。
- 约束：防爆认证、单手操作、续航8小时以上、-20℃~60℃工作。
URD的模板我一般这样写：
# 用户需求文档（URD）
## 1. 用户画像
- 目标用户：化工厂巡检员
- 使用频率：每天8小时
- 技术背景：初中级操作水平
## 2. 核心场景
- 场景A：日常巡检（占比70%）
- 场景B：异常排查（占比20%）
- 场景C：数据上报（占比10%）
## 3. 功能需求
- F1：测温精度 ±1.5℃（必须）
- F2：报警响应 < 1秒（必须）
- F3：数据存储 1000条（期望）
- F4：APP连接（可选）
## 4. 非功能需求
- 重量 < 300g
- 防护等级 IP65
- 电池续航 ≥ 8小时
- 跌落高度 1.5m注意，URD里不要写技术实现。比如「用非制冷焦平面阵列」这种话，别写。那是TRD的事。
2.4 技术需求文档（TRD）撰写——把「需要」变成「指标」
TRD是给研发团队看的。它把URD里的每一条需求，翻译成可量化、可测试的技术指标。
这一步最容易出问题。我见过太多人直接把URD复制过来，加几个数字就当TRD了。不行！
举个例子，URD里写「测温精度 ±1.5℃」，TRD里要拆解成：
- 探测器NETD（噪声等效温差）≤ 50mK
- ADC采样精度 ≥ 14bit
- 温度校准算法误差 ≤ 0.5℃
- 环境温度补偿范围 -10℃~50℃
你看，一个简单的精度要求，背后涉及探测器、电路、算法、补偿四个子系统的指标。
TRD的典型结构：
# 技术需求文档（TRD）
## 1. 系统级指标
- 探测距离：100m（@人体目标）
- 视场角：50°×38°
- 帧率：25fps
## 2. 光学子系统
- 焦距：15mm
- F数：1.0
- 透过率：≥ 90%（8~14μm）
## 3. 探测器子系统
- 类型：非制冷氧化钒
- 像元尺寸：17μm
- NETD：≤ 50mK
- 响应率：≥ 10mV/K
## 4. 电路子系统
- 主控：STM32H743
- ADC：16bit，4通道
- 通信接口：UART、I2C、SPI
## 5. 算法子系统
- 非均匀校正：两点校正+场景校正
- 温度补偿：查表法+线性插值
- 报警逻辑：阈值可设，迟滞1℃
## 6. 验证标准
- 高低温测试：-20℃~60℃，4小时
- 跌落测试：1.5m，6面
- EMC：GB/T 17626.3关键提醒：TRD里的每一个指标，都要有对应的验证方法。如果写「探测距离100m」，就要写清楚「在25℃、相对湿度60%、目标温差5℃条件下，用黑体测试」。否则，研发和测试会打架。
2.5 从URD到TRD的映射——别让需求「失真」
这一步是需求分析里最容易被忽略的。URD是「人话」，TRD是「技术话」。翻译过程中，信息会丢失。
我举个例子。URD里用户说「我要轻便」，TRD里你写「重量≤300g」。但用户说的「轻便」可能还包括「手感好」「单手操作不累」。这些怎么量化？
我的做法是：建立需求追溯矩阵。
| URD编号 | URD描述 | TRD编号 | TRD指标 | 验证方法 |
|---|---|---|---|---|
| URD-F1 | 测温精度±1.5℃ | TRD-1.1 | NETD≤50mK | 黑体测试 |
| URD-F1 | 测温精度±1.5℃ | TRD-1.2 | ADC≥14bit | 信号源测试 |
| URD-NF1 | 重量≤300g | TRD-2.1 | 整机重量≤300g | 电子秤称重 |
| URD-NF2 | 续航≥8小时 | TRD-3.1 | 电池容量≥3000mAh | 充放电测试 |
这个矩阵的好处是：任何一个TRD指标变更，你都能立刻知道影响了哪些用户需求。有一次，我们的结构工程师说「为了防水，重量得加到320g」。我一看矩阵，发现影响的是URD-NF1。于是我们开会讨论，最终决定接受320g，但优化了握持手感来弥补。
我的经验：需求追溯矩阵最好用Excel或在线文档维护，每周更新一次。项目后期，你会发现它比任何文档都管用。
2.6 需求评审——别让一个人做决定
需求文档写完了，别急着发版。组织一次需求评审会，拉上产品、研发、测试、生产、采购的人一起过。
为什么？因为每个人看到的「需求」不一样。
- 产品说：这个功能必须有，不然卖不出去。
- 研发说：这个指标太难了，得加钱加时间。
- 测试说：这个验证条件不明确，我没法测。
- 采购说：这个芯片交期要16周，你们确定？
- 生产说：这个外壳公差±0.1mm，我们产线做不到。
你看，一个需求在落地过程中，会经历多少「变形」？评审就是把这些矛盾提前暴露出来，而不是等到流片了才发现。
我个人习惯在评审会上用「三色标记法」：
- 绿色：需求明确，团队达成一致。
- 黄色：需求有争议，需要进一步调研或实验。
- 红色：需求不可行，需要砍掉或大幅调整。
只有所有需求都变成绿色，才能进入下一阶段。
我曾经踩过的坑：有一次，我们为了赶进度，跳过需求评审直接开干。结果做到一半，采购说某个关键芯片停产了。我们不得不重新选型，整个方案推倒重来。那一次，项目延期了3个月。从那以后，我再也不敢跳过评审了。
2.7 本章小结
需求分析，说白了就是「想清楚再动手」。市场调研帮你找到方向，竞品分析帮你找到位置，URD帮你定义目标，TRD帮你拆解任务。
这四个步骤环环相扣，缺一不可。你想想看，如果市场调研没做透，你可能会做一个没人要的产品；如果竞品分析没做细，你可能会在红海里拼价格；如果URD没写清楚，研发可能会做出一个「能用但不好用」的东西；如果TRD没拆解到位，测试可能会跟你扯皮。
嗯，这一章的内容就到这里。记住，需求分析花的时间，会在项目后期十倍百倍地还给你。