我们应当怎样做需求调研？
首先是双方初步认识，这个时候需要树立良好的职业威信，在交谈中进行详细角色分析，将与会各方代表对号入座，最后从宏观上制订目标与方案。
做好初步认识之后，接下来就要一一去拜访这些对应角色了。需求不是一蹴而就，在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求，这都需要有良好的客户关系。按照现在的软件运作理念，软件项目已经不是一锤子的买卖，而是长期的、持续不断的提供服务，这更需要我们与客户建立长期友好的关系。
拜访，则是分别去拜访软件的用户，当然开始是要搞好感情，然后再展开调研，看看他们的工作流程以及对软件的功能需求，同时还要为了以后工作更好的展开，拉拢可以合作的人，弄清会阻碍我们项目进展的人。
研讨会，就是将各个阶层的用户代表聚集在一起，提出他们各自的业务需求，并且对于有差异的业务需求做出一个确定的管理模式，我们的软件就是要规范各分支机构的管理，抑制个性化差异。
需求研讨，就是与客户进行软件功能需求的讨论，不同的客户对我们专业的了解程度不同，所以对于软件本提出功能需求的能力不同。对于不了解我们专业的客户我们不应该只停滞在他们提出的需求，更加要去挖掘客户没有提出但必须有的功能。而对于了解我们专业的客户经常会提出比较全面的功能需求，但他们往往要求太多而且不是最优的解决方案，此时我们就需要耐心说服客户接受我们的方案。
需求捕获，为了软件产品更好的满足客户要求，我们必须尽可能准确的捕获客户的需求，当然有些需求客户可以想到并且提出，但我们也要挖掘出那些客户应该提出但没有想到的功能需求。当然对于客户提出的变态的，技术难于实现的，我们需求分析员不能盲目地去记录。为了更好的了解客户的需求，很多时候我们都要去涉足客户的专业领域，当然这不是要求我们成为相关领域的专业人士，我们只要知道一些基本信息就可以了。
功能角色分析与用例图，当完成需求捕获后，我们就要对捕获的信息进行分析，对系统中每个功能和角色进行梳理和分析，对于系统应有的功能，角色以及每个角色应该具备的操作权限，都要进行准确的定位，当然用例图是最适合表示这些信息的工具，但我们要记得尽量使用客户看的懂的语言。
业务流程分析，对于软件来说是模仿企业的整个业务流程，所以我们必须熟悉企业的整个业务流程并且分析在这个流程中我们可以做些什么，业务流程分析就是分析业务流程中哪些需要信息化管理，哪些不需要，哪些我们能做到，哪些我们做不到。因为如果信息化过细，只会加重人们工作的负担，这就背离了我们做软件的初衷。
用例说明，即是用图的形式尽可能的对每个用例进行全面的分析，使每个用例更加形象可观，避免遗漏细节。
查询报表分析，通过数据揭示一些客观规律，复杂活动与发展趋势，方便领导对员工工作进程的了解以及对员工的管理。
首先，需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。
应当在需求分析阶段采用快速原型法，拿出实物，用实物与用户确认需求，
本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。从理论上讲，需求规格说明书分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言来表达大家都清楚明白的概念。从这个角度将，需求规格说明书就应当是一个，不区分用户需求规格说明书和产品需求规格说明书。
最后需要的就是评审与签字确认会。需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。
需要掌握的内容上有：
在开发过程中，要有迭代的思想，同时要把迭代用于实践，不断的与客户进行交流反馈，及时获得反馈信息，来进行需求的更新。
用例图，活动图等常用uml图的绘制。这些图是描述系统各部分之间联系的表示图形，需要清晰的将系统功能进行表示出来，
用例说明，同用例图一样重要，用例图不能清楚的反应各个相互联系，还需要语言描述来更加清楚的表达。
规格说明书，文档的书写是非常重要的。