需求工程基础：需求工程的定义、生命周期与AI项目中的重要性

各位同学，咱们直接切入正题。需求工程，说白了，就是一套系统化的方法，用来搞清楚“我们到底要造什么”，并且确保所有人——产品、开发、测试、业务方——对这件事的理解完全一致。

我见过太多AI项目，算法团队闷头调了三个月参数，最后发现业务方要的根本不是这个。所以，需求工程不是写文档的苦差事，它是项目的“防跑偏护栏”。

官方定义我就不念了。用我的话讲：需求工程是“从模糊到精确”的翻译过程。它把业务方的痛点、想法、甚至抱怨，翻译成技术团队能执行的、可验证的规格说明。

举个例子。我参与过一个智能客服项目，业务方说“让机器人更聪明”。这算需求吗？不算。经过需求工程后，我们把它翻译成：“在用户提问后3秒内，从知识库中检索出Top-3答案，准确率不低于85%”。你看，这才是可落地的需求。

这里有个关键点：需求工程包含“开发”和“管理”两个维度。开发是挖掘、分析、定义；管理是跟踪、变更、维护。缺一不可。

我习惯把生命周期分成五个阶段，每个阶段都有血泪教训：

阶段	核心活动	我的个人经验
1. 需求获取	访谈、问卷、观察、原型演示	别只问业务方“你要什么”，要问“你现在怎么做的”。有一次我蹲在仓库看拣货员操作了三天，才发现他们真正需要的是语音指令，不是扫码枪。
2. 需求分析	建模、优先级排序、冲突消解	AI项目里，数据需求往往被忽略。分析时一定要问：这个模型需要多少标注数据？数据分布长什么样？我见过一个项目，需求分析时没考虑数据偏差，上线后模型对少数群体识别率只有30%。
3. 需求规格说明	编写SRS（软件需求规格说明书）	别写“系统应能识别用户情绪”。要写“系统对正面/负面/中性情绪的识别准确率分别不低于80%/75%/70%”。量化，量化，再量化。
4. 需求验证	评审、原型确认、验收测试	我吃过最大的亏，就是没让业务方在需求文档上签字。后来一个项目，对方说“这不是我要的”，但文档里白纸黑字写着，省了扯皮。验证环节其实是保护自己。
5. 需求管理	变更控制、版本管理、追溯	AI项目需求变更特别频繁——数据变了、模型效果不达标、业务策略调整。我建议用Jira或类似工具，每条需求都关联到具体的模型版本和数据集版本。

其实这五个阶段不是线性的。我经常在“分析”阶段发现新问题，又回头去“获取”。迭代是常态，别怕。

为什么单独拎出来说？因为AI项目有三个“坑”，需求工程是唯一的填坑工具：

坑一：效果不确定性。传统软件需求是“做或不做”，AI需求是“做到什么程度”。没有精确的需求定义，你没法判断模型是“合格”还是“失败”。
坑二：数据依赖。AI系统的行为由数据驱动。需求工程必须定义数据质量、数据分布、标注标准。我有个项目，因为没定义“异常数据”的过滤规则，模型上线后把正常交易也拦截了，损失惨重。
坑三：利益相关者复杂。AI项目往往涉及业务方、数据工程师、算法工程师、运维、甚至法务。需求工程是统一语言的桥梁。说白了，没有它，大家各说各话，项目必死。

最后说一句掏心窝的话：在AI项目里，需求工程不是“写文档”，而是“做决策”。你定义了什么，团队就朝什么方向努力。定义错了，后面所有工作都是白费。我见过太多团队，把80%的时间花在调模型上，只花20%在需求上。结果呢？模型调得再好，也不是人家要的。

所以，请把需求工程当作AI项目的“第一优先级”。它不性感，但能救命。