在研讨会上进行需求研讨。我在进行需求研讨的时候，首先跟客户探讨的不是软件功能，而是客户现有的业务知识，用专业的话叫“业务领域分析”。在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。他们为什么要提出这项需求，提这项需求的目的是什么？只有经过这样的分析，我们才能深刻地理解需求，进而运用我们的专业知识，提出更加合理的技术方案。对于技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。因为苍白的拒绝客户往往会让客户产生抵触情绪，但当我们提出一个更加合理的方案时，客户往往会欣然接受，而且会感觉我非常专业，我在客户心目中的形象也会无形中提高，使得我有更多的机会提出有利于开发的可行方案，降低开发的风险。
学会迭代，也就是在项目开发阶段不断的重复捕获需求->整理需求->验证需求的过程。不然就会像作者提的第三个故事一样，项目开发过程中没有进行迭代，当把项目成果向客户展示时，顾客会提出很多要求，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。
学会捕获需求。我们与客户在一起开研讨会，讨论需求。我们在纸上绘制简单的流程草图把业务流程记录下来；客户在描述业务的时，可能会反复提到一些业务名词，详细询问这些名词的含义，以及它们与其它名词的关系，用类图或者对象图绘制简单的草图；客户在描述业务的同时，还会提出今后的软件希望实现的功能，以需求列表的形式记录下来。一个功能，在需求列表中会有多个需求，而每个需求应当能够用1、2句话，在20个字以内就可以描述清楚。需求列表是客户提出的最最原始的需求，他不掺杂任何分析设计，是我们的每项功能必须实现的内容。需求列表是需求验证以及日后的用户验收测试的依据。
学会功能角色分析与并且绘制用例图，用例图是站在客户的角度，我们要将分析设计图形化，使人立即就明白了其中的意思，但前提是，这个图形是主题清晰的、形象生动的。因此，我们绘制用例图要学会拆分，由粗到细地一个一个绘制。先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。所以，描述一个系统应当有许许多多的用例图。
学会业务流程分析，我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。信息化管理过细，无疑会加重基层业务人员的负担（这也正是为什么许多基层业务人员会排斥信息化系统的原因），而适当的信息化管理则可以提高工作效率。因此，我做需求分析，最喜欢下到基层去了解基层业务人员的需求，去分析怎样设计流程才能提高他们的工作效率，而避免加重他们的负担。“水能载舟，也能覆舟。”一套系统是否能顺利推行下去，基层人员是否支持往往起到十分重要的作用。另外，业务流程分析的另一个重要的分析内容就是流程差异化分析。不同的领导有不同的思路，不同的单位有不同的情况。因此，我们在进行流程分析的时候，常常面临流程差异化的问题。我们说企业信息化就是一次改革，这首先体现在业务流程的规范化操作，也就是消除这种流程差异。但不同的单位有不同的情况，这特别体现在不同地域和文化的不同，又常常造成这种流程差异不可避免。分与合，分治与一统，常常是一个都要兼顾的问题，非常微妙，我们要小心处理。在这个问题上你也许会问，使用工作流引擎就可以了嘛。工作流引擎不是万能的，它只能解决一部分问题，更多的问题还需要我们的分析人员去分析与处理。
在研讨会上进行需求研讨。我在进行需求研讨的时候，首先跟客户探讨的不是软件功能，而是客户现有的业务知识，用专业的话叫“业务领域分析”。在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。他们为什么要提出这项需求，提这项需求的目的是什么？只有经过这样的分析，我们才能深刻地理解需求，进而运用我们的专业知识，提出更加合理的技术方案。对于技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。因为苍白的拒绝客户往往会让客户产生抵触情绪，但当我们提出一个更加合理的方案时，客户往往会欣然接受，而且会感觉我非常专业，我在客户心目中的形象也会无形中提高，使得我有更多的机会提出有利于开发的可行方案，降低开发的风险。
学会迭代，也就是在项目开发阶段不断的重复捕获需求->整理需求->验证需求的过程。不然就会像作者提的第三个故事一样，项目开发过程中没有进行迭代，当把项目成果向客户展示时，顾客会提出很多要求，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。
学会捕获需求。我们与客户在一起开研讨会，讨论需求。我们在纸上绘制简单的流程草图把业务流程记录下来；客户在描述业务的时，可能会反复提到一些业务名词，详细询问这些名词的含义，以及它们与其它名词的关系，用类图或者对象图绘制简单的草图；客户在描述业务的同时，还会提出今后的软件希望实现的功能，以需求列表的形式记录下来。一个功能，在需求列表中会有多个需求，而每个需求应当能够用1、2句话，在20个字以内就可以描述清楚。需求列表是客户提出的最最原始的需求，他不掺杂任何分析设计，是我们的每项功能必须实现的内容。需求列表是需求验证以及日后的用户验收测试的依据。
学会功能角色分析与并且绘制用例图，用例图是站在客户的角度，我们要将分析设计图形化，使人立即就明白了其中的意思，但前提是，这个图形是主题清晰的、形象生动的。因此，我们绘制用例图要学会拆分，由粗到细地一个一个绘制。先整体的绘制，再划分成各个模块一个一个详细绘制，再进一步细化。所以，描述一个系统应当有许许多多的用例图。
学会业务流程分析，我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。信息化管理过细，无疑会加重基层业务人员的负担（这也正是为什么许多基层业务人员会排斥信息化系统的原因），而适当的信息化管理则可以提高工作效率。因此，我做需求分析，最喜欢下到基层去了解基层业务人员的需求，去分析怎样设计流程才能提高他们的工作效率，而避免加重他们的负担。“水能载舟，也能覆舟。”一套系统是否能顺利推行下去，基层人员是否支持往往起到十分重要的作用。另外，业务流程分析的另一个重要的分析内容就是流程差异化分析。不同的领导有不同的思路，不同的单位有不同的情况。因此，我们在进行流程分析的时候，常常面临流程差异化的问题。我们说企业信息化就是一次改革，这首先体现在业务流程的规范化操作，也就是消除这种流程差异。但不同的单位有不同的情况，这特别体现在不同地域和文化的不同，又常常造成这种流程差异不可避免。分与合，分治与一统，常常是一个都要兼顾的问题，非常微妙，我们要小心处理。在这个问题上你也许会问，使用工作流引擎就可以了嘛。工作流引擎不是万能的，它只能解决一部分问题，更多的问题还需要我们的分析人员去分析与处理。