12、需求工程-需求获取

需求获取 (Requirements Elicitation)

需求获取是整个需求工程中最具挑战性也最关键的一步。它的核心目标是从各种来源（特别是利益相关者）中发掘、理解并捕获需求信息。如果这一步做得不好，后续的所有工作都将建立在不稳固的基础之上。

---

🧲 需求获取的核心挑战

架构师和分析师在需求获取时常常面临以下挑战：

• 范围问题： 利益相关者可能无法清晰地界定系统边界，导致需求范围蔓延。
• 理解问题： 利益相关者可能不完全了解他们真正需要什么，或者无法清晰地表达他们的需求。开发者也可能误解业务领域的术语和流程。
• 波动问题： 随着项目的进行，利益相关者的需求可能会发生变化。

---

🛠️ 常用的需求获取技术

为了系统地获取需求，架构师可以使用多种技术。通常，最佳实践是组合使用这些方法，以从不同角度验证和补充需求。

方法 (Method)	描述 (Description)	优点 (Advantages)	缺点 (Disadvantages)
访谈 (Interviews)	与单个或小规模的利益相关者进行直接对话，可以是结构化的（预设问题）或非结构化的（开放式讨论）。	- 能深入挖掘细节和复杂问题。- 灵活性高，可随时追问。- 能建立良好的人际关系。	- 非常耗时。- 访谈者的技巧对结果影响很大。- 容易引入个人偏见。
问卷调查 (Surveys)	向大量的利益相关者分发一系列书面问题，以收集广泛的意见和数据。	- 面对大量用户时效率很高。- 易于量化分析。- 匿名性可以鼓励坦诚的回答。	- 难以设计出无歧义的好问题。- 无法进行追问和澄清。- 回收率可能很低。
现场观察 (Observation)	前往用户的工作环境，直接观察他们如何执行任务、使用现有系统以及遇到的困难。	- 能发现用户自己都未意识到的“隐性需求”。- 提供真实的业务流程和环境背景。- 减少对用户口头描述的依赖。	- 用户被观察时可能会改变行为（霍桑效应）。- 观察到的现象需要正确解读。- 耗时且可能对用户造成干扰。
专题讨论会 (Workshops)	组织一个由关键利益相关者（用户、客户、开发者）组成的集中会议，通过头脑风暴、讨论和协作来共同定义和提炼需求。	- 能快速解决冲突，达成共识。- 促进团队协作和沟通。- 可以在短时间内产出大量需求。	- 组织成本高。- 强依赖于主持人的引导能力。- 可能被少数声音主导。
原型法 (Prototyping)	创建一个系统的早期、可交互的模型（如UI界面模型、线框图），让用户试用并提供反馈。	- 将抽象的需求具体化，非常直观。- 能在开发早期就发现设计缺陷。- 极大提升用户参与感和满意度。	- 用户可能误将原型视为最终产品。- 如果原型过于简陋，可能无法获得有效反馈。- 有投入成本。
文档分析 (Document Analysis)	研究与项目相关的现有文档，例如业务计划、市场分析报告、现有的系统规格说明书、用户手册等。	- 是了解现有系统和业务规则的良好起点。- 成本较低，不打扰用户。- 可发现书面化的正式需求。	- 文档可能已经过时或不准确。- 文档描述的可能是“理想流程”而非“实际流程”。- 无法揭示新的或未被满足的需求。

---

💡 总结

需求获取不是一次性的活动，而是一个迭代的过程。一个成功的架构师会像侦探一样，综合运用多种方法，从不同角度拼凑出完整的需求图景。

在完成了初步的需求获取之后，下一步就是对这些纷繁复杂的信息进行梳理和提炼，也就是我们即将讨论的 需求分析。