通过阅读《我们应当怎样做需求分析这篇文章》我大致了解到了最基本的几个步骤（1）需求的调研（2）需求的分析（3）需求的确定
一：需求调研需要经历这几个阶段
1首先是与客户的首次认识
在客户至上的今天，与客户保持适当的谦卑是有必要的，但过于的谦卑却常常给项目日后的进程带来风险。过于的谦卑，处处都是诺诺诺，客户说什么就是什么，就会使客户变得非常强势。这样的结果就是，客户提出了许多变态的、不太现实的、不合理的需求，而我们呢却是一味地服从，客户说什么就是什么。最后我们做得很累，结果却不能让客户满意。正确的做法是，我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。
2再就是拜访客户
需求分析需要与客户进行交流，与人交流就要处理好与他人的关系，我们应该在项目的整个过程中与客户建立良好的友谊关系，好的关系可以提高交流的效率。客户是一个大群体，有很多部门，有的部门与项目关联较大，有的则关联较小，不管关联大还是小我们都要与客户建立良好的友谊关系，这对项目的良好开展非常地重要。
3然后是我们怎样开研讨会
业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
4就是需求研讨了
需求研讨是在客户提出需求时，需求人员对客户的需求进行可行性分析，因为客户一般都是非专业人员，对项目的开发不了解，以致于提出的需求不合理或者很难实现，所以需求人员需要对希求进行可行性分析，如果客户提出的需求不合理则应该充分了解客户为什么会提出这项需求，客户究竟想要实现什么功能，充分了解客户，充分理解需求，制定出替代的方案，然后跟客户进行协商，以达到客户的满意和自己项目的正常进行。
5是迭代
需求分析不是一蹴而就的，是一个反复迭代的过程。它将从第一次需求分析开始，一直持续到整个项目生命周期。在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
6是需求捕获
从客户那里得到需求是需求分析的关键，如何从客户那里捕获需求，捕获的需求是否明确非常重要，我们应主动地从客户那里捕获需求，不能被动地捕获，这样可以有效地分析客户业务的详细流程，了解由谁来操作，并了解为什么要这样操作，深入地了解这些领域和知识，另外因为我们对客户的业务不熟悉，我们要主动地对客户进行询问，深入明确地了解用户的需求和业务流程。大多数客户对于软件开发并不专业，所以很有可能会遗漏一些东西，需求人员应该深入分析客户的需求，提出客户遗漏的东西，使需求更接近与客户真正的需求。
二：需求分析包含以下几个方法
1功能角色分析与用例图
我们应根据需求分析角色，分析出各个角色的功能，绘制用例图，其中包括参与者、用例与系统边界。用例图是提供给客户看的，所以不应该出现技术性较强的表达方式，应该用客户易懂的词语进行功能描述，从而让客户了解我们了解到的需求，并提出修改意见。
2、业务流程分析
将从客户调研现场拿回来的需求，经过一番功能角色分析，整个系统的整体脉络与轮廓已经被勾画出来。在这个过程中，我们首先将系统划分成了几个功能模块（如果系统规模较大，还应先划分为几个子系统，然后再划分出各个功能模块）。然后，我们为每个功能模块绘制用例图。用例图是站在用户角度去观察的系统，即系统为用户提供了哪些功能，这就是功能分析。同时，这些功能是为哪些用户服务的，这就是角色分析。我们绘制的用例图应当能够为用户所理解，这也是UML其中的一项核心思想——与客户形成统一的、能够相互理解的语言，这对于需求分析过程中与客户的沟通是大有好处的。
3、用例说明
在进行业务流程分析时绘制用例图能够生动形象地描述我们的分析，但是其会丢失很多信息，所以我们需要有一些文字的描述，就是用例说明。
4、查询报表分析
我们应根据需求实际设计不同的查询报表，报表的内容应符合客户的需求，对必须的内容要加上，不需要的可以删掉。
5、子用例与扩展用例
在基本流程中将多个用例所共有的，可以相互共享的流程，将这些流程提取出来就是子用例，这样提取公共部分提高了系统的内聚降低了系统的耦合。
6、行动图和状态图
用例图只是描述了某一个用例自己的功能，而各个功能很分散，没有联系，所以需要行动图和状态图来将各个模块组织起来，来对业务进行整体的描述。状态图描述了业务流程状态的转换，可以清晰地展现各个业务流程。
7、业务领域分析
业务领域分析就是通过与该业务领域的专家进行学习，了解该领域的一些基础知识，然后构建该领域的知识体系，了解该领域需要什么实体，并可以对业务流程更加熟悉，有助于在项目开发中进行参考，从而提高项目的正确性和提高项目的开发效率。
业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。前面我们谈到了功能角色分析，或者说用例分析，它是从整体的角度对整个系统人机交互的分析与整理。随后我们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。业务流程分析是对系统进行的一种动态的分析，分析的是那些行为，那些操作。
8、原文分析法
原文分析就是分析需求的原文，提取出业务领域的名词，对名词进行分析提取出业务领域的实体。
9、非功能需求
非功能需求包括可用性、可靠性、性能、可支持性以及其他，非功能需求时需求人员非常容易忽略的，但是确实对软件开发非常重要的，某一方面考虑不周全，可能会导致软件的失败，例如界面不友好，性能差，支持性差等都会导致客户不想使用导致软件开发的失败。
三：需求确认
1需求列表
2一个需求列表的实例
3快速原型法、
4需求规格说明书
5评审与签字确认会