阅读博客——我们应当怎样做需求分析？
一.需求调研
1.初识客户
初次接触客户，对于一个项目团队意义重大，对方对你的印象的好坏，今后如何与你的交往都在这个阶段被确定下来。我们需要与客户保持适当的谦卑，但是不要太过，因为过于谦卑会使客户变的很强势，最后会让我们很累很累，但是结果却不一定让客户满意。我们应该队客户提出的需求深入理解之后，运用我们的专业知识，提出比客户的原始需求更加合理，可操作的解决方案，让客户感觉到你说的就是他们想要的。这样更利于以后的开发。
在一个群里当中，客户会按照职能的不同分成不同的角色，一个单位可以被横向分成许多个部门，但是也可以划分为高层领导，中层领导，与基层人员。我们需要弄清他们每个层次所关注的东西，弄清楚每个角色的需求提出者和决策者，就是为了在今后的需求调研中找到正确的人，使今后的调研工作事半功倍。我们要在需求调研阶段降低软件的多元化需求，要解决这样的问题，首先应当从高层领导着手，提出规范化管理的口号，同时，在进行需求调研时，尽可能地召集各个单位的代表一起开会讨论。同时，应当有高层领导，或者指定一个负责任，在出现分歧的时候最终拍板决策，这些需要求项目启动时规划好。
2.拜访
软件供应商与客户建立的是长期供应的战略协作关系，这更需要我们与客户建立长期友好的关系。我们需要善于分析一个客户人群的关系，就是在分析这个人群中，谁愿意支持我们，而谁在不知不觉的阻碍我们。那些通过这个项目可以提高政绩，提高自身价值的人，都是我们可以争取的盟友。他们是我们最可以依赖的人，我们一定要与他们站在一起建立战略合作伙伴关系。报着谦虚谨慎，相互尊重的态度，大方地与他们交往。当他们帮助我们以后，真诚地予以感谢。经过一番交往，我们将举荐在客户中结实一批可以帮助我们的人。在今后一段日子里，我们将依靠他们学习和认识业务知识，手机业务需求，为今后的软件研发提供素材。
3.研讨会
项目负责人和业务人员，客户代表定期进行研讨会，根据业务的特点，将人员分成若干个业务组，分别对每个模块进行讨论，最后做出最后的决定，让问题处理更加高效，最终在软件维护中体现出来，让客户去选择自己的管理模式。研讨形式有集中式的业务研讨形式，也有分散式的业务研讨形式，应该根据实际情况选择合适的研讨形式。
4.需求调研
在需求调研的时候，首先和客户探讨的不是软件功能，而是客户现有的业务知识没，然后更加详细地描述怎么进行业务领域分析。只有认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求，我们才能更深刻地理解需求，运用我们的专业知识，提出更加合理的技术方法。客户是非专业的，我们要在理解客户真实意图之后，提出比耿虎更优的解决方案，对于一些难于实现或者根本无法实现的需求，我们应当耐心说服和引导客户，并且提出合理方案。需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
5.迭代
在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••
需求捕获，就是我们与客户在一起开研讨会，讨论需求的活动。
需求整理，就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。
然后，我们再在整体用例图的基础上，依次对每个用例绘制用例图。
用例分析的过程，之所以称之为分析，它掺入了很多需求分析人员对业务的理解与设计：模块如何划分、流程如何设计、业务如何转换，等等。用例分析，还需要让需求分析员与架构师、设计师等技术人员共同协作来完成，因为用例分析还包含对业务需求的技术可行性分析。
在用例分析的同时，需求分析人员还需要对业务中的相关事物，制作领域模型。
最后，当我们完成了一系列的分析整理并形成文档以后，应当对及时地与客户进行反馈，确认我们的理解是否正确，也就是需求验证工作。
需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
6.需求捕获
需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作？但是，非常遗憾，按照我以往的经验，需求捕获是我们最薄弱的环节。需求捕获是整个需求分析工作中最难把握的一个部分，它不仅仅是一个技术的问题，还涉及到人际交往、沟通、知识理解，以及心理学等一系列问题。我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。如果需求人员能上到这样一个高度，我们的需求分析就进入了一个更加崭新的层面
二.需求分析
1.功能角色分析与用例图
我们对需求的分析，首先应当从功能角色分析开始。对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。
2.业务流程分析
我我们绘制的用例图应当能够为用户所理解，这对于需求分析过程中与客户的沟通是大有好处的。我们一定要沉下气来认真仔细地做需求分析，我们可以有两个方向细化需求：业务流程分析与业务领域分析。我们可以进行我们对流程改进的分析：清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。
3.用例说明
当我们进行业务流程分析时，只空对空而不落到纸面上是不可以的。现在，在面向对象的时代，我们则是绘制行动图、状态图，以及编写用例说明来完成这部分工作。在绘用例图时，我们最好将需求列表附在用例后面，便于日后的需求评审与确认。当每次需要升级时，则添加上新的需求，或对以往的需求进行更新。
4.查询报表分析
对于些查询、汇总与报表功能，需要我们描述的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。那么我们需要写一个查询报表。一个报表的核心就是展现给客户的报表格式，以及报表与报表间的各种链接。
5.子用例与拓展用例
子用例应当是在逻辑上相对独立的一系统流程组成的用例。这个用例应当是抽象的，没有自己的参与者，只有在调用它的用例中，才能真正明确它的使用者。用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。
6.行动图和状态图
用例图并不能最好最全面的描述，所有我们还需要行动图和状态图。行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。状态图就是对关键对象中流程中状态变化的描述在需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。
7.业务领域分析
在需求分析工作中，最后一项分析工作就是业务领域分析啦。就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。
三.需求确认
我们根据用户的初步需求构建出一个实物提供参考，然后再不断细化，从而使用户的需求展现给需求人员。写规格说明书，评审与签字确认会最后完成需求确认。
