阅读文章《我们应该怎样做需求分析》我了解到，软件需求分析需要掌握以下的内容：

　　需求调研：对自己需要开发的软件进行调查，了解好用户的需求，针对需求做好准备。需求调研对于一个软件开发来说，是一个系统开发的开始阶段，它的输出“软件需求分析报告”是设计阶段的输入，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。

　　需求分析：针对自己调研出来的数据进行相应的分析，提取出用户真正的需求。需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

　　需求确认：用户开始的需求经过调研和分析两个过程后，列出最终的需求列表，与客户进行核对。书写需求说明书。

一、需求调研

初识：

     要让客户认识到自己的专业性。通过听取客户的需求，做出相应的判断，以专业的角度对需求进行理解并回复客户。不要在客户面前唯命是从，要适当地提出自己的见解，这样不但会让客户对自己有信心，而且自己也可以规范化客户的需求，不至于客户提出什么我们就按照客户说的做什么。进行详细的角色分析，对号入座。客户方有很多的角色，每一个角色都有自己独特关注的地方，要合理地进行角色分析，让他们了解他们所希望了解的问题，对于需求的调研分析非常地重要。从宏观上制定目标。在将角色进行分析后，要对每一个角色进行特定地分析，与各个角色进行详细地业务分析，详细了解业务的流程，对于需求的分析非常重要。

拜访：

需求分析需要与客户进行交流，与人交流就要处理好与他人的关系，我们应该在项目的整个过程中与客户建立良好的友谊关系，好的关系可以提高交流的效率。客户是一个大群体，有很多部门，有的部门与项目关联较大，有的则关联较小，不管关联大还是小我们都要与客户建立良好的友谊关系，这对项目的良好开展非常地重要。

研讨会：

将项目负责人以及客户代表聚到一起开需求研讨会是非常重要的，在研讨会上可以详细地对项目进行需求分析，将客户聚到一起一方面可以将各个部门的客户的需求统一化，避免每个部门的需求不一致，导致项目需要开发很多的版本，导致项目太大开发困难而且不容易维护；另一方面可以将各个部门的需求进行分析，取长补短，从而制定一个好的项目。

需求研讨：

需求研讨是在客户提出需求时，需求人员对客户的需求进行可行性分析，因为客户一般都是非专业人员，对项目的开发不了解，以致于提出的需求不合理或者很难实现，所以需求人员需要对希求进行可行性分析，如果客户提出的需求不合理则应该充分了解客户为什么会提出这项需求，客户究竟想要实现什么功能，充分了解客户，充分理解需求，制定出替代的方案，然后跟客户进行协商，以达到客户的满意和自己项目的正常进行。

迭代：

在从客户那里得到需求后，我们应该分析用户的每一项需求，对需求进行分析，绘制类图和对象图等，详细地进行设计分析，然后不断地与客户进行交流，细化需求，进行迭代开发，每次多理解一点，最终使软件更接近用户的满意。

需求捕获：

从客户那里得到需求是需求分析的关键，如何从客户那里捕获需求，捕获的需求是否明确非常重要，我们应主动地从客户那里捕获需求，不能被动地捕获，这样可以有效地分析客户业务的详细流程，了解由谁来操作，并了解为什么要这样操作，深入地了解这些领域和知识，另外因为我们对客户的业务不熟悉，我们要主动地对客户进行询问，深入明确地了解用户的需求和业务流程。大多数客户对于软件开发并不专业，所以很有可能会遗漏一些东西，需求人员应该深入分析客户的需求，提出客户遗漏的东西，使需求更接近与客户真正的需求。

 

二、需求分析

功能角色分析与用例图

我们应根据需求分析角色，分析出各个角色的功能，绘制用例图，其中包括参与者、用例与系统边界。用例图是提供给客户看的，所以不应该出现技术性较强的表达方式，应该用客户易懂的词语进行功能描述，从而让客户了解我们了解到的需求，并提出修改意见。

业务流程分析

应根据需求对业务流程进行分析，分清系统外和系统内，将需要信息化管理的部分进行开发，不需要信息化管理的部分则不开发，使软件真正地实现提高工作效率，而不是加重负担。

用例说明

在进行业务流程分析时绘制用例图能够生动形象地描述我们的分析，但是其会丢失很多信息，所以我们需要有一些文字的描述，就是用例说明。

查询报表分析

我们应根据需求实际设计不同的查询报表，报表的内容应符合客户的需求，对必须的内容要加上，不需要的可以删掉。

子用例与扩展用例

在基本流程中将多个用例所共有的，可以相互共享的流程，将这些流程提取出来就是子用例，这样提取公共部分提高了系统的内聚降低了系统的耦合。

行动图和状态图

用例图只是描述了某一个用例自己的功能，而各个功能很分散，没有联系，所以需要行动图和状态图来将各个模块组织起来，来对业务进行整体的描述。状态图描述了业务流程状态的转换，可以清晰地展现各个业务流程。

业务领域分析

业务领域分析就是通过与该业务领域的专家进行学习，了解该领域的一些基础知识，然后构建该领域的知识体系，了解该领域需要什么实体，并可以对业务流程更加熟悉，有助于在项目开发中进行参考，从而提高项目的正确性和提高项目的开发效率。

原文分析法

原文分析就是分析需求的原文，提取出业务领域的名词，对名词进行分析提取出业务领域的实体。

非功能需求

非功能需求包括可用性、可靠性、性能、可支持性以及其他，非功能需求时需求人员非常容易忽略的，但是确实对软件开发非常重要的，某一方面考虑不周全，可能会导致软件的失败，例如界面不友好，性能差，支持性差等都会导致客户不想使用导致软件开发的失败。

 

三、需求确认

通过对客户的需求进行分析，以业务人员的角度进行总结，列出需求列表。并用快速原型法进行需求确认。以供每一步的开发人员进行参考，防止出现不符合需求的因素。最后书写自己的需求说明书，本着实事求是、切实可行的态度去描述用户的业务需求。

思维导图：