问题：需求分析员缺乏应用域知识。应用域的知识是无边无际的，任何人都不可能是“万事通”。需求分析员可能是某一领域的专家，但一个企业要谋求发展，不能总在做老的业务，当他接手陌生的业务时，他可能是个“无知”者。

　　策略：要勇于实践，不要逃避。还应当赶紧补习应用域知识，不论是通过自学还是培训的方式。可能的话，最好请既懂软件又懂应用域知识的行家来帮忙。

　　2 态度

　　问题：很多开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会找一堆用户的毛病。很多开发人员错误地以为：

　　需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗?如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。

　　策略：用户说不清楚需求或者需求发生变更都是常见的问题，人们可以设法解决的。开发人员不应该把这些问题当成借口。需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。

　　3 合作关系

　　问题：需求分析员不能与用户建立良好的合作关系。对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你。搞需求开发。用户有他自己的想法：我回答了你们的问题，讲了该讲的。我们付钱给你们，你们自己想办法把工作做好……

　　策略：出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。对于重大的、复杂的项目，不能完全期望双方能够自发地建立起良好地合作关系。 开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。如果条件允许，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。

　　4 用户说不清楚需求

　　问题：用户说不清楚需求。有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。有些用户虽然心里明白想要什么，但却说不清楚需求。

　　策略：需求分析员不能以用户说不清楚需求为借口而草率地对待需求开发工作，无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。

　　5 双方误解需求

　　问题：人们在交流的时候，经常会发生“问非所求，答非所问”的事情。有时用户会把开发人员的建议或答复给想歪了，而用户表达的需求，不同的开发人员可能有不同的理解。

　　策略：如果需求分析员误解了需求，那会导致后续的不少开发人员将错就错、白干活。不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求，所以应当做好需求确认工作。

　　6 开发人员写不好需求文档

　　问题：需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。或者开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。

　　策略：要想写出好的需求文档，前提条件是把需求调查工作做好。提高开发人员写作能力，让他们多练习写文档。另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。

　　7 用户需求变更频繁

　　问题：在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。或者由于市场变化而导致产品需求发生变更。其实，

　　策略：做好需求变更控制。需求变更通常会对项目的进度、人力资源、经费产生很大的影响，但需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。