我们应该怎样做需求分析——读后感

在阅读《我们应当怎样做需求分析》这篇博客之后，印象最深的就是博主所说的令人印象深刻难以忘怀的一个个软件项目，有的获得了成功，而有的走向了失败。导致这些失败的原因，值得我们深思。作为软件工程专业的学生，进入社会，进入岗位，需要的就是对于一个项目的了解，并且清楚客户的需求，并且能顺利将需求进行合理的分析，从而使项目走向成功。

那么我们应该怎样去做呢，前辈在博文中给了我们很好的建议：

（一 需求调研）

一：初识

很多需求分析的工作是从需求调研开始的，需求调研是需求分析最重要的一环，要求我们既要有理解能力，设计能力，又要有与人交往，沟通的能力。对于客户提出的需求要从技术人员的角度去看待，给出客户更加合理，可操作性的解决方案；另外不同的层次有不同角色上的需求，划分清楚角色，弄清楚每个角色的需求提出者与决策者；从宏观上制定目标与方案，随后的工作，就是与各方代码建立联系，逐一拜访他们，将需求调研工作一步一步进行下去。

二：拜访

需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作，我们需要依靠客户这个群体的帮助，从而掌握真实可靠的业务需求，更加需要我们有良好的客户关系，还要能够分析一个客户人群的关系，分析这个人群中，谁支持这个项目，谁在阻碍这个项目，谁能与我们结为盟友，荣辱与共，都是需要我们去掌握的，去交往的东西

三：研讨会

业务研讨会是重要的，同时也是灵活的，面对不同的管理模式，不同形式的多组织机构，众说纷纭的需求，我们要根据实际情况，合理的与客户组织研讨会，有限抑制个性化差异，分模块组织专项研讨会。

四：需求研讨

讨论业务需求是需求分析人员的功底，在做需求研讨时，我们需要的不是一些过于具体的业务需求，甚至是所谓的最佳设计方案，首先应该跟客户探讨的是现有的业务知识，即“业务领域分析”，不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中，而不是成为一个专家。只有建立在大量业务分析与技术可行性分析基础上的分析活动，才能保证需求的正确与变更的可控。

五：迭代

需求不是一蹴而就，而是一个反复迭代的过程，通过一次次验证，每次多理解一些，更多了解一些，每深入一步，我们的软件就更接近客户的满意。

六：需求捕获

需求捕获是整个需求分析工作中的最重要的部分，需求捕获是比较薄弱的环节，在需求捕获的过程中，最根本的问题是一个态度的问题，是主动还是被动，我们更多的要发倔，客户没有说出，或者没有想到的需求，一个需求分析人员只有熟悉了业务操作的流程，站在客户的角度去思考问题，进而深入的了解客户所提出的业务需求，达到这样的水平才能做出完整，准确的分析

（二 需求分析）

一：功能角色分析与用例图

需求分析是一个由粗到细的过程，首先要从功能角色进行分析，对系统宏观的，整体的需求分析，并且还需要在它的基础上进行更详尽的分析

二：业务流程分析

在整个系统的整体脉络与轮廓已经被勾画出来，我们仍然需要为客户进行分模块的用例图设计，进行分为两个方向的需求细化，分别是业务流程分析与业务领域分析

三：用例说明

当我们进行业务流程分析时，不能空对空，必须要落实，在画用例图时，最重要的则是事件流，基本流程描述是应该是该用例中最佳的，最正常的方式流转

四：查询报表分析

一个有效的报表，并不是对数字的简单堆砌，它通过一组一组的数据，揭示的都是一些客观规律、复杂活动与发展趋势，需求人员在进行需求分析阶段，应当准确的与客户敲定这些格式，并最终在用例说明中体现出来

五:子用例与扩展用例

六：行动图和状态图

针对用例图缺乏生动形象的图形表示，行动图与状态图可以有效的弥补用例图的缺陷，使我们对系统设计的流程更加清晰

七：业务领域分析

对系统进行静态分析，通过与客户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程

需求分析的方法还有原文分析法，领域驱动设计，非功能需求，通过这些才能将软件开发过程化繁为简，称为敏捷开发的精髓

（三 需求确认）

需求列表，一个需求列表的实例有了需求列表的内容，我们才能一项项的检查我们是否满足用户的需求，快速原型法能够确保与用户流畅的确认需求，面对状况不断，令人崩溃的研发过程，需求规格说明书显得尤为重要，本着实事求是的态度去描述客户的需求，最后经过一系列需求研讨，需求分析和整理确认，我们整理出了需求列表，最后的里程碑就是需求评审会了，确认需求，从而开始设计开发工作。

 思维导图：