需求获取只是一个收集信息的过程，是最大化的获取用户信息，且要确保收集到的信息是有效的，尽管提到需求分析是对已获取用户信息的分析，但无可避免的是这种分析是无处不在的，在与用户的沟通、在与用户的谈判等等，所以，很多时候业务领域/项目领域的专家在这个阶段会有先天的优势，但就像前面所谈，需求获取和需求分析通常都是同步进行的，这个两个过程是无法分开的。
1) 需求分析（***）
需求分析应该是建立在业务分析层面上，但在这个过程中又无可避免会涉及到系统的问题（以用户为中心，业务场景及用例场景的描述）。从笔者的角度来看，需求分析主要是侧重于业务逻辑本身、潜在的业务需求，同时还需了解业务本身的发生频率、重要级别等内容。总之，需求分析就是对业务本身的一种深入理解，与需求获取同步的也多是这个过程。这个过程最重要的就是：从全局的眼光来透射项目的业务范围，从而比较准确地把握项目范围，形成正确的业务理解和需求定义。从而能够建立起完整的业务概念模型和比较稳定的需求设计模型。
在这里我们不得不提到的一个关键内容就是业务建模。业务建模如果仅从字面上理解，可以想象为是将获取的零散的业务信息，组织成为业务模型。这个过程中，实际就是深入理解业务的过程，只有理解了业务，才可以组织这些业务模型，甚至还需改进业务模型。同时在这个过程中会发现问题，同时还会发现前阶段工作的遗漏等等，然后有的放矢的去解决这些呈现在你眼前的所有问题。
找了一个业务建模的定义：业务建模，又称为企业建模。它是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。注意：是以软件模型的方式描述。这就提出了新的要求：需求分析师必须具备建立软件模型的能力。如果需求分析师不具备，那么在此阶段必须要有具备这样能力的人员来参与其中。这点很重要，为什么如此重要，可以看一下软件过程的发展史，有助于了解此内容。
需求分析常用的方法可总结如下：
a) 结构化分析；
b) 原型法；
c) 面向对象分析；
当今常用的业务建模的方法应该是面向对象的分析方法，在此笔者强烈推荐http://blog.csdn.net/coffeewoo/中的《OO系统分析员之路--用例分析系列》，此文章对建模进行了非常详细及非常到位的讲解，写的非常好。本来笔者也想对此部分进行一个说明，但看了此文之后，自愧不如，所以也只有强烈推荐的份了。
需求分析是非常重要的，它将直接决定了项目的成败。所以，在此阶段，笔者认为人的因素最为重要，方法并非是第一位的，所以无论是选择何种方式分析业务，一定要考虑需求分析师的能力。
需求分析师最熟练、最擅长的方法是什么，也许可能不一定完全适合项目的特点，但首先要确保可以适合需求分析师，作为需求分析师暂时没有掌握或者由于需求分析师能力造成的问题，只要可控即可，但在此阶段不建议给需求分析师加太多的压力。有种观点，不一定会得到所有人的认可，做项目不怕出问题，也不怕问题很多，最怕的是不知道问题所在，或者是知道了问题不知道该如何弥补。所以，如果给需求分析师过大的压力，会造成其他不可控的问题，所以与其不可控，不如减轻需求分析师的压力，让其按照适合的方法去做，让其把业务分析透彻，成为一个业务的活字典，针对此阶段部分工作质量不到位的情况，可安排其他人员或者在其他环节来解决。当然如果这样做，就出现了管理的漏洞，至于如何解决不是本文探讨的重点，只是提出这样一种观点，并且笔者可以很负责任的说，这个问题曾经在笔者参与的项目中肯定存在，且经常存在，对项目的影响有大有小，甚至重新返工整个需求阶段也是有的。
总结了一些在需求分析阶段常出现的问题：
1、 忽略了范围：需求分析是一个分析过程（呵呵，绝对是废话），业务是一个关联不可分割的，所以，很容易从这里到那里，从那里再到更远的地方，天马星空，没有边界，做了很久，才发现这些内容并不是合同签订的范围，焕然大悟之后损失已经造成。所以需求分析师要有清晰的认识，不要超越项目范围。
2、 没有经过分析的结论：很多时候，当需求分析师了解了业务内容之后，根据经验也好、惯性思维也罢很快知道用户想要什么，系统该提供什么。尽管很多时候这些都是正确的，但如果缺少了中间的分析过程，还是有可能导致结论的偏差。要知道是有了“因为”才会“所以”，这就是追溯的重要性，过程可以在最终的SRS文档中省略，但不要在脑中和手中省略。
3、 方法的问题：这个问题是软件过程中任何一个阶段都会遇到的问题。软件过程发展至今已有些时日，所以在这个过程中所应用的方法有很多，所要了解的概念也有很多。不同的概念会应用于不同的方法中。譬如：现在很流行的OO。所以需求分析也就是面向对象的分析方法，但大家都理解了么？真正做到了么？还是可以看上面所推荐的文章，文中也提到了这个问题。所以，要知道，适合自己才是王道，不要一味的去追求什么先进的方法，一定要找到适合自己的。实际前面说的需求分析师的能力是主要也是谈的这个问题。
4、 过多的考虑了系统的问题而忽略了业务的问题：需求分析是一个转化的过程，需要将现实中的业务转化成为计算机的业务。专业点讲就是业务建模到系统建模。注意仅到系统建模。至于系统该如何完成，是设计的事情，不是分析的事情。尽管有些时候这个分析结果可以有助于后续的工作，有助于与用户的沟通，但还是要了解，需求分析就是需求分析，不是设计，更无法替代技术人员与用户的沟通。
