这篇博客的作者开篇这样写道：幸福的家庭都是一样的，不幸的家庭却各有各的不幸；幸福的软件项目都是一样的，不幸的软件项目却各有各的不幸；或者说，成功的软件项目都是一样的，失败的项目却各有各的问题。软件的失败原因千奇百怪，但说到根本，问题还是出在软件需求和分析上。
从我们的角度来说，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，这些文档又详细地说明了产品“必须或应当”做什么。
其实，开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。这项工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。因此，需求分析就是在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。
由此可见，需求与分析的正确性与一个软件项目是否能成功息息相关。我们要充分了解客户的需求是否可行，如果把开发当做“有条件要上，没有条件创造条件也要上”的鲁莽之事，那么结果必然是十分悲惨的。
在文中讲解的一步步的需求调研中，我对每一步的关键点，理解如下：
1、初识：我们对客户提出的需求进行深入理解以后，应该运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案。这就保证了我们在与客户的初步交涉中，占有了一定主动权，更容易调整客户的预期，使客户描述软件的可行性更强。
再者，在与领导商议的会议时，要记住树立良好的职业威信，进行详细角色分析，将与会各方代表对号入座，以及从宏观上制订目标与方案。
2、拜访：经过一番交往，我们将逐渐在客户中结识一批可以帮助我们的人。而今后一段日子里，我们将依靠他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。
3、研讨会：业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。但恰恰它是重要的，为了有效抑制个性化差异并且分模块组织专项研讨会。
4、需求研讨：它不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
5、迭代：每开发完一个迭代周期，将开发的成果与客户反馈。这样做，是为了让客户可以及时地提出我们对需求理解的偏差，或者及时提出对我们设计不满意的地方，使我们存在的问题得到及时地发现与解决。问题及时的解决，使我们修复问题的代价得以降至最小。
6、需求捕获：从需求列表到产品需求说明书，这之间要经过一段长长的路，这段路就是我们的分析与设计，而不是简单的记录与编写文档。只有经过这样的过程，最后得到的才是高质量的需求分析，才能有效地指导软件研发，避免项目的风险。
7、功能角色分析与用例图：这就到了软件开发的UML阶段。功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。
8、业务流程分析：ERP对企业流程改进，清除低效环节，简化业务瓶颈，整合可用资源，自动化繁重操作。
9、用例说明：由于不同的人对用例的理解不同，格式也不尽相同，但一些基本的元素是一样的。每次需要升级时，则添加上新的需求，或对以往的需求进行更新。
10、查询报表分析：一个报表的核心就是展现给客户的报表格式，以及报表与报表间的各种链接。需求人员在进行需求分析阶段，应当准确地与客户敲定这些格式，并最终在用例说明中体现出来。报表格式是否体现客户的意图，报表数据项是否都能在系统中取到，数据间的逻辑关系是否正确，报表格式是否技术可行，都是需求分析人员在前期就必须要分析到位的内容。
11、子用例与扩展用例：用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。
12、行动图和状态图。
13、业务领域分析。
14、领域驱动设计：需求人员在开始一个新的管理系统的分析工作时，都有可能面临着一个全新的业务领域。每认识深入一点儿，就可能会体现到我们的分析设计中，并最终体现在开发的软件中。我们对领域知识认识越深，软件就再完善一分。
15、需求列表：需求列表中应当剔除那些客户对系统设计的内容。
除这些外，软件需求规格说明书、评审与签字确认会也是很重要的。
在需求的问题上，这篇博客给出了几个实例来讲解，我大概学到以下几点，这或许就是王建民老师让我们阅读这篇博客的关键所在。
我们当前软件需求与分析所要掌握的必要内容：
1、当客户提出业务变更的时候，一定不能被客户牵着走，不要觉得客户说啥就是啥。毕竟在软件开发上，我们才是专业的，要从业务角度深入的去分析，他为什么提出变更，提得是否合理，以及我们有没有更合理的方案满足这个需求。相信当我们提出更加合理的方案时，客户必然是乐于接受的，那么变更也变得可控了。
2、客户提出的原始需求往往是不考虑技术实现，基于非计算机管理的操作模式提出来的，毕竟人家是非技术的，他们提出的很多需求常常比较理想而不切实际这也情有可原。我们必须要基于技术实现去引导客户的需求。做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。
3、一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。需求调研的初期需要召开项目动员大会，这是十分必要的。真正要完成需求分析，应该分成细化的小会，只讨论某个领域的业务需求。
很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。
4、敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。
对于一个失败的项目来说，它们有的是需求的问题，有的是客户关系的问题，还有设计的问题、技术的问题、时间管理的问题、人员培养的问题。但归根到底，更多的却还是需求的问题。需求分析既是人际交往的艺术，还是逻辑分析与严密思考的产物。正是我们在需求分析过程存在的巨大隐患，最终导致了那么多项目的失败。
要做到好的需求结果，我认为需要，大胆和用户沟通。不要怕说错、有不懂业务问题的一定要问用户，不要怕打扰别人了，再者多写各类软件文档不要怕麻烦，多百度一下很多问题能解决，多推敲在用户需求上能否在扩展更有用的东西。