《我们应当怎样做需求分析》阅读笔记

     

     作者在第一段说“需求分析既是一份体力活儿，更是一份技术活儿，它是人际交往的艺术，又是逻辑分析与严密思考的产物。”然后作者讲述了几个故事来说明了需求分析。他的第一个故事讲了东软的一个项目过程中客户不停地修改需求，最后以致于项目组的员工都离开了东软，究其原因是他们只听到了客户表面上的需求说辞，没有去站在用户的角度理解客户心里真正想要的是什么。正确的做法应是在用户更改需求时我们去提出更加合理的方案去满足用户的需求。第二个故事是说在作者的一个早期项目中，客户向他们提出了许多非常理想的但是技术上难以实现的需求，最后作者想尽方法去实现但最后还是失败了。而面对这样的用户需求时，我们应该去在现有的技术的基础之上引导客户的需求，摒弃过去的手工管理模式，换成现有的信息管理模式。第三个故事是讲作者参与的一个集团信息化建设的项目。该项目中的客户有很多角色，不同的角色有不同的需求，但是作者在做需求分析时没有认真分析所有的角色需求，所以在项目上线后，系统根本用不了。一个软件项目的需求调研应该必须进行角色分析，然后面对不同角色分别调研。然后分别与领域内的专家沟通一个领域一个领域的做业务需求。第四个故事是讲在项目的后期讲项目交给客户看时客户提出了许多需改，然后赶时间修改项目，但项目上线后发现了许多BUG。这个故事告诉我们需求分析不是一开始就做好然后再不用管它的，而是贯穿整个项目。所以我们在项目开发时应在发布之前不停地将项目交给客户与客户沟通，然后根据客户的满意度继续做需求分析。

    很多需求分许的工作是从需求调研开始的，然后作者给我们介绍了几种需求调研的方法：初始，拜访，研讨会，需求研讨，迭代，需求捕获。在与客户初识时，我们应该在客户提出需求后提出更加专业，更加合理可操作性的解决方案，真正理解客户内心想要的东西。而不是讨好客户，唯唯诺诺，让客户提出非常理想却不能实现的需求。除此之外，当我们面对许多角色时，我们应该向不同的部门寻求不同的需求。与高层讨论宏观的目标，与中层讨论功能的定义，业务流转的衔接，查询报表的设计等，与基层的领域内专家讨论软件的细节。在与客户认识后应该经常拜访客户，与客户建立良好的关系。在随后的客户交流中去得到对软件的帮助。当软件存在个性化的问题时，通常会集聚不同的业务需求的客户分成若干个业务组，在客户最熟悉的领域内讨论需求。当客户不能集聚在一起时，就需要我们开需求研讨会。在与客户进行需求研讨时，应该了解客户的现有的业务知识，然后再去分析客户提出的原始需求，深刻地理解需求。并且我们应该反复与客户讨论需求。然后做出成品给客户看，再与饿虎讨论需求.....。

     在捕获需求后，我们需要做需求分析。作者给我们介绍了几种需求分析方法：功能角色分析与用例图，业务流程分析，用例说明，查询报表分析，子用例与扩展用例，行动图与状态图，业务领域分析，原文分析法，领域驱动设计，非功能需求。大部分都在我们上学期的UML建模语言课上都学习过。

    当我们捕获到需求后，为了我们得到的需求与客户心中的需求相同，所以我们需要向客户再确认一次，这就是需求确认。作者给我们介绍了几种需求确认的方法：需求列表，一个需求列表的实例，快速原型法，需求规格说明书，评审与签字确认会。需求列表不掺杂我们对业务需求的任何分析与设计和客户对系统设计的内容。项目过程中每一次升级维护都不断增添和修改需求求列表。而需求列表是经过初次与评审人员的业务讨论以后而得出。有了需求列表，需求分析后，每项都检查是否满足用户需求。快速原型法就是在需求分析阶段拿出实物，用实物与客户确认需求。需求规格说明书的重要作用是摒弃不可行的需求或者换成更加可行的解决方案。当做出需求列表与需求规格说明书后，最后一项就是需求评审会。

    最后，我通过阅读这篇文章，整理出了学习软件需求的知识点。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

转载于:https://www.cnblogs.com/wl2017/p/8519699.html