标签：
软件的项目，有成功的案例，但是除此之外，也难免会有失败的经历，而且这也不在少数。造成项目失败的原因多种多样，客户关系、设计、技术、时间管理、问题培养，但是归根到底，更多的问题还是归咎于需求分析没有做完善：被不懂技术的客户牵着走，没有分析到位；没有弄清需求是否能给予我们现有的技术；是否触及到了有需求的所有层面的人员，没有合理安排和客户进行需求的多方面交流，来保证项目的成功，这些都源于没有做好需求分析。为了不重蹈覆辙，了解软件需求与分析十分有必要。
做需求分析大多是从需求调研开始的，尽管如此，但是重要性不可小觑，它是对我们体力和技术的双重考验。其中最重要的三点：树立良好的职业威信、进行详细角色分析，将各方代表对号入座、宏观制定目标与方案。我们需要有理解、设计能力，更要有与人交往的沟通能力。与客户的见面会就是调研的开始，我们要在和客户的交流中展露出我们的专业，不仅能快速树立起我们的形象，作为之后交流的基础，更有利于今后的开发，让我们在开发中占有主导地位，形成良性循环。不同的展现会直接影响到后期的项目开发。同时还要兼顾项目的准备工作，搞清面向的角色，对不同层次的人要进行不同的询问。
要和各个类型的客户打交道，逐个拜访，搞好关系，培养起感情，也会开一个好头。在漫长时间里，建立长期共赢是长远之计。这不是讨好客户，而是为了更好地了解他们的业务知识，收集业务需求，为日后的研发提供帮助。
建立基本的关系之后，有了可以了解业务知识的途径后，研讨会就为我们提供了一个通过合适的形式和用户进行业务需求研讨的方式。这个过程中可以解决许多潜在的问题，保证有效抑制个性化差异、分模块组织转型研讨会，这可有效的提高安全性。我们希望客户提出正确的需求，但是出于专业，他们并不能完全提供我们想要的结果。所以我们要先进行业务领域分析，学习基本的领域知识，并借此重新整理用户的原始需求，保证需求的正确与变更的可控。
我们总体的需求分析过程大概是这个样子的：需求捕捉，需求整理，需求验证，再循环。不断从客户那里得到原始需求，之后进行用例分析，希冀得到最符合用户要求的需求，完成之后，与客户进行反馈，需求验证，逐步理解深入用户的满意。
其中需求捕获是整个需求分析工作中最难把握的一个部分，它不仅仅是一个技术的问题，还涉及到人际交往、沟通、知识理解，以及心理学等一系列问题。学习业务领域的知识，一遍开发，一边演示，争取步步为营，实现适合信息化管理的流程。我们要采用成熟稳重的完整方法来分析，主要包含三个方面的分析，下面进行详细的介绍：
①功能角色分析：使用用例图，罗列出各角色的功能以及相互之间的关系，将整个系统变得更加清晰可见。向用户介绍需求成果时，一个好的用例图辅以好的描述会对整体增分不少；
②业务流程分析：对于一般模式的系统，利用通用的需求列表，仔细分析客户的业务流程，争取做到：清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。同时还要进行一定的用例说明并绘制行动图、状态图。对于一些不同与一般的系统，它包含特殊的功能，例如：查询、汇总、报表，我们还要按照实际的需要来改变列表的格式；
③业务领域分析：对需求分析中涉及到的业务实体，以及它们之间的关联关系的分析，用于指导我们的开发过程。他常见的有两种方法：原文分析法（在用例说明和流程分析的基础上进行业务领域分析，用于需求研讨会后整理和分析需求），领域驱动设计（与客户使用同一种语言进行沟通与讨论，实现消除障碍），针对不同类型的业务领域及解决方向，我们可以选择最适合我们的方法。
总而言之，功能角色分析，或者说用例分析，它是从整体的角度对整个系统人机交互的分析与整理。随后我们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。业务流程分析是对系统进行的一种动态的分析，分析的是那些行为，那些操作。
还有一些非需求功能常常容易遭到我们的忽视，因为他更靠近技术，是实现，是架构师关心的内容，而这恰恰是需求人员不擅长的方面。这时，架构师就应该参与其中，参与到需求分析中，考虑技术的可行性，以及性能、安全性、可靠性等其它非功能需求，开始架构设计。
如实记录原始需求，不掺杂分析人员对业务需求的分析与设计，简明扼要，直接体现出客户需要系统提供的功能。逐渐整理，不断增添和修改。
在需求分析阶段拿出实物，用实物与客户进行确认，可供用户进行使用、补充、修改。同时这也极需要我们自己的把握，快速开发，顺畅的与用户确认需求。
回归技术本质，本着实事求是，切实可行的态度，使得需求变成可解决的方案。
评审与签字确认会：
需求分析工作不会完全完成，其中最重要的是确定：整体框架与功能模块。
结束的里程碑：确认需求，内部评审会和外部评审会。
起决定性作用。
标签：
原文地址：http://www.cnblogs.com/Daddy/p/5883705.html
