需求分析方法和实践

   软件项目中40%-60%的问题都在需求分析阶段埋下的隐患。软件开发中返工开销占开发总费用的40% ，而其中70%-80%的返工是由于需求方面的错误所导致的。如果我们在需求审核阶段上投入1小时，就节省10个小时以上的错误更正时间，成功的需求开发和管理能节省大量的资源，因此需求分析是软件开发的关键阶段。

说一下需求分定义：

         如何表达这种需求，现在用得最多的就是书写需求规格说明书，虽然这仅仅提供了一个模型、一种描述

但编写出高质量的规格说明书在需求分析阶段还是关键。所以，需求就是指明必须实现的目标的规格说明。它描述了系统的行为和属性，是在开发过程中对系统的约束。

需求的类型：

        1、业务需求    2、用户需求   3、功能需求   4、飞功能需求

需求分析的任务：

       需求分析阶段要完成的具体明确的任务就是最终形成一份经开发方和用户认可或达成共识的《需求规格说明书》。

了解了什么事需求，它的几种类型及其主要交付物后，我们来看看如何开展需求调研的工作，具体步骤都有哪些？

需求开发和管理的步骤：

   1.需求开发：

    1.1 需求获取

           需求获取的过程就是通过需求调研，获取清晰、准确的需求。获取需求的一个必不可少的结果，是分析者、开发者和客户对项目中描述的客户需求的普遍理解。关键问题是需求调研的范围及深度如何确定。

           需求获取的一般步骤是：

                    目的：明确系统总体目标，定义项目的视图和范围，划分子系统；

                    做法：了解手工的流程和已经使用的老系统的功能和流程，手机各种单据、报表格式等原始资料，分析数据流和控制流，画出每个工作流程的流程图；罗列出决策层、管理层、操作层的不同需求，是下层满足上层的需求，调整流程图；找出疑问、及时和用户沟通。

总结一句：通过资料收集、访谈、调查、实际观察等方法，了解用户的业务流程、哥哥关键点的操作；明确上层领导、管理层、操作者的本质需求，并与大成一致；

        需求分析

         需求分析的过程就是将收集到的调研信息加以处理并理解它们。

          把调研信息分成不同的类型。同时将客户需求同可能的软件需求相联系。然后将客户信息结构化，编写成文档和示意图，作为提交给让客户代表评审并纠正存在的错误的一个书面文档。重要详述需求，一确定用户目标和任务，并把它作为食用实例，进行深入收集和分析，消除任何冲突或不一致性，拟定出详细的使用实例，使其融合到必要的功能需求中，为编制测试用例做准备。

         进行需求分析时，尽量理解用户用于表述他们需求的思维过程，从分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。避免使用用户提出的需求细节，因为会随后的设计过程带来不必要的限制，周期性地检查需求获取，以确定保用户参与者将注意力集成在与今天所讨论的额话题适合的抽象层上。此外，不可忽视飞功能需求的描述。它表明了系统得 限制和用户对质量的期望。

        为了更好地跟用户交流，最初的屏幕构思有助于描述开发人员对需求的理解，可以利用visio这个工具来设计界面。如果项目开发周期允许，可以开发原型来交流和确认。最后针对用户的需求说明细化用户界面设计，有助于对需求达成共识，为以后的设计工作带来便利。

          总结一句：将收集到的信息，利用分析工具进行归纳，筛选后，并有机的组织到一起，制作demo并梳理其各个功能之间的关系，将了解到得需求用可视化的形式展现出来（有条件的情况下）。

编写需求规格说明书：

       需求开发的最终成果是形成一份客户和开发小组对将要开发的产品达成一致的协议，也就是我们所说的需求规格说明书，需求规格说明书综合了业务需求、用户需求和软件功能需求。同时增加描述产品的非功能性方面的需求，包括质量属性和外部接口需求；

        需求规格说明书除了罗列各种系统功能外，最好以用例来说明问题。用例分析是消除需求不明确、不一致、不完整的重要手段和关键。使用用户的好处在；有效表发用户的任务目标层次；完整反映使用软件功能的实例、处理流程（例：交互行为序列、正常 /非正常事件流）；显著突出用户和系统行为的特殊行为情况、扩展条件和约束；是测试用例和用户界面设计的天然来源。

       除了编写需求用例，最好再写个未来系统的用户手册，这样更能帮助彼此之间的沟通和消除很多不明确的地方。

总结一句：需求规格说民书的好坏，很大部分取决对客户需求的正确了解，单在已经正确了解的基础上，还需要考虑，一些分功能性方面的需求；

需求验证：

        需求规格说明书完成后，并不能说已经完成了需求分析阶段的工作，可以进入设计阶段了，只有以结构化和可读性方式编写玩这些文档，并由项目的风险承担着评审通过后，各方面人员才能确信他们所阵痛的需求是可靠的，这个阶段工作才告完成。

        需求验证的只要内容有：需求规格正确描述了预期的系统行为和特征；软件需求复合业务需求或者其他来源的需求；需求是完整和高质量的，所有对需求的看法。观点是一致的；需求为产品设计、构造和测试提供了坚实的基础。

        需求验证的手段主要有软件审核和软件测试。在需求规格说明书形成后。必须进行需求评审，来检验质量。测试阶段对软件功能的验证，其实也是对需求的再次验证。

         以上需求开发的四个阶段并不是严格按照需求顺序进行的，这些活动是相互分离，但又是曾量和反复的，是一个迭代的过程，然后让客户代表评审文档和纠正存在错误，这四个过程贯穿于需求开发的整个阶段。