今天阅读了建民老师课件上提供的关于如何做需求分析的博文，下面把这篇博文的
一些重点总结一下。
需求分析既是一份体力活儿，更是一份技术活儿，它既是人际交往的艺术，又是逻辑分析与严密思考的产物。
作者给我们提出了几个例子
第一个故事讲的是发生在东软的事情，由于对客户的需求了解不够透彻最终导致了
整个这个项目组的所有成员都离开了东软，这就是不了解客户的需求。
深入地去理解客户的业务，进而想到客户的心坎儿上去，最后做出来的东西必然是客户满意的。
当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，
他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。
当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
第二个故事告诉我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，
最后一步一步地去引导他们按照更加合理的方式去操作与管理。
客户提出的要求是根据他们心中的理想但是他们并不是技术人员，所以他们没有考虑到需求分析必须实事求是的、基于技术可以实现的角度去考虑。
需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。
本学期软件需求与分析应该掌握需求调研、需求分析、需求确认，需求调研是需求分析最重要的一环，也最集中地体现了需求分析的特点——既是一份体力活儿，
更是一份技术活儿。它既要求我们具有一种理解能力、设计能力，更要求我们具有一种与人交往、沟通的能力。
我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。
业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获••••••
需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。
企业信息化管理实质就是一次改革，是企业摒弃手工操作，向信息化建设迈进的一次改革。既然是改革，就必须要改变过去不合理的管理流程，向更加合理和高效的管理流程迈进。因此，我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。如果需求人员能上到这样一个高度，我们的需求分析就进入了一个更加崭新的层面。
需求分析：功能角色分析与用例图、业务流程分析、用例说明、查询报表分析、子用例与扩展用例、行动图与状态图、业务领域分析、原文分析法、领域驱动设计、
非功能需求。
需求确认：需求列表、一个需求列表的实例、快速原型法、需求规格说明书、评审与签字确认会。
