从范围管理到需求开发，我们已经搭建了项目的骨架。现在，我们需要通过"需求获取（Elicitation）"和"用例（Use Cases）"来为项目填充血肉，把抽象的需求真正落地。
🗣️ 常见的需求获取技巧
没有哪一种技巧是万能的，通常需要组合使用。我们可以把它们分为三大类：
1. 一对一获取 (One-on-one)
- 访谈 (Interviews)：提前准备好问题并发送给干系人。开场可以用轻松的寒暄（如聊聊天上的照片）来破冰，这招对亲和型（I/S型）性格的人很管用。
- 观察 (Observation/Job Shadowing)：站在用户旁边看他们实际工作。很多时候，用户做的和他们说的并不一样，观察能发现这些隐藏信息。
- 问卷 (Surveys)：适合收集大量信息。设计时要小心，避免引导性提问，尽量给受访者表达真实想法的机会。
2. 群体获取 (Group-focused)
- 头脑风暴 (Brainstorming)：激发跳出框架的创新思维。难点在于当大家意见不一时，如何引导达成共识。
- 焦点小组 (Focus Groups)：针对特定、狭窄的领域，邀请关键领域专家（SME）进行深入对话。
- 需求研讨会 (Requirements Workshops)：形式灵活，可以是非正式的讨论，也可以是正式的敏捷时间盒会议。
3. 特殊技巧 (Special Techniques)
- 包括文档分析、接口分析，以及逆向工程 (Reverse Engineering)（通过研究现有系统来推导需求）。
💡 核心提示 ：需求获取永远不可能一步到位，必须迭代进行。你可以先通过原型（如纸面原型、线框图）获取初步反馈，再逐步完善。
📝 使用用例 (Use Cases) 记录需求
用例是描述"系统必须做什么"的绝佳工具，它聚焦于行为，能很好地填补"用户需求"与"系统功能"之间的鸿沟。
- 核心概念 ：
- 参与者 (Actor)：与系统交互以获取价值的用户角色或外部实体。
- 用例 (Use Case)：参与者为实现某个目标而与系统进行的一系列交互步骤。
- ATM 取款实例 ：
从客户插卡、选语言、输密码，到选择"取款"、输入金额、系统吐钞，最后退卡打印凭条。这一连串的交互就是一个完整的用例。 - 渐进明细 (Progressive Elaboration) ：
用例不需要一开始就写得很完美。- 第一轮：识别参与者，确定目标，写个简短描述，起个名字（如"从ATM取款"）。
- 后续迭代：把简短描述扩充为详细的步骤（主流程），再补充异常流程（替代流程），最后加上前置条件、后置条件等，形成"完全展开的用例"。
⚖️ 平衡干系人需求
在实际项目中，你很少只面对一个需求来源。通常会有很多人声称他们的需求是"必须立刻实现的"。这时就需要平衡干系人需求。
- 设立接口人：理想情况下，应该有一个像敏捷中"产品负责人（Product Owner）"那样的角色作为需求的统一出口。如果没有，项目分析师（Project Analyst）通常是最佳人选。
- 优先级与冲突解决 ：平衡需求的核心在于优先级排序 。当需求发生冲突时，项目经理需要依据清晰的项目目标来进行权衡和裁决。