通过阅读《我们应当怎么做需求分析》：http://blog.csdn.net/yqmfly/article/details/7679781 一文，我了解了需求分析的基本步骤和一些方法
通过这篇文章的标题，可以得出软件需求大致分为三步：需求调研，需求分析，需求确认
:（1）需求调研：如何与客户交流、建立联系、研讨业务需求，捕获需求
：（2）需求分析：功能角色分析、业务流程分析与业务领域分析，用例分析及用例图，查询报表分析，原文分析，非功能需求
：（3）需求确认：需求列表,需求实例，快速原型法，需求规格说明书，评审与签字确认会
一， 需求调研
1.与客户交流的方法
首要的是收集需求，收集需求的方法千千万，直接征集客户意见是最简单粗暴的一种，但是效果却不一定有多好
与客户交流过程，不仅需要我们的理解、设计能力，更需要我们具有与人沟通交往的能力，Wiegers的《Software Requirement》中更是提到，What & Why，在与客户沟通时，我们不能仅仅局限于What ，客户说什么就是什么，而更应该从Why方面展开，通过理解客户的意图来得到对客户意图更深入的理解，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。大方而得体地提出自己的意见，会使客户重视你的意见，甚至主动征求你的意见。这一方面要求我们对自己要有足够的自信，另一方面也要有循循善诱的表达能力。
2，主动收集需求
除了向客户收集需求外，还可以通过访问用户，实际体验，问卷调查，市场调查等手段收集需求
3，迭代
从客户嘴中说出来的需求，只是整个软件需求中的冰山一角，还有两类需求需要我们自己去挖掘：客户嘴中没有说出来的需求，和客户压根儿就没有想到的需求。
客户嘴中没有说出来的需求，并不是客户故意卖弄官子不愿说出来，而是在客户所在业务领域已经约定俗称，在他们看来已经是天经地义，根本就不用说出来的业务规则。然而，作为刚刚涉足该领域的需求人员，他们是不了解这些规则的。
如何破解这样的问题呢？那就是要求我们在需求分析的整个过程，不断进行业务领域知识的学习。多问Why而不是What
另一种就是客户压根儿没有想到的需求。
如何解决这样的问题呢？首先，在需求分析阶段，需求分析人员应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。先用最短的时间先做一个可以展示和操作的原型给客户看，让客户提一些意见。然后再在这个原型的基础上再多做一些，再给客户看。一步一步推进，直到最终项目研发结束。采用这样的方式，最适合那些客户在项目初期提不出什么需求，也没用合适的参照物来进行需求分析的软件项目，特别是那些数据分析与决策类的软件项目。
二， 需求分析
需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。因此，我们应当采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。不同类型的软件项目其分析方法可能存在差异，但一般来说，信息化管理类软件项目通常从这几个方面着手分析：功能角色分析、业务流程分析与业务领域分析。
需求分析不是一项一蹴而就就可以完成的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。
1， 功能角色分析
所谓功能角色分析，就是从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给哪些角色使用。对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。
2，业务流程分析
如果我们现在做的需求分析是一个企业信息化管理系统，毫不疑问，我们的软件系统就是在模拟企业已有的那些业务流程。在现实世界中，企业是按照怎样的流程来管理，我们的软件就应当去模拟这样的流程。但是实际上，存在诸多问题导致我们不能完全模拟这些流程，有些环节则是应当在系统之外，由人工去完成的。我们进行流程分析，就是要求分析哪些是系统之内的，哪些是系统之外的。
除此之外，还可以对流程进行改进。一般来说，我们可以用以下思路来进行我们对流程改进的分析：清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。
在进行业务流程分析时，不可避免要用到用例分析、报表等
3， 业务领域分析
业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。我们进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。
3， 非功能需求
那么哪些是非功能需求呢？我们可以简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。这些不针对于系统的功能，但却对系统至关重要，非功能性需求是常常被轻视，甚至被忽视的一个重要方面。
三.需求确认
1，需求列表
需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。用这样一个列表来开始分析，最后用它来验证设计，为软件开发指明方向。
其次，需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。
需求列表描述的更应当是客户对软件功能的意图，即客户使用这个功能所达到的目的，而不是功能的具体实现。
最后，需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。
2， 快速原型法
在需求分析阶段拿出实物，用实物与用户确认需求，这就是快速原型法的基本思想
3， 需求规格说明书
用户编写的原始需求，是脱离了技术实现，编写的一份十分理想的业务需求。我们之所以要编写自己的需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。
来源：https://www.cnblogs.com/sdysyhj/p/8530348.html