1、客户不满意，不能一直让客户牵着鼻子走，我们需要去深入理解客户的需求，将自己的理解给客户，达到客户的认同。
2、不能客户说怎么做就怎么做，客户没有这方面的知识，需要提前分析客户的功能，用计算机能用的方法就觉。
3、需求调研之前需要进行角色分析，需要对每个角色都进行调研。划分清楚角色，弄清楚每个角色的需求提出者与决策者，就是为了在今后的需求调研中找对正确的人，使今后的调研工作事半功倍。
4、在开发过程中需要时刻将程序的进行与客户交流，在开发过程中发现问题，及时解决，避免到最后的赶时间，出现更多的问题。
【拜访】
5、与客户相处好关系，经过一番交往，我们将逐渐在客户中结识一批可以帮助我们的人。今后一段日子里，我们将依靠他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。
【研讨会】
6、业务商讨，可以划分为几个部分或找到相关的部分将他们集中到一起，集中进行调研，每个部门都划分开，以保证不会杂乱无章。
【需求研讨】
7、自己做的软件与客户期待的软件不是一种东西，客户前期调研是提不出需求，最后做出软件客户使用时，感觉不是这个软件。这就需要在调研过程中不要先于客户讨论软件的功能，先了解客户的知识领域，将自己带入到特定的软甲使用环境中，客户现有的业务流程是什么样的，都有些什么操作？客户在业务中都有些什么事物，什么专用名词，都是怎样定义的，相互之间的关系是什么？客户在每一项操作中的目的是什么，为什么要这样做，他们制作的手工报表都说明了什么问题？在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。他们为什么要提出这项需求，提这项需求的目的是什么？
【迭代】
8、需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。为什么这样说呢？让我们一起来分析分析。
在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••
需求捕获：在调研过程中需要记录着客户的每一个关键词，并且要有与客户回应，需要明白以写名词的含义。做出适当的记录绘制简单的草图，记录过程。
需求整理：在与客户讨论后，回到公司需要立刻开会，集体讨论客户的要求，再集体考虑客户的语录，参考记录，草图，总结客户的需求。最后，当我们完成了一系列的分析整理并形成文档以后，应当对及时地与客户进行反馈，确认我们的理解是否正确，也就是需求验证工作。需求验证工作应当贯穿整个研发周期，并且在不同时期表现出不同的形式。
【需求捕获】
9、在软件需求捕获过程中，最根本、最容易犯错的问题是什么呢？我认为是一个态度的问题，是采用主动态度去捕获需求，还是采用被动的态度去捕获需求。如果需求分析人员总是诺诺诺，客户说什么，我们就记什么。客户处于非常强势的地位，给我们提出了非常多变态、技术难于实现的需求，而我们的需求分析人员却成为记录员，埋头记录客户说的每一句话，不加分析地就直接扔给了开发人员。这就是采用被动的态度去捕获业务需求的方式。毫无疑问，这样的需求分析必然将给项目开发的后期带来巨大的风险。
客户说的需求只是软件的一点，需要我们调研开发去追问具体需求，自己去挖掘，然后将自己想到的软件说给客户，看客户是否满意。
【功能角色分析与用例图】
10、我们绘制的用例图拿给客户看不懂。这样一个清晰明了的用例图，辅之以我们对图形的描述，客户怎么会看不懂呢？关键问题在于，我们没有将用例图的精髓弄明白，再加上出现一些常见问题，使得用例图画得不伦不类，客户当然就看不明白了。现在我们看看用例绘制都有些什么常见问题。
- 没有正确理解用例图的视角。
- 图形绘制杂乱无章。
- 用例是一个场景。
【流程分析】
11、首先，我们应当抛开软件实现，对这样一个流程进行梳理，形成这样一个步骤：
1. 高层领导通过信访、举报、数据查询分析等方式发现一批问题；
2. 将这批问题制作成一个调查清册；
3. 自查或将清册下派给下级去调查；
4. 下到基层执行调查；
12、5. 从基层回到自己的单位，填写调查工作底稿，详细描述调查情况，并结束调查工作。
然后，在对原始需求分析的基础上，分析我们的软件能做什么事：
第一步：信访和举报虽然有自己的操作流程，但那些都在这个系统之外，在这个系统中仅仅只需录入最后的结果。数据查询分析过去只是业务人员在相关业务系统中根据自己的经验执行各种查询，现在则可以上一套数据采集和分析系统，提高数据分析的质量。
第二步：形成调查清册，可以在系统中设计一个功能实现。
第三步：自查或下派，可以在系统中设计一个流程实现。
第四步：下到基层执行调查，由于网络条件等因素的限制，业务人员不可能也不必要在系统中去完成调查，只需要执行一个标志调查工作开始的操作，并打印或导出调查清册，然后去基层调查。最终，这部分被设计成一个“开始实地核查”的操作，并提供打印导出功能。
第五步：调查人员从基层回到自己的单位都是系统外的事情，而填写调查工作底稿，详细描述调查情况，并结束调查工作，则是系统内的功能。最终，这部分被设计成一个“调查完结”功能，标志调查工作结束，并提供工作底稿的填写功能。
【用例说明】
【业务领域分析】
13、业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。前面我们谈到了功能角色分析，或者说用例分析，它是从整体的角度对整个系统人机交互的分析与整理。随后我们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。我们进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。日后我们去设计开发系统时，应当设计哪些类，类中都应当有什么属性和行为，以及怎样去设计数据库，都是以这个领域模型为基础的，虽然有时并不完全与领域模型完全一致。过去，没有一个切实可行的方法来指导我们的业务领域分析，而现在，我们可以通过两种分析方法一步步进行：原文分析法与领域驱动设计。随后，我们将就这两种方式进行详细分析。
【原文分析法】
【领域驱动设计】
【非功能需求】
【一个需求列表的实例】
【快速原型法】
【需求规格说明书】
【评审与签字确认会】
