《我们应当怎样做分析》阅读感受

作为一名软件工程专业的学生，软件需求与分析这门课是我们做软件的基本。针对这门课，我阅读了《我们应当怎样做需求分析》这篇文章，在此写下一些怎样做需求分析的感受。

需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。需求不是被客户牵着走，而是和客户去商量，我们必须要基于技术实现去引导客户的需求。需求是各自不同，需求分析的时候认真分析清楚所有类型人员的需求，需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。应当不停地用开发的成果与客户交流，及时获得反馈。

文章中需求分析分为了三个阶段：需求调研、需求分析、需求确认。

需求调研：初识、拜访、需求调研、迭代、需求捕获。

初识是需求调研的开始，需要我们具有理解能力、设计能力，还需要我们具有一种与人交、沟通的能力。不能一味的听从客户的要求，应当理解客户的需求之后，运用我们的专业知识，提出更加合理、可操作的解决方案。而在交往之中，我们要足够的自信，还要有循循善诱的表达能力，这样我们才能合理、正确的来向客户表达我们项目的正确方向。文章中的“在这里我给大家的三点建议：1）树立良好的职业威信；2）进行详细角色分析，将与会各方代表对号入座；3）从宏观上制订目标与方案。”是一个很好的方式。

拜访如同人与人的相识。首先留下一个好印象，之后与各种角色、各个类型的客户建立了联系。下面，我们将一个一个去拜访他们，展开我们的需求调研。需求调研也是一个培养感情的事情，而不是一蹴而就的。依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求。软件项目已经不是一锤子的买卖，而是长期的、持续不断的提供服务。需要我们与客户建立长期友好的关系。

需求研讨是需求调研的重要阶段，是我们了解客户需求的真正阶段。需求研讨的时候，首先跟客户探讨的不是软件功能，而是客户现有的业务知识，用专业的话叫“业务领域分析”。我们应当分析他们提出的所有原始需求，去了解客户的需求。做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。正如老师经常举的例子，要分析哪个领域的哪些需求，才是真正的去完成一个软件。

迭代是需求反复的过程。一遍又一遍的理解需求，需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。

需求捕获。采用主动态度去捕获需求，需求分析的整个过程，不断进行业务领域知识的学习。

需求分析：功能角色分析与用例图、业务流程分析、用例说明、查询报表分析、子用例与扩展用例、行动图和状态图、原文分析法、领域驱动设计。

功能角色分析与用例图。。需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。采用一套成熟而完整的分析方法，稳步而有序地完成这部分工作。对一个系统进行功能和角色方面的梳理和分析，可以采用的比较主流的方法之一就是绘制用例图。

业务流程分析。将客户调研的需求进行分析，进行功能分块。我们一定要沉下气来认真仔细地做需求分析，细化需求也需要一定的方法与思路。有两个方向细化需求：业务流程分析与业务领域分析。

用例说明。是一个面向过程的分析过程。对用例图进行文字描述。在每一个用例说明的后面与该用例相关的需求列表，便于需求跟踪。将需求列表附在用例后面，便于日后的需求评审与确认。当每次需要升级时，则添加上新的需求，或对以往的需求进行更新。

查询报表分析。报表分析能让程序员更加清楚的看到软件项目的分类，各个需求、文档等。查询报表的需求分析与一般的业务操作的需求分析存在着巨大的差异。一个有效的报表，往往不是对数字的简单堆砌，它通过一组一组的数据，揭示的都是一些客观规律、复杂活动与发展趋势。

子用例与扩展用例。用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。

行动图和状态图。是用例分析的一个流动状态。

业务领域分析。软件系统，毫不夸张地说，就是对现实世界的真实模拟。它与各个世界中的事物相互关联，正是面向对象编程的核心思想。我们进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。我们去设计开发系统时，都是以这个领域模型为基础的，虽然有时并不完全与领域模型完全一致。过去，没有一个切实可行的方法来指导我们的业务领域分析，而现在，我们可以通过两种分析方法一步步进行：原文分析法与领域驱动设计。随后，我们将就这两种方式进行详细分析。

原文分析法。原文分析法（Textual Analysis），是在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。原文分析中的名词可以更加深入的分析系统中的某个功能。系统之内的事物转化到领域模型中，成为实体与实体中的属性。

领域驱动设计。首先客户描述着他们的需求，随着需求分析的不断深入，我们发现问题了。并最终体现在开发的软件中。你对领域知识认识再深入一点儿，软件就再完善一分。

非功能需求。寻找适合自己的，避免做过度分析和设计，这种思想也是敏捷开发的精髓。需求分析是一个撒大网的过程。对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险。

需求确认：需求列表、一个需求列表的实例、快速原型法、需求规格说明书。

需求列表。因为人与人的沟通最大的问题就是失真，复述的步骤就是需求确认。需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。

快速原型法。要快速开发，必然不可能和最终交付的软件系统一模一样，许多复杂问题被简化，非关键性流程被忽略，这就是所谓的模拟。因此，模拟到什么程度是关键，既能说明问题，又不耽误时间。一般能拿出界面，并可以走通关键性流程就可以了。一些快速开发平台为快速原型法提供了可能。当用户拿到原型可以自己操作时，需求研讨的气氛立即变得不太一样了。当用户享受原型给他们带来体验的快感时，需求被源源不断地被提出来。既然是原型，必要的校验、非正常操作的处理通通都被忽略。因此，当演示原型出错时，用户你可千万不要较真！

需求规格说明书。这是我们软件工程的特点，也是展现用户原始需求的重要文档。

外部需求评审会。就是与用户就需求规格说明书进行评审，最后签字确认。

经过以上的流程步骤，一个完整的需求分析才能完成。