总算学完一个学期的UML建模，自觉也学的不大好，老师讲的也快，用的是经典的《UML 模式与应用》一书，所以打算暑假花点时间再次边研究边总结，并且打算结合项目管理的课程，一边复习一边写点心得，每次都打算以最简单的进行概括
首先想谈下的是需求分析过程。其实这应该理解为两个过程：1 需求的获取 2、需求的分析。这两部十分重要的，需求的获取，往往不受到重视，特别是国内目前的情况，项目工期紧，公司往往想方设法先把项目拿下来，然后就拿自己公司以往做过的项目做蓝本，然后再根据顾客的需求改动，再次开发，测试，交付就完工了。但如果需求的获取，做不好，往往对后面的步骤流程造成很大的影响，造成太多的改动和损失。所以，在需求获取阶段，应该做好如下几点：
1、尽可能在需求的获取阶段有行业专家或行业专门人员提供咨询和参与，往往在大型项目中，适当在这方面予以投资，产出比是很高的（当然，目前大多数企业很难做到，但建议十分大的项目的话，起码要找熟悉的行业人员做个帮手，呵呵）
2、设法得到用户的协同和认可，特别要尽量得到用户方高层的认可。目前很多企业外包系统开发，特别是一些国家单位，事业单位和企业，都有这样的意识：认为项目一旦签了出去，事情就让公司开发去了，自己省了很多事，因此态度在需求分析阶段不是那么好，高高在上的态度，认为开发方老是去烦着他们，浪费他们的时间（要知道，不是所有用户的公司都有负责IT的专业人员的，很多都是业务部门拍拍脑袋说了算），这个时候要怎么办？这时候，应将公关的重点放在与用户的沟通上，开发方要以充分的证据，最好以成功，失败的案例（无的话呢，编也要编出来给用户知道，一定要充分和开发方进行很好的配合。之前我在一个监理项目中，就建议开发方这样做，因为当时甲方是大型的国家单位，高高在上，也有高级IT人员，领导整天忙，流程也不好，一开始态度也一般，所以后来开发方在项目的一个有领导参与的大会上，通过PPT演示和讲解了用户方和开发方配合的重要性，果然引起了领导的重视，为后来项目的成功打下很好的基础。记住，要通过案例的形式来让用户特别是用户的领导充分意识到：用户领导重视的重要性。
3 与客户的需求调研时，要以客户为中心，要选择好和用户沟通的语言。很多人喜欢在调研后，画出UML用例图给用户看，我觉得这是不恰当的。试想，用户的领导，一般业务人员，有多少会看UML图呢？所以，在调研后，给用户看的应该
A 业务流程图
B 对业务流程图的文字阐述
C 用户方原有系统（组织）的架构图
D 用图表，表格等形式对用户需求的调研反映
因为从心理学上看，以上四点，最能符合用户的心理习惯，不容易给用户抗拒，用户十分熟悉，一看就明白，沟通起来自然得心应手。
4、在确定每个需求后，要用户和开发方签名确认。很多用户不喜欢这样做？怎么办？这个时候，公关要出动了！要让用户知道，只有双方都同意了，对大家双方都有好处，开发方可以加快进度，完成高质量的产品，用户方在思考一定时间后的确认，则保证了项目的健康发展。
5、在每次调研时，要注意笔记和录音，起码两人，一人询问，一人记录
6、每次调研需求后，将需求分类别，分为最容易实现的需求，可以实现的需求，需要较长时间才能实现的需求，目前不可能实现的需求，该项目不可能实现的需求，对需求运用需求管理工具进行分类管理，然后下次展示给用户看。要注意一点的是：不要单独在一次会议上向用户大吐苦水，说哪些哪些需求是实现不了的（即使用户很多不要的要求甚至无理的要求），要以列表的形式，象上文所的那样，
列出哪些是用户好的需求（甚至要赞扬用户的需求提的好，让用户乐一下，呵呵），哪些是本公司一定能实现的，哪些是目前暂时不能实现的，哪些是有可能实现不了的。如果用户很多无理要求，也不要一次全盘说出来，以免引起用户的反感，尽量分几次说出来，每次都让
用户觉得，开发方能最大限度满足用户的需求，这样，用户从心理上就不会那么抗拒了，即使用户提出了不合理的要求。这样的办法，
可以很好地拒绝用户不合理的要求，水到渠成，不会让用户怀疑开发方的能力，大家都高兴。
以上是需求调研阶段要注意的一些东西。
.