第一个故事的收获：
当客户提出业务变更的时候，我们一定不能被客户牵着走，客户说啥就是啥。我们要从业务角度深入的去分析，他为什么提出变更，提得合不合理，我有没有更合理的方案满足这个需求。当我们提出更加合理的方案时，客户是乐于接受的，变更也变得可控了。
第二个故事的收获：
我们作为技术人员，需求分析必须实事求是的、基于技术可以实现的角度去考虑。那种“有条件要上，没有条件创造条件也要上”的鲁莽行事，结果必然是悲惨的。所以我们必须要基于技术实现去引导客户的需求。同时，计算机信息化管理就是一次改革，对以往手工管理模式的改革。如果我们上了信息化管理系统，采用的管理模式却依然是过去的手工模式，新系统的优势从何而来呢？因此，我们做需求就应当首先理解现有的管理模式，然后站在信息化管理的角度去审视他们的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。
第三个故事的收获：
一个软件项目的需求调研首先必须要进行角色分析，然后对不同的角色分别进行调研。需求调研的初期需要召开项目动员大会，这是十分必要的。但真正要完成需求分析，应该是一个一个的小会，1~3个业务专家，只讨论某个领域的业务需求，并且很多问题都不是能一蹴而就完成的，我们必须与专家建立联系，反复沟通后完成。需求分析必须遵从的是一定的科学方法，而不是盲目的大上快上。
最后一个故事的收获：
敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。
需求调研的初识阶段：
适当的谦卑，但不要过分谦卑，过于的谦卑，处处都是诺诺诺，客户说什么就是什么，就会使客户变得非常强势。这样的结果就是，客户提出了许多变态的、不太现实的、不合理的需求，而我们呢却是一味地服从，客户说什么就是什么。最后我们做得很累，结果却不能让客户满意。正确的做法是，我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。
了解客户的角色，谁是提出者，谁是决策者，由于业务的不同，对软件的需求自然是不同的，因此我们在进行需求调研的时候，什么部门的需求就应当跟什么部门谈。
1. 高层领导：高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，都应当与高层领导谈。他们关系的都是宏观的问题，因此不要与他们谈那些细枝末节；
2. 中层领导：中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节；
3. 基层人员：基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。另外，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。而他们关心的则是每项操作的细节。
需求调研的拜访阶段：
分析一个客户人群的关系，就是在分析这个人群中，谁有意愿支持我们，而谁却在自觉不自觉地阻碍我们。那些通过这个项目可以提高政绩，提高自身价值的人，都是我们可以争取的盟友。他们是我们最可以依赖的人，我们一定要与他们站在一起，荣辱与共，建立战略合作伙伴关系。
另一种人，即使软件获得了成功，也与他没有太多关系，但你与他相处得好，却可以给予你巨大的帮助，这种人是我们需要拼命争取的人。所谓领域专家，他可以给你多讲点儿，但随便打发你，对他也没太大影响。报着谦虚谨慎、相互尊重的态度，大方地与他们交往。当他们帮助我们以后，真诚地予以感谢。这是我总结出来的，与他们交往的准则。
最后，就是那些对我们怀有敌意的人。尽管有敌意，但我们能够坦荡的，敞开心扉的与他们交往。虽然不能奢望太多，但拿出诚意去争取他们，也还是有机会化干戈为玉帛、化敌为友。如果能够那样，那是再好不过了。
需求调研的研讨会阶段：
需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。在面对多个方案时，采用这种集中式的研讨，可以使问题的处理变得高效而及时。选择最合理的方案，或者方案合并，使得差异最小化，最终在软件维护中体现出来，让客户自己去选择自己的管理模式。进入一个良性循环。合理地与客户组织研讨会，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
需求调研的需求研讨阶段：
在需求分析过程中，客户存在的最大问题就是提不出正确的需求：
1.由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。
2.能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。这类客户，他们能熟练使用电脑，对信息化管理是清楚的。
3.能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。
在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。在最后我们才能说出，是客户让我们这样做的。眼界决定你的成败。
需求调研的迭代阶段：
需求分析是一个反复迭代的过程，需求捕获->需求整理->需求验证->再需求捕获••••••这是一个迭代循环。需求整理，就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。在一个系统中，用例需要细化几次，是由这个用例的业务复杂程度决定的。通过不断的迭代，最后得到客户满意的结果。
需求调研的需求捕获阶段：
需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。需求捕获最重要的是态度。在需求分析的整个过程，不断进行业务领域知识的学习。做需求访谈的初期，不是跟客户谈需求，而是先跟客户谈业务。我们的需求捕获最初是源于企业现有的操作流程，但当我们深入理解了客户现有的操作流程以后，应当有意识地发现那些不合理的部分，并最终提出更加合理、更适于信息化管理的流程。
需求调研的功能角色分析与用例图阶段：
一般地，在一个用例图中通常有三种元素：参与者（Actor）、用例（Use Case）与系统边界（Boundary）。用例描述的是系统为用户提供的功能，也就是系统能为用户做什么，通常被绘制成一个椭圆；参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责，通常被绘制成一个小人儿；最后是系统边界，也就是系统是对现实世界哪个范围的内容进行的模拟，它涉及到软件设计的工作范围与工作量，通常被绘制成一个方框。
功能角色分析是对系统宏观的、整体的需求分析，它用简短的图形绘制出了一个系统的整体轮廓。但仅仅进行功能角色分析是远远不够的，我们还需要在它的基础上做更加详尽的分析。
需求调研的业务流程分析阶段：
我们进行业务流程分析，就是要分析业务流程中哪些是需要信息化管理的，而哪些则不需要。清除低效环节，简化业务瓶颈，整合可用资源，最后是自动化繁重操作。
需求分析：用例说明
编写用例说明应当是最主要的工作，之后在一些关键部分辅之以行动图、状态图。将需求列表附在用例后面，便于日后的需求评审与确认。做到最方便。
需求调研的查询报表分析阶段：
报表作用：就是描述参与者使用这个报表做什么。如果有多个参与者，每一个都应当描述。
报表内容：用简短的话描述一下。
查询报表的需求分析与一般的业务操作的需求分析存在着巨大的差异。查询报表一定要分析到位。
需求调研的行动图与状态图阶段：
用例分析中对子用例与扩展用例的分析，使我们对系统的设计，从一开始就将公共的、可共享的部分提取出来，使我们在日后的设计与开发中得以很好地复用，提高了系统的内聚并降低了系统的耦合，是一个优秀软件设计的开始。
需求调研的子用例与扩展用例阶段：
正如任何事物都有两面性，用例图也不例外。在需求分析中，状态图并不是必须的，它仅仅出现在你认为需要对某个对象的状态进行说明的时候。活动图表明了各种活动之间的流转顺序。
需求调研的业务领域分析阶段：
软件系统就是对现实世界的真实模拟。在软件世界中就拥有什么函数；在现实世界中与哪些事物存在怎样的关系，在软件世界中就应当与它们发生怎样的关联。这正是面向对象编程的核心思想。业务领域，就是客户所在的知识领域，譬如财务人员所在的是财务领域，税务人员所在的是税务领域，营销人员所在的是销售领域。进行业务领域分析，就是通过与用户进行交流，掌握领域知识，然后绘制成业务领域模型，去指导我们软件开发的过程。
需求分析：原文分析法
过去我们拿到需求不知道该怎样去业务领域分析。有了原文分析方法，给了我们一个简单可行、易于操作的方法，让我们准确而高效地完成业务领域分析。
非功能需求可以简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。而这5部分我们可以进一步细化。
需求确认：需求列表
通过需求列表的形式可以更加直观的看出系统有哪些需求。
需求确认：快速原型法
用实物与用户确认需求，这就是快速原型法的基本思想。快速原型法，简称原型法（Prototyping），它摒弃了那种一步步周密细致地调查分析，然后逐步整理出文字档案，设计开发，最后才能让用户看到软件结果的繁琐作法。当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。
需求确认：需求规格说明书
需求规格说明书（Requirement Specification）分为用户需求规格说明书和产品需求规格说明书。
需求确认：评审与确认签字会：
确认需求，内部评审会与外部评审会，签字确认，成功完成！