《我们应当怎样做需求分析》读书笔记
《我们应当怎样做需求分析》这篇博客的作者以自己的经验和教训告诉我们怎样解决项目中的需求问题。要解决需求问题，就要从需求调研、需求分析、需求确认三个方面进行，同时这也是《软件需求与分析》这门课必须要掌握的内容。
一、需求调研
我们应当怎样做需求调研？初识——第一次需求调研对我们至关重要，这考验我们与人交往、沟通的能力，是一门技术活。虽然顾客是上帝，但是我们不能对顾客唯唯诺诺，我们要展现出一位技术专家的姿态，大方提出自己的意见，运用专业知识，提出比客户原始需求更加合理的方案，使客户更加重视我们的意见；就是“拜访各种各样的客户”，分析其中的利弊关系，结识一批可以帮助到我们的人，然后依靠他们去学习和认识业务知识，收集业务需求，为以后软件研发提供素材；但是即使我们找到了一批可以解答我们业务问题的一批人，怎样合适的与客户展开业务研讨任务，也是一道难题，一种较好的形式是开展集中式的业务研讨会，根据业务需求将客户们分组，通过各抒己见和辩论每个部分形成统一的版本，虽然也会因为地区差异出现多个版本，至少我们能容易清楚有几种情况，有没有使差异最小化的可能。集中式的研讨会虽然好处较多，但是并不适用于所有情况，如果很难将各地的业务代表集中到一起，那么可以采用分散式的业务研讨形式，无论哪种研讨会，都要注意有效抑制个性化差异和分模块组织专项研讨会两点；然后，我们需要进行需求研讨，学习相关领域知识，在理解用户意图之后，提出比客户更优的解决方案，对于一些无法实现的需求，耐心解说，并给他提出一个更加合理的解决方案；最后，因为需求分析不是一种简单的你说我记的手机活动，而是在大量业务分析和技术可行性分析基础上的分析活动，需求分析是一个迭代过程，不断重复需求捕获->需求整理->需求验证这个过程。
二、需求分析
我们应当怎样做需求分析？功能分析与用例图，从一个外部用户的视角分析整个软件系统能够提供的功能，以及这些功能到底是提供给那些角色使用，对一个系统进行功能和角色方面的梳理和分析，可以采用比较主流的方法之一就是绘制用例图，用例图描述的是熊到底为用户提供了哪些功能，是沟通用户和技术人员的桥梁；业务流程分析，分析业务流程中那些需要信息化管理，那些则不需要，还要分析流程差异化，不同的单位有不同的情况；用例说明我们进行流程分析的时候，必须要落到纸上，现在我们需要绘制行动、状态图，以及来编写用例说明来完成这部分工作；查询报表分析，虽然用例模式对大多数业务操作流程来说是得心应手的，但是对于查询、汇总与报表功能需要的不是什么操作流程，更重要的是那些数据项、数据来源、报表格式、数据连接，那么我们就要分析报表；子用例与拓展用例，用例分析中对子用例和拓展用例的分析，使对我们对系统的设计，从一开始就将公共、可共享的部分提取出来，提高了系统的内聚并降低了系统的耦合，是一个优秀软件的开始；行动图和状态图，对行动和某个对象的状态进行分析；业务领域分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及去组成一个个业务操作，软件系统就是对现实世界的模拟，我们进行业务分析就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们日后的开发过程；领域驱动设计，我们在开始一个新的管理系统的分析工作时，都要面临一个全新的业务领域，我们需要时间去学习领域知识，但是并不意味着去学习所有的知识领域，而是与软件相关的领域知识，我们对领域知识认识再深入一点，软件就再完善一分；非功能需求分析，其实需求分析人员最容易忽略的部分就是非功能需求，非功能需求更加靠近的是技术，是设计，是实现，是架构师关注的内容。
三、需求确认
我们在需求调研和需求分析之后，需要进行需求确认。我们在和老板沟通确认需求的时候，可能会直接交代一大堆任务，但是一次简单的口述不足以满足需求分析的过程，每次确认可能都要与不同的人进行，不同层次确认，我们最好是形成需求列表和需求规格说明书。需求列表又称之为需求跟踪表，是最原始的。用户对业务需求的描述；快速原型法，我们要在需求分析阶段拿出实物，用实物与客户进行需求确认；需求规格说明书，用户编写的原始需求，脱离技术实现，理想和现实总有差距，所以我们要编写需求规格说明书。那么最后就是评审和签字确认。
通过阅读《我们需要怎样做需求分析》，我发现需求分析是一个复杂的过程，与我之前想象的大相径庭，需求分析是一个充满智慧和技术的事情，我们学习软件需求与分析这门课，要付出更多的努力。
