一、软件需求的目的：

1.准确的理解和描述客户需要的功能

客户只知道他不满意，但怎样才能使他满意呢？他不知道，于是就在一点儿一点儿试，于是这种反复变更就这样发生了。

如果我们明白了这一点，深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。记住，当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。业务场景是需求之魂，我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。

2.帮助客户挖掘需求

他们的需求与我们的需求之间有一些距离，我们的需求仅仅是对方能满足和达成的一部分，对方有更多的目标和愿望需要我们去挖掘和助其达成，而那些潜在需求得到满足时，这种显性需求自然而然便被解决。且在挖掘用户需求时，变陈述句为疑问句是比较关键的方法，通过提问，获得用户究竟“要什么？”、“为什么要”、“其他需要”，讲究提问方式和技巧，以同理心去倾听。

3.分析客户需求的可行性：

需求分析的本质在于业务分析，而非技术分析。但我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。那种“有条件要上，没有条件创造条件也要上”的鲁莽行事，结果必然是悲惨的。所以我们必须要基于技术实现去引导客户的需求。我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。

需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。敏捷开发倡导需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。

二、需求分析分为三个阶段

1.需求提出（应当怎样做需求分析）

主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。开发人员和用户确定一个问题领域，并定义一个描述该问题的系统。这样的定义称作系统规格说明，并且它在用户和开发人员之间充当合同。

需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。

他们为什么要提出这项需求，提这项需求的目的是什么？只有经过这样的分析，我们才能深刻地理解需求，进而运用我们的专业知识，提出更加合理的技术方案。但非常遗憾，我们在需求分析中常常不是这样做的，甚至当软件都开发出来了，需求分析人员都说不出客户为什么要提出这个需求，更谈不上了解业务操作流程。一句经典的话是：“客户让我们这样做的。”

需求捕获->需求整理->需求验证->再需求捕获??????

2.需求描述（需要的设计和文档）

在问题分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。

采用原文分析法，是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。

领域驱动设计，建立模型，需求列表

3.需求评审（应当怎样做需求确认）

在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。

理想与现实总是有差距，我们之所以要编写自己的需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。

我们说这种需求分析工作不可能完全完成，或者说日后用户的需求会变，其实并不是毫无规律可循的。通常，用户对需求的变更只发生在某些固定的范围内，弄清楚了这些范围，我们的问题就迎刃而解了。

需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。

参考博文：http://blog.csdn.net/yqmfly/article/details/7679781