④掌握各种沟通技巧

　　需求分析的过程实际上是个沟通的过程，CIO要想方设法吸引业务人员说出其需求。有时候，尝试着问一些“愚蠢”的问题也有助于用户打开话匣子。如果CIO直接要求业务人员写出业务是如何实现的，十有八九无法完成;但如果尝试着问一些实际的问题，例如：“以我的理解，你们收到订单后，会。。。”。业务人员立刻就会指出你的错误，并滔滔不绝的开始谈论业务，这一招就叫“抛砖引玉”。

　　⑤对业务需求进行逻辑分析

　　业务人员对需求的表达通常是笼统、感性、琐碎的，CIO要尽量理解业务人员用于表述他们需求的思维过程，充分研究用户执行任务时决策的过程，并抽象出潜在逻辑关系，把一些“常识”性东西用逻辑来实现。例如，当IT人员与护士交流医嘱处理过程时，护士会告诉IT人 员，护理级别有特级护理、一级护理、二级护理、三级护理以等;饮食又分流食、半流食、禁食等种类。如果仅仅把护士的要求用计算机语言表达出来，就可能出现 同一个病人既是一级护理又是二级护理，既吃流食又吃半流食的可笑情况;这些矛盾的避免原来是靠护士的大脑来判断的常识性问题，而用计算机来判断“常识”是最难的，也是最容易忽视的。经过反复探索，协和医院信息中心主任李包罗抽象出了一个互斥组的概念。特级、一级、二级、三级护理组成一个互斥组，当护士选择特级护理的时候，自然排斥了一级、二级和三级护理。李包罗说：“在与医生、护士沟通的过程中，IT人员不是要成为临床专家或者护理专家，而是要用IT知识去梳理医生护士的要求，变成一种计算机可以实现的概念，超越了手工的功能才会受到业务部门的欢迎。”

　　⑥以通俗的语言编写软件需求报告

　　IT人员应将从业务人员那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法等，然后编写软件需求报告。“需求分析报告”是IT人员和业务人员之间针对要开发的产品内容达成的协议。报告应以一种业务人员认为易于翻阅和理解的方式组织编写;报告中可以大量使用图表，但必须向业务人员解释清楚每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

　　⑦描述产品的使用特性

　　业务人员可以要求IT人员在实现功能需求的同时还注意软件的易用性，因为易用性或质量属性能使客户更准确、高效地完成任务。例如业务人员有时要求产品要“界面友好”或“健壮”、“高效率”，但对IT人员来讲，太主观了并无实用价值。IT人员可以通过询问和调查了解客户所要的“友好、健壮、高效“所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。

　　⑧业务人员和IT人员互相尊重

　　如果业务人员与IT人员不能相互尊重，那关于需求的讨论将会遇到障碍。参与需求分析的业务人员有权要求IT人员尊重他们并珍惜他们为项目成功所付出的时间;但业务人员也要尊重IT人员的需求可行性及成本评估。所有软件功能都是有成本的，业务人员所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。IT人员会拒绝或实现不了业务人员的一些要求，业务人员也应该尊重IT人员的意见。

　　⑨有需求变更要立即联系

　　不断的需求变更，会给在预定计划内完成的产品质量带来严重的不利影响，但需求变更又是不可避免的。在开发周期内变更越在晚期出现，其影响越大;变更不仅 会导致代价极高的返工，而且工期将可能被延误，特别是在主体架构已完成后又需要增加新特性时。所以，一旦客户发现需 要变更需求时，请立即通知IT人员。

　　⑩需求确认仅仅是以后讨论的“基线”

　　在“需求分析报告”上签字，通常被认为是业务部门同意需求分析报告的标志性行为，然而在实际操作中，业务人员往往把“签字”看作毫无意义的事情。有时这个领导同意了，那个领导却不同意;即使每个相关人员都签了字，也照样“翻供”，通常的理由是：“他们要我在需求文档的最后一行签名，于是我就签了，否则他们不开始编码!”同样的问题也发生在仅把“签字确认”看作是完成任务的IT人员身上，一旦有需求变更出现，便指着“需求分析报告”说：“您已经在需求分析报告上签字了，所以这都是按照您的要求开发的。”-这两种态度都是不对的，因为业务人员不可能在项目早期就能说清楚所有业务需求，变更需求是必然现象。在“需求分析报告”上签字确认，仅仅是需求分析过程结束的标志，它意味着“需求分析报告”是以后讨论的基线，进一步的变更可在此基线上通过项目定义的变更过程来进行。

　　拨开需求分析的迷雾，将给初步的需求开发工作画上双方都明确的句号，将有助于形成一个持续良好的客户与开发人员的关系，为项目成功奠定坚实的基础。

　　需求分析的风险

　　客户有时会提一些看上去很“酷”，但缺乏实用价值的功能;若要实现这些功能可能要耗费大量时间和成本，造成项目延期，此时CIO要权衡业务需求和项目资源之间的关系，及时决定必须完成哪些需求，舍弃哪些需求。

　　不重视需求分析的项目组将“自食其果”，但重视了并不一定能写出完美的需求分析报告，因为需求分析中还有很多陷阱，稍微不慎CIO就可能掉进业务需求的“陷阱”。需求分析中常见的陷阱有以下几种：

　　首先是无足够用户参与。业务部门经常不明白为什么收集需求和确保需求质量需要费那么多功夫。由于业务部门工作很忙，有时IT人员很难与业务人员坐在一起交流业务需求;即使费了九牛二虎之力坐在一起，业务人员也讲不明白自己的真正需求。为确保需求分析的质量，CIO一方面要让IT人员与尽量多的业务人员交流;另一方面，应让具有代表性的用户在项目早期就直接参与到开发队伍中来，一同经历整个开发过程。

　　其次是业务需求无休无止。业务部门在开发中若不断补充需求，项目就可 能越变越大以致于超过计划及预算范围。计划并不总是与项目需求规模与复杂性、风险及需求变更实际情况相一致，使得问题更难解决。要想把需求变更范围控制到 最小，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。另一方面，CIO要确定一个提需求分析的最后时间，不能放任业务人员无休止的提需求分析。

　　再次是用户需求模棱两可。模棱两可是需求规格说明中最可怕的问题。模棱两可的需求会使开发人员为错误问题而浪费时间，并使测试者无所适从。一位系统测试人员说，他所在的测试组经常对需求理解有误，以致不得不重写许多测试用例并重做许多测试。

　　最后是不必要的“画蛇添足”。“画蛇添足”是指开发人员力图增加一些用户“欣赏”，但需求分析说明中并未涉及的新功能。有时IT人员花了非常大的力气，但用户并不认为这些功能很有用;IT人员应努力使功能简单易用，但不要未经业务人员同意，就自作主张。同样，客户有时也会提一些看上去很“酷”，但缺乏实用价值的功能;若要实现这些功能可能要耗费大量时间和成本，造成项目延期，此时CIO要权衡业务需求和项目资源之间的关系，及时决定必须完成哪些需求，舍弃哪些需求。任何项目都不可能十全十美，也不可能满足用户的所有需求，毕竟项目的成本有限;CIO要弄清这些功能的“来龙去脉”，使得需求分析过程始终注重那些能使用户完成主要任务的核心功能。