我们应当怎样做需求分析
需要掌握的内容：理解能力、设计能力、与人交往、沟通的能力
对这部分内容的理解：一个软件项目的需求调研必不可少，需要对不同的角色进行调研，完整的需求分析不能一蹴而就，需要遵循一定的科学方法，在理解现有的管理模式的基础上，站在信息化管理的角度去审视客户的管理模式是否合理，最后一步一步地去引导他们按照更加合理的方式去操作与管理。我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的，而且会感觉你非常的专业，你在客户心中的形象也会无形中提高，是你有更多的机会提出有利于开发的解决方案，这会形成一个良性循环，人与人交往，起初展现出以为技术专家的姿态，能大方得体地提出自己的意见，会是顾客重视你的意见，这就要求我们有足够的自信。
需要掌握的内容：职业威信、尊重、谦虚谨慎
对这部分内容的理解：要完成一个目标需要双方共同的努力，中国人做事重感情，所以做事先培养感情，有了感情才能慢慢做事，有了良好的客户关系，软件项目不是一锤子的买卖，而是长期的、持续不断的提供服务，客户与软件供应商应该是长期友好的关系，与可以从我们的项目中提高自身业绩的人站在一起，荣辱与共，建立战略合作伙伴关系。面对可以对项目有所帮助的人应该抱着谦虚的态度，相互尊重的态度，大方地与他们交往，当他们给予我们的帮助后真诚地表示感谢，对于阻碍项目的人来说，能够坦荡的敞开心扉的与他们交往，拿出诚意去争取他们的谅解。
需要掌握的内容：集中式的研讨
对这部分内容的理解：划分业务组，可以让业务人员分别在各自最熟悉的业务范围内参与讨论，可以有效的提高业务讨论的质量。一个管理系统涉及的业务是复杂而系统的，如果划分成多个模块并行地进行业务讨论，也可以大大提高业务研讨的工作效率。对管理松散的多组织机构时，寻找一个管理规范、对我们支持度高的分支机构，首先将他们的信息化系统建立起来，产生预期的效益这就树立了一 个范例。它的成功就会为其它分支机构带来一种精神动力和成功案例，照着 做肯定不会错。这样就可以更容易地说服其它分支机构，摒弃现有的管理模 式而朝着规范化管理迈进，业务研讨是灵活的，合理地组织研讨会，都要有效抑制个性化差异、分模块组织专项研讨会。
需要掌握的内容：需求研讨会
对这部分内容的理解：首先跟客户探讨的不是软件功能，而是客户现有的业务知识，又叫业务领域分析。在认识了客户的业务领域之后，我们才能去分析他们提出的所有原始需求。主要解决的是他们为什么会提出这样的需求，他们的目的是什么，这样才能深刻理解需求，然后利用我们现有的知识去解决这样的需求，眼界应当更开阔一些，扩展到跟这个业务有关的哪些领域知识中。我们应当有自信，在理解客户的真正意图后可以提出比客户更好的解决方案。
需要掌握的内容：迭代分析，用例分析
对这部分内容的理解：分析和设计功能，需求列表中的需求在各个过程中都要如实的实现，通过用例模型将流程细化，由粗到细，在用例图的基础上在有更加细化的用例，这样不断的细化，知道我们的需求被描述清楚为之
需要掌握的内容：需求捕获
对这部分内容的理解：以主动的态度去捕获需求，在需求分析的整个过程中，不断进行业务领域知识的学习，深入理解用户为什么会提出这样的需求，这样做出的需求分析才是完整的、准确的。
需要掌握的内容：功能角色分析
对这部分内容的理解：采用完整的分析方法，稳步有序地完成工作。采用绘制用例图的方法对一个系统进行功能和角色的梳理和分析，用例图的常见问题：没有正确理解用例图的视角，应在用户的角度去观察我们需要设计的系统。图形绘制杂乱，一级用例与二级用例不能混杂在一个人设计图里，用例没有在特定的场景下
需要掌握的内容：业务流程分析
对这部分内容的理解：绘制用例图，与客户形成统一的，能够相互理解的语言
需要掌握的内容：原文分析法
对这部分内容的理解：在用例说明与流程分析的基础上进行的业务领域分析，对用例说明中事件流部分的文字描述，对用例说明中的动词分析，定义各个实体之间的各种行为。
需要掌握的内容：需求规格说明书
对这部分内容的理解：用户编写的原始需求脱离了技术实现，本着实事求是的态度、切实可行的态度，需求规格说明书是站在用户的角度，产品需求规格说明书是站在开发人员角度。
