一、
初识
我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。
划分清楚角色，弄清楚每个角色的需求提出者与决策者，就是为了在今后的需求调研中找对正确的人，使今后的调研工作事半功倍
1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。
拜访
做事先培养感情，感情培养起来才好慢慢做事
研讨会
业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会
需求研讨
认识客户的业务领域之后，我们才能去分析他们提出的所有原始需求。
迭代
需求分析不是一蹴而就的，是一个反复迭代的过程。需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获······
需求捕获
从客户嘴中说出来的需求，只是整个软件需求中的冰山一角，还有两类需求需要我们自己去挖掘：客户嘴中没有说出来的需求，和客户压根儿就没有想到的需求。在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。
功能角色分析和用例图
不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。
用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。
业务流程分析(细化需求)
分析哪些是系统之内的，哪些是系统之外的。
用例说明
当我们进行业务流程分析时，绘制行动图、状态图，以及编写用例说明
查询报表分析
根据需要设计自己的格式
报表作用：就是描述参与者使用这个报表做什么。如果有多个参与者，每一个都应当描述。
报表内容：用简短的话描述一下。
输出列：罗列报表的输出列，如果需要的话，还应对输出列进行说明，或描述它的数据来源。
使用频率：参与者使用它的频率，便于设计者考虑报表的查询效率。
数据链接：哪些数据项有链接，链接到什么报表，或显示什么数据。
子用例和扩展用例
用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。
行动图和状态图
业务领域分析
对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。
原文分析法
对用例说明中事件流部分的文字描述，提取其中的名词。
系统之内的事物转化到领域模型中，可能会变成两种东西：实体与实体中的属性。
名词的多义性。
用例说明中的动词分析，是为了定义各个实体之间的各种行为。原文分析方法，给了我们一个简单可行、易于操作的方法，让我们准确而高效地完成业务领域分析。
领域驱动设计
非功能需求
非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容，是需求人员最不擅长的方面
那么哪些是非功能需求呢？我们可以简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。而这5部分我们可以进一步细化。
需求列表
我们的项目需要对需求的跟踪
需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。
快速原型法
我们就应当在需求分析阶段拿出实物，用实物与用户确认需求
需求规格说明书
本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。
评审与签字确认会
需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。从理论上说，需求评审会应当由用户代表，与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理，还有公司相关领导参加。但实际上，让如此多不同角色的人聚集在一起开会是不现实的。因此，我们可以将需求评审会分为内部评审会与外部评审会两部分来开比较现实。