从需求方、需求获取方、业务本身三个方面阐述。
需求方（客户方）：
产生的问题：
- 描述不完整：描述的时候只考虑到正常情况下的需求，对一些自认为是常识的需求忽略不提
解决办法：需求获取方能够适当的引导和挖掘 - 用语不准确，可能内心清楚但是表达能力欠缺
解决办法：尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时做出的决策过程，并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。 - 知识能力有限：隔行如隔山，知识局限，导致提出的需求不完整、不统一
解决办法：尝试多问客户一些问题，更好的获取需求。 - 用户参与不足：实际用户太多，无法有效选择客户；用户不配合需求获取；没有明确用户
解决办法：需求获取方应对用户进行有效的选择，展开需求获取，或者尝试多种获取方法获取需求。
需求获取方：
产生的问题：
- 专业能力强弱：需求获取方要了解需求获取的多种方法（如面谈、问卷调查、原型法、模拟情境观察、文档审查等）
解决办法：配备专业能力强的人组成需求获取方，或团队中至少有一名比较有经验的软件需求工程师 - 理解客户方需求困难
解决办法：尽量把客户所持有的假设等解释清楚，特别是那些发生冲突的部分 - 总是站在技术角度，无法理解客户的业务需求
解决办法：需求获取方了解软件实现技术，但软件的前提是满足客户需要，而不是复兴局限于技术。技术服从需求，应尽力解决客户提出来的需求 - 需求获取时的有效需求提炼
解决办法：在需求获取过程中分析模型，屏幕图形和原型可以使概念表达更加清晰，然后提供一个寻找错误和遗漏的办法 - 对用户的有效选择
解决办法：需求获取时，讨论会的团队人数控制5到7人最好 - 需求获取时工具携带、人员安排不足，不能及时获取和处理需求
- 对项目范围的定义过小或过大
- 需求收集不可能全面
业务本身：
- 实际的业务比想象中的要复杂
