《我们应当怎样做需求分析》一文写到了三个关键部分：需求调研、需求分析、需求确认。
在文章的开始作者为我们介绍了三个案例来说明一些情况，从东软的事例到自身的事例都说明了软件的需求部分是多么的重要。东软的事件告诉我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。所以抱怨那么多似乎也是无济于事的。作者自己本身的第一个案例向我们说明我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。不要去盲目的进行操作。作者的本身的第二个案例还说明了真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。专家是一个领域的佼佼者，他们可以让我们走更少的弯路。
作者向我们介绍如何做需求分析：
需求调研：
1.初识：要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。让我们分的清自己所处的位置，不要盲目去想一些东西。还有与客户的交流沟通讨论项目目标，既重要又适时。这是完成一个成功软件的开头之笔。
2.拜访;经过一番交往，我们将逐渐在客户中结识一批可以帮助我们的人。今后一段日子里，我们将依靠他们去学习和认识业务知识，收集业务需求，为日后的软件研发提供素材。这是做软件需求部分一个十分重要的环节。
3.研讨会：业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
4.需求研讨：需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
5.迭代：需求分析不是一蹴而就的，是一个反复迭代的过程。需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
6。需求捕获：需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分
需求分析：
1.功能角色分析与用例图：功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。用例图的使用一定要符合实际情况，如果是一个错误的用例图可能会造成更多的麻烦。我们绘制的用例图应当能够为用户所理解，这也是UML其中的一项核心思想——与客户形成统一的、能够相互理解的语言。
2.业务流程分析：清除低效环节-----简化业务瓶颈-----整合可用资源-----自动化繁重操作
3.用例说明：参与者：用例图中该用例的参与者，通常是业务操作的触发者和施与对象（如外部系统）。
触发事件：谁干了什么，触发了这个用例。
前置条件：在触发该用例相关操作前必须达到的条件。
事件流：这是用例说明中最重要的部分，它详细描述了该用例可能出现的所有流程。
这些部分是非常必要的体现。
4.查询报表分析：输出列、使用频率、数据链接。一个有效的报表，往往不是对数字的简单堆砌，它通过一组一组的数据，揭示的都是一些客观规律、复杂活动与发展趋势。报表的数据项应当都是来源与系统中各项操作的结果数据。另外，用户使用报表的频率，常常决定了报表设计的方式。最后，一个报表的核心就是展现给客户的报表格式，以及报表与报表间的各种链接。
5.子用例与扩展用例：用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。
6.行动图和状态图：行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。状态图描述了业务流程状态的转换，可以清晰地展现各个业务流程。
7.业务领域分析：进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。日后我们去设计开发系统时，应当设计哪些类，类中都应当有什么属性和行为，以及怎样去设计数据库，都是以这个领域模型为基础的，虽然有时并不完全与领域模型完全一致。
8.原文分析法：有了原文分析方法，给了我们一个简单可行、易于操作的方法，让我们准确而高效地完成业务领域分析。
9.领域驱动设计：需求人员在开始一个新的管理系统的分析工作时，都有可能面临着一个全新的业务领域。对领域模型的认识被延伸到了整个软件生命周期中，包括之后一次一次的升级完善。你每认识深入一点儿，就可能会体现到你的分析设计中，并最终体现在开发的软件中。
10.非功能需求：简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。
需求确认
需求列表：它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。需求列表也不是一步到位的，而是经过由粗到细逐渐整理形成的。同时，需求列表也是一个不断变化的过程，日后的每一次升级维护都需要不断增添和修改需求列表，使其与实际系统保持一致。另外的部分是最终部分的一些实例，这些是我们的参考文件。
关联关系：
