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

阅读笔记如下：

 

       新的学期又开始了，所以新的目标要被确定了，今年又加入了考研的队伍，所以一定加油！！

近年来，软件业发展突飞猛进，但一个软件项目要做好的前提还是软件需求分析，从作者分享的故事中我总结了以下几点：

（1）要对客户的需求进行深入的了解，而并非一味地被客户牵着鼻子走，从业务角度深入进行分析，有没有更好的方案对客户需求进行改进，使变更变得更加可控。

（2）作为技术人员，需求分析必须实事求是、基于技术可以实现的角度去考虑、去引导客户的需求，而非一味地鲁莽行事。做需求应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步步引导他们按照更加合理的方式去操作与管理。

（3）在集团类似大型的建设项目进行需求分析时，一定认真分析清楚所有类型人员的需求。一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。

（4）需求分析不是一蹴而就的，他应当贯穿整个开发周期，不断的分析确认过程，即敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。

 

有关于需求分析，我们需要掌握的内容有以下几方面：

（1）需求调研：包括与用户的初识、交流、以便建立良好的关系，研讨会的展开对原始需求调研的作用，并且通过迭代的方式进行需求的完善，需求的捕获。

（2）需求分析：分析用例、分析业务流程、构建用例说明、其他例如查询功能的分析、子用例及扩展用例的分析、行动图和状态图、业务领域分析、原文分析、非功能需求分析。

（3）需求确认：列出需求列表、利用快速原型法得到用户的确认，构建需求规格说明书。

 

关于我们应当怎样做需求调研，作者给我们提供了尤为深刻的见解。

（1）初识：初见时应该树立良好的职业威信，正如人与人之间的交往，如果你对其一直唯唯诺诺，不仅不会让对方感受到你的个性、你的观点，还会给人一种可以变相提条件的感觉。更重要的是，对之后的项目工作的开展尤其不利，一味地服从，只会使得自己做的很累，客户也不会满意。相反，我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。

此外，特别是在管理型项目中，要分为不同的角色对其进行项目需求的调研，不同的部门，业务不同，需求也就不同。只有真正了解了各方需求时，才能对项目有尽可能完善的目标与方案。

（2）拜访：需求调研不是一蹴而就的事情，而是一件持续数月甚至数年的工作，在这期间，只有依靠客户的支持与帮助，一步步掌握真实的客户需求。此外，建立良好的客户关系，也是一个必经之路。

（3）研讨会：业务研讨会是非常重要的，项目经理需要根据实际情况，将项目负责人以及客户代表聚在研讨会上可以详细地对项目进行需求分析，将各个部门的客户需求统一化，避免之后的需求不一致，不易维护；另一方面可以将各个部门的需求进行分析，取长补短，以便后期的工作及业务的开展。

（4）需求研讨：在进行需求研讨的时候，首先探讨的不是软件功能，而是客户现有的业务知识，之后对客户为什么要提出这项需求的目的，在理解客户真实意图以后，能够提出比客户更优的解决方案。通过大量的业务分析与技术可行性分析基础上的分析活动，确保需求的正确与变量的可控。

（5）迭代：在需求分析阶段，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••过程中需要绘制类图，用例图，细化用例图，建立用例场景，此外，还要及时与客户进行反馈，多理解一点，逐渐深入，软件就会更加接近客户的满意。

 

需求分析，需要掌握的内容如下。

（1）功能角色分析与用例图：需求分析不应当是太公钓鱼，而应当是拉网排查。任何一个疏忽都可能对项目研发带来风险。需求分析是一个长期的过程，由粗及细。从功能角色分析开始（采用绘制用例图），辅之以我们对图形的描述。

（2）业务流程分析：首先，对流程进行梳理，在对原始需求分析的基础上，分析我们的软件能做什么事。应根据需求对业务流程进行分析，分清系统外和系统内，将需要信息化管理的部分进行开发，不需要信息化管理的部分则不开发，使软件真正地实现提高工作效率，而不是加重负担。

（3）用例说明：进行业务流程分析时，编写用例说明是最主要的工作，之后进行查询报表的分析。

（4）查询报表分析：报表作用体现的是报表对于不同用户的真实意图

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

（6）行动图和状态图：用例图只是描述了某一个用例自己的功能，而各个功能很分散，没有联系，所以需要行动图和状态图来将各个模块组织起来，来对业务进行整体的描述，对关键对象中流程中状态变化的描述。

（7）业务领域分析：进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。

（8）原文分析法：在用例说明与流程分析的基础上进行的业务领域分析，是一项在需求研讨会后整理和分析需求的工作。

（9）领域驱动设计：领域驱动设计（在我的理解）就是客户与你之间形成一种统一语言，这种语言有助于两者之间的交流。

（10）非功能需求：非功能需求很重要却常常被忽略，我们在进行非功能需求的分析时，除了制订整体的原则以外，还要落实到各个具体的功能中，将这些功能所潜在的、特殊的非功能需求挖掘出来，提前进行分析设计，对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险。

 

需求确认：收集需求的条列，对其进行分类，绘图，评审需求的确认。需求确认是一系列的确认过程，每次确认都可能需要与不同的人，在不同层次的确认。最终应当形成到纸面，形成文档性的东西，双方签字确认。它包括需求列表；快速原型法来构建出一个实物，不断进行改进；制定需求规格说明书和评审与签字确认会。