第2章需求工程基础

2、需求工程基础：五大过程深度解析

好，咱们进入正题。需求工程，说白了就是把用户脑子里的「想法」变成开发团队能执行的「蓝图」。这活儿看着简单，做起来坑特别多。我个人习惯把这五大过程当成一条流水线——每个环节漏掉一点东西，最后出来的产品就可能跑偏。

这五大过程分别是：需求获取、需求分析、需求规格、需求验证、需求管理。咱们一个一个拆开聊。

需求获取是第一步，也是最容易出问题的一步。你想想看，用户说「我想要一个快的系统」，他心里的「快」可能是点击后0.5秒响应，而你理解的「快」可能是3秒以内。这不就出岔子了吗？

我在项目中遇到过一位客户，反复强调系统要「智能」。我追问了三次，他才说清楚——原来他想要的只是根据历史数据自动填充表单。嗯，这就是典型的「模糊需求」。

  核心要点：
  用户访谈：别只问「你想要什么」，多问「你现在的痛点是什么」
问卷调查：适合收集大量用户的共性需求，但问题设计要具体
原型演示：拿个低保真原型给用户看，比说一百句话都管用
观察法：去用户工作现场看看，你会发现很多他们自己都没意识到的需求

我的小技巧：每次访谈结束后，我会花10分钟把听到的内容复述一遍给用户听。比如「您刚才说的是不是这个意思...」——这能避免很多误解。

获取到的需求往往是杂乱的、矛盾的。需求分析就是做「提纯」工作。我个人习惯把需求分成三类：业务需求、用户需求、功能需求。

举个例子：用户说「我要能导出报表」——这是用户需求。分析后你会发现，他真正的业务需求是「每周一早上9点自动生成上周的销售数据报表并发送给管理层」。你看，差别很大吧？

避坑指南：我曾经接手过一个项目，需求文档里写了「系统要支持多语言」。结果分析阶段没深挖，开发到一半才发现——客户要的不是界面翻译，而是数据内容的多语言存储。这一下子架构都要改。所以，分析阶段一定要追问「为什么」。

这是咱们这门课的核心。需求规格就是把分析后的结果写成文档，让所有人都能看懂、看明白、没有歧义。

怎么写？记住一个原则：可验证。每条需求都要能明确判断「做完了」还是「没做完」。

举个例子：

❌ 错误写法：
系统应具有良好的响应速度。

✅ 正确写法：
在标准网络环境下（带宽≥100Mbps），用户点击查询按钮后，
系统应在2秒内显示查询结果，95%的请求应在1秒内完成。

你看，后者明确给出了指标，测试人员拿到就能写测试用例。前者呢？什么叫「良好」？每个人理解都不一样。

  需求规格的黄金法则：
  唯一性：每条需求有唯一编号，方便追溯
完整性：一条需求说清楚一件事，别混在一起
一致性：需求之间不能互相矛盾
可测试性：能写测试用例的需求才是好需求

需求验证是很多人容易忽略的一步。说白了，就是让干系人（客户、用户、开发、测试）一起确认：「这需求文档写的，是不是你们要的？」

我建议用评审会的形式来做。会上别光念文档，要带着大家走场景。比如：

这些问题一抛出来，很多隐藏的问题就浮出水面了。

我的经验：验证阶段最好让测试人员也参与。他们最擅长找「漏洞」——需求里没写清楚的地方，测试人员一眼就能看出来。我曾经在一次评审会上，测试人员问了三个问题，结果发现需求文档里有五处逻辑矛盾。

需求管理，说白了就是应对「变化」。项目做到一半，客户说「我要加个功能」，怎么办？不加？客户不满意。加？项目延期谁负责？

所以，需求管理要建立一套变更控制流程：

避坑指南：我曾经见过一个项目，需求变更全靠口头沟通。开发人员改完了，测试不知道，测试用例还是按老需求写的。结果上线前才发现功能对不上，加班加点返工。所以，任何变更必须走文档，这是底线。

这五大过程不是串行的，而是迭代的。你获取需求的时候可能就在做分析，写规格的时候可能发现需要再获取一些信息。嗯，这很正常。

我个人习惯在每个迭代结束时，花半天时间做一次「需求回溯」——看看这轮有没有遗漏的需求？有没有理解偏差？有没有变更没记录？这能帮团队持续改进。

记住一句话：需求工程做得好，项目就成功了一半。另一半嘛，靠的是靠谱的开发团队和良好的项目管理。但那是另一门课的内容了。