需求获取是什么
需求获取是把干系人脑子里的期望、约束与隐性规则挖出来的过程，常用技术包括访谈、引导式工作坊、现场观察、问卷、文档分析与原型演示。不同技术适合获取不同类型的信息：访谈适合深挖动机与背景，观察适合发现真实流程与例外处理，原型适合验证界面与交互理解。组合使用并交叉验证，可以显著降低遗漏与误解。
常用技术
| 技术 | 适用场景 | 注意点 |
|---|---|---|
| 访谈 | 深入了解角色痛点与决策背景 | 区分表面诉求与真实目标，避免引导性提问 |
| 工作坊 | 跨角色对齐流程与业务规则 | 控制范围，现场记录冲突点与待办事项 |
| 现场观察 | 隐性流程、例外处理与工作习惯 | 被观察者会改变行为，需要多次跟岗 |
| 问卷 | 面向大量同类用户收集偏好 | 问题设计不当会放大既有假设 |
| 文档分析 | 梳理既有规则、报表与制度约束 | 历史文档可能已过期，需与业务确认 |
| 原型演示 | 验证界面与交互类需求理解 | 明确是探索原型而非交付承诺 |
典型使用场景
- 新系统立项：访谈关键角色，明确目标与成功判定标准
- 流程改造：现场观察实际做法，找到与制度不符的真实处理方式
- 存量系统接手：分析既有文档与代码，梳理真实业务规则
- 多方诉求冲突：用工作坊当场对冲突点做裁决并记录结论
- 面向大量终端用户：先用问卷定位范围，再对典型用户深访
- 交互方案确认：用低保真原型验证理解，尽早暴露偏差
基本信息
| 输出物 | 需求清单、术语表、流程说明、冲突点与待确认问题列表 |
|---|---|
| 确认机制 | 获取结果需回读确认，关键歧义当面澄清并留下书面记录 |
| 覆盖范围 | 覆盖一线操作者、管理者、运维、安全与合规角色 |
| 常见依据 | IIBA 的 BABOK 指南与 Wiegers 的需求工程实践 |
获取阶段的成本远低于返工成本：一次半天的现场观察，往往能发现文档里完全没有写、但每天都发生的例外处理。
只访谈需求提出人而忽略一线操作者与实际数据，容易得到理想化流程，上线后与真实业务冲突。