软件系统的建设工作，大多数是从需求收集工作开始，逐一开展建设。需求调研，既是软件系统建设的头等大事，也是难点。很多失项目，由于走入需求调研工作的误区，导致项目失败。因此，本文就需求调研的几个主要误区展开分析讨论，以求避免问题的发生。
误区一：需求调研计划不够切合实际
曾经给一个客户做一个业务审计系统，项目组就访谈的潜在对象列出了调研问题清单，计划列出了近期的调研工作安排，并且将很多不符合项目范围的内容也列入调研内容中，导致项目推进速度非常缓慢。
误区二：需求调研浅尝辄止
本来系统是面向整个公司的，而实际的调研工作却只深入到了一线部门。不凑巧的是，一线部门基本上是站在本位角度讲解他们自己的需求，而对于交叉需求如何处理，系统逻辑问题该如何解决，却没有哪个部门或者总监有权决断一下。脱离了上层的调研，绝大部分将会失败。
误区三：架空需求调研对象的想法
我们都知道，一个访谈对象，不仅能提出对项目的建设性意见和需求，还会夸夸其谈的展开想象，提出更多更加难以实现的想法。这本身不能责怪调研对象，因为他的职责是陈述他对系统的想法，而作为需求调研人员，你的做法是给出一个访谈脉络，引导访谈对象就主线展开联想，而不是一味的否定他的想法。
误区四：不断向客户抱怨需求多变，调研失控
需求调研是项目乙方与甲方、用户单位深入构建信任的阶段，在此阶段，不能及时收集到客户需求，不能就多变的需求展开需求管控，乙方则不能顺利的开展后续工作。一个典型的例子是，项目乙方将客户描述的问题简单化处理，导致每次开会时候，客户会就此问题开展讨论，补充这样那样的需求说明，导致需求没完没了，因此而抱怨增多，项目失控。
误区五：帮客户想需求
很多时候，对于项目将实现哪些功能、达到哪些目标，客户心里是没有底的。这时候，乙方就站出来帮甲方想需求，殊不知，这些需求一旦想出来后，甲方可能同意，可能不同意，也可能处于中立状态。同意的需求，也许后续有变化，乙方还得修正，还得推倒重来，不同意的需求，乙方的工作白忙活了。对于中立状态的需求，乙方显得束手无策。对于此类问题，我的建议是：一旦客户自己都想不出来需求，最好不要接这一单生意。
误区六：派出了技术骨干出身的项目经理还应对需求调研工作
技术骨干出身的项目经理往往困惑在客户为何要求不断，就算确定下来的需求也是一天一个样子，甚至有时候会直接说“先做吧，做完再改！”。无奈的项目经理最后只好统统归结——客户太难弄了，明明啥都不懂，一边把软件说的一文不值，一边提无数的无理要求。技术经理一般比较擅长做需求分析，熟悉各种需求分析手段，但是不擅长需求收集。同时，他不清楚如何将客户零散的需求系统地整理在一起，只是简单的记录下客户需求，有时候可能还会有遗漏，或者对客户需求前后不一致的地方不够敏感，又或者对可能影响整体业务逻辑思路的关键需求重视不够。还有，他不注重需求调研的阶段性，不注重同客户的阶段性确认。
需求调研工作还有很多其他的误区。对于这项工作，项目组应该合理制定出调研计划，让这项工作变得足够有意义。