2. 项目需求分析：从客户需求中提取技术指标

做机器视觉项目这么多年，我最大的体会就是：需求分析做不好，后面全是坑。很多工程师一上来就急着选相机、挑镜头，结果做到一半发现客户要的根本不是那回事。嗯，今天我们就聊聊怎么把客户嘴里说的「我要一个检测系统」变成实实在在的技术指标。

2.1 从模糊需求到技术指标

客户通常会说：「我要检测这个零件有没有划伤。」

你一听，觉得简单。但实际呢？划伤多长算划伤？多深算划伤？在什么光照条件下看？检测速度要多快？

我个人习惯，拿到客户需求后先做三件事：

1. 把「定性」变成「定量」——「划伤」变成「长度≥0.5mm，深度≥0.1mm」
2. 把「目标」变成「约束」——「检测速度快」变成「单次检测≤200ms」
3. 把「理想」变成「边界」——「所有缺陷都能检」变成「漏检率≤0.1%，过杀率≤1%」

举个例子。我之前遇到一个客户，说要检测手机屏幕的「轻微划痕」。我追问了一句：「轻微到什么程度？」客户说：「就是人眼在自然光下能看到的。」好，那我们就按人眼分辨率来算——大约0.1mm宽度的划痕。再结合屏幕尺寸、检测节拍，最后定下来的指标是：分辨率0.05mm/pixel，检测节拍3秒/片，光源用同轴光。

你看，一个模糊的需求，就这么一步步拆解成了可执行的技术参数。

2.2 需求文档的编写规范

很多团队不重视需求文档，觉得「口头说好了就行」。我曾经吃过这个亏——项目做了两个月，客户说「我要的不是这个」，结果因为没有书面记录，只能自己扛成本。

所以我现在要求：所有需求必须落到文档里，双方签字确认。

一份好的需求文档，应该包含以下内容：

模块	内容	示例
项目概述	项目背景、目标、范围	本系统用于检测A型号轴承端面缺陷
功能需求	检测项、判定标准、输出方式	检测划伤、压痕、锈斑，输出OK/NG信号
性能指标	精度、速度、稳定性	检测精度0.1mm，节拍2秒/件，MTBF≥5000h
环境要求	温度、湿度、振动、光照	工作温度0~45℃，湿度≤85%
接口定义	硬件接口、软件接口、通讯协议	触发信号24V，数据输出TCP/IP
验收标准	测试方法、通过条件	用标准缺陷样件测试，漏检率≤0.1%

另外，我建议在文档里加一个「假设与约束」章节。比如：「假设客户提供标准样件」「假设现场供电稳定」。这些看似废话，但真出了问题，这就是你的护身符。

2.3 需求变更对成本的影响

说到这个，我就想起一个惨痛教训。有个项目做到一半，客户说：「能不能再加一个检测项？」我想着不就是多写几行代码嘛，就答应了。结果呢？

• 相机视野不够，要换更高分辨率的相机——硬件成本+5000元
• 算法要重新训练，标注数据要重新做——人力成本+2人周
• 测试时间延长，项目延期——管理成本+违约金

最后算下来，一个「小需求」多花了将近3万块。从那以后，我定了一条铁律：需求变更必须走变更流程，重新评估成本和时间。

需求变更对成本的影响，可以用下面这张图来理解：

这张图想说明什么？说白了就是：需求变更越晚，成本越高。在需求分析阶段改个参数，可能就改一行字。到了开发阶段再改，要改代码、改硬件、改测试用例。到了交付阶段？那基本等于重做。

2.4 需求变更的成本量化模型

为了让大家更直观地理解，我整理了一个简单的成本量化模型：

变更阶段	成本系数	典型影响
需求分析阶段	1x	修改文档，重新确认
方案设计阶段	3~5x	重新选型，修改方案
开发实施阶段	10~20x	改代码、改硬件、重新测试
测试验收阶段	30~50x	几乎等于重做，还要赔违约金

你看，在需求分析阶段改一个东西，成本是1。到了测试阶段再改，成本就是30到50倍。所以我的建议是：前期多花时间把需求搞清楚，比后期改来改去划算得多。

2.5 总结

需求分析这件事，说白了就是把客户脑子里的画面，变成你纸上的数字。做得好，项目就成功了一半。做得不好，后面全是补不完的窟窿。

记住三句话：

• 需求要量化——别用「快」「好」「准」，用「200ms」「0.1mm」「99.9%」
• 文档要规范——白纸黑字，双方签字，这是你的护身符
• 变更要收费——别不好意思，这是对双方负责

好了，这一章就聊到这里。下一章我们聊聊方案设计阶段怎么控制成本——嗯，到时候见。

---