4、需求获取技术：利益相关者分析、访谈与问卷、原型法、场景与用例、文档分析

各位同学，今天我们聊聊需求获取。这活儿看着简单，其实门道很深。我见过太多项目，需求没搞清楚就开干，最后返工的成本比重新写一遍还高。说白了，需求获取就是跟人打交道、跟文档打交道、跟原型打交道的过程。咱们一个一个说。

4.1 利益相关者分析：先搞清楚谁说了算

做航天软件，利益相关者可不是一个人。你想想看，一个卫星项目，用户是总体所，但真正操作的是地面站，维护的是后勤部门，掏钱的是甲方领导。这些人诉求完全不一样。

我个人的习惯是，第一步先画一张利益相关者地图。把所有人都列出来，然后标出他们的影响力、关注点、以及冲突点。

我在项目中遇到过一件事：某型号的遥测参数定义，用户觉得够了，但维护人员觉得少了。两边吵了三天。后来我拉了个会，让维护人员把历史故障案例摆出来，用户一看，确实缺参数。你看，利益相关者分析做不好，后面全是坑。

4.2 访谈与问卷：问对问题比答案更重要

访谈是获取需求最直接的方式。但很多人不会访谈。我见过有人拿着问题清单，一条一条念，跟审犯人似的。这不行。

访谈的技巧：

• 先聊背景，建立信任。别上来就问技术细节。
• 多用开放式问题。比如「您觉得这个流程哪里最麻烦？」而不是「这个流程需要优化吗？」
• 学会追问。对方说「这个功能很重要」，你要追问「重要在哪？什么场景下会用到？」
• 记录要快，但别只顾着记。眼神交流很重要。

问卷呢，适合大规模收集意见。但航天项目里，问卷用得不多，因为涉密。我一般只在内部团队用问卷，比如收集大家对某个接口设计的看法。

4.3 原型法：做出来看看，比说一万句都强

原型法，说白了就是「先做个样子出来看看」。航天软件里，原型特别适合做界面原型和操作流程验证。

我记得有一次做地面站监控软件。用户说「我要一个直观的界面」。我问什么叫直观？他说「就是一看就懂」。这没法写需求文档。于是我花了两天，用原型工具画了一个界面，把卫星轨道、遥测参数、告警信息都摆上去。用户一看，说「不对，告警应该放在右上角，轨道图要能缩放」。你看，原型一出来，需求就具体了。

原型法的好处：

• 降低沟通成本。一张图胜过千言万语。
• 早期发现误解。用户说「我要A」，你理解成「B」，原型一出来就露馅了。
• 快速迭代。改原型比改代码快多了。

但要注意，原型不是最终产品。我见过有人把原型做得特别精致，用户以为快做完了，结果原型只是画了个皮。嗯，这里要跟用户讲清楚：原型是用来确认需求的，不是交付物。

4.4 场景与用例：把需求讲成故事

场景和用例，是需求获取的「故事板」。你想想看，用户不会说「我需要一个状态机」，他会说「卫星飞到南大西洋上空时，我要能切换成应急模式」。这就是场景。

场景描述：

• 谁（角色）
• 在什么条件下（前置条件）
• 做了什么操作（触发事件）
• 系统怎么响应（系统行为）
• 结果是什么（后置条件）

用例呢，更结构化一些。我习惯用UML的用例图，把角色和功能的关系画出来。但说实话，航天项目里，用例图用得不多，因为太抽象。大家更喜欢看场景描述，因为贴近真实操作。

我曾经帮一个团队梳理需求。他们写了200页文档，全是功能列表。我让他们把每个功能对应一个场景，结果发现有一半的功能根本没人用。为什么？因为那些功能是「我觉得用户需要」的，不是用户真正需要的。

4.5 文档分析：从旧文档里挖金子

别小看文档分析。航天项目有大量的历史文档：上一型号的需求文档、接口控制文档、测试报告、故障归零报告……这些都是金矿。

文档分析能做什么：

• 发现历史问题。比如某个接口以前出过问题，新项目就要特别注意。
• 复用已有设计。别什么都从头造轮子。
• 验证需求一致性。新需求跟旧文档有没有冲突？

我个人的习惯是，拿到一份旧文档，先看「变更记录」和「遗留问题」。这两个地方信息量最大。变更记录告诉你哪些地方踩过坑，遗留问题告诉你哪些坑还没填。

但要注意，文档分析不能替代跟人沟通。文档是死的，人是活的。我见过有人拿着五年前的文档当圣经，结果发现系统架构早就变了。文档只能作为参考，最终需求还是要跟利益相关者确认。

4.6 五种技术的组合使用

这五种技术不是孤立的。我一般这样组合：

阶段	技术	目的
项目启动	利益相关者分析	搞清楚谁说了算，谁有需求
需求探索	访谈 + 文档分析	收集初步需求，了解历史
需求细化	原型法 + 场景用例	把模糊需求变成具体描述
需求验证	问卷 + 原型评审	确认需求理解一致

你想想看，如果一上来就做原型，连利益相关者都没搞清楚，做出来的原型给谁看？如果只做访谈，没有文档分析，很多历史问题会重复出现。所以，这五种技术要搭配着用。

好了，这一章就讲到这里。下一章我们聊聊需求建模，怎么把获取到的需求变成结构化的模型。到时候我会带一个实际案例，你们会看到这些技术是怎么落地的。