需求获取（Requirements Elicitation）也称为需求收集（Requirements Capture），它是与发现目标系统应该提供的需求相关的活动的统称。
需求开发小组的一个或多个成员与顾客组织之间的交流通常是需求获取的重要前提。为了获取客户的需求，需求小组成员必须熟悉应用领域，并使用正确的术语同客户交谈。消除术语误解问题的一个办法是建立并随时更新术语表。在需求获取时，经常使用访谈、场景（Scenario，也称情景，在面向对象分析中也叫用例）以及其他一些技术（例如，向客户组织成员发放调查表，检查客户工作使用的各种表格）。
Christel和Kang指出，以下问题导致了需求的获取非常困难：
（1）范围问题。开发时经常还未定义好系统边界，或者客户/用户刻画的技术细节不清晰、不必要，系统目标的描述不简明、不全面。
（2）理解问题。客户/用户不能完全确定需要什么，不能完全理解问题领域，与系统工程师在需求沟通上存在歧义，甚至提出一些同其他客户/用户的需要相冲突的需求以及一些不可测试的需求。
（3）易变问题。需求随事件发生变化。
为了克服这些问题，系统工程师必须有组织地收集需求。Sommerville和Sawyer建议采用如下步骤来指导需求的获取：
（1）针对提议的系统评估业务及技术可行性，给出需要和可行性的陈述。
（2）确定那些能够帮助刻画需求和熟悉组织及相关业务的人员，给出参与需求获取活动的客户、用户和其他风险承担者的列表。(www.xing528.com)
（3）定义系统或产品的技术环境（如计算体系结构、操作系统），给出系统的技术环境的描述。
（4）确定“领域约束”（即目标应用领域的业务环境的特征），这些约束将限制待建造系统/产品的功能或性能。需给出系统/产品范围的限制性陈述，以及需求列表和应用于每个需求的领域限制。
（5）定义一种或多种需求获取方法。
（6）要求很多人员参与，以便能从不同视角来定义需求，并确定每个正式需求的理由。
（7）确定有歧义的需求为原型实现的候选对象。
（8）创建并给出使用场景，以帮助客户/用户更好地确定关键需求，提供对在不同运行条件下系统或产品的使用指导意见。
最后，还需要给出原型以更好地定义需求。以上每一个工作产品都要参与需求获取活动的所有人员评审确认。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
