拨开需求“迷雾”
业务部门的主管甚至CIO经常试图代替终端用户说话，但通常又无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中；否则，产品很可能会因缺乏足够的信息而遗留不少隐患。
需求分析是软件开发和项目管理的基础，但业务部门经常三言五语就把开发人员“打发”了，业务人员笼统、感性的描述对开发人员来说就像“雾里看花”，一些开发人员只好按照自己的理解去写CODE。要拨开需求分析的“迷雾”，就要先了解需求分析的“程序”。
需求分析包括业务需求、用户需求、功能需求、非功能性需求和需求分析报告等。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明；用户需求描述了用户使用产品必须要完成的任务，应在使用实例或方案脚本中予以说明；功能需求定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足业务需求；非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制等；需求分析报告所说明的功能需求充分描述了软件系统所应具有的外部行为，在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。 
业务部门的主管通常阐明“业务需求”，即产品的高层次概念和主要业务内容，为后继工作建立指导性框架；但“业务需求”并不能为开发人员提供开发所需的许多细节说明。“用户需求”必须找系统的最终使用者，他们最清楚要使用该产品完成什么任务和一些非功能性的特性需求，如程序的易用性、健壮性和可靠性等，而这些特性将会使用户很好地接受具有该特点的软件产品。业务部门的主管甚至CIO经常试图代替终端用户说话，但通常又无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中；否则，产品很可能会因缺乏足够的信息而遗留不少隐患。
在实际需求分析过程中，由于业务部门工作很忙，经常没有时间或者觉得没有必要与IT人员讨论需求分析，有时甚至希望IT人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则千万不能这样做。
优秀的软件产品建立在优秀的需求分析基础上，而优秀的需求分析又源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
十项基本法则
如果CIO尝试着问一些愚蠢问题，例如：“以我的理解，你们收到订单后，会……”。业务人员立刻就会指出你的错误，并开始滔滔不绝谈论业务，这一招就叫“抛砖引玉”。
开发人员与业务部门的交流需要好的方法。下面建议10条法则，开发人员和业务部门可以通过评审以下内容并达成共识；如果遇到分歧，可通过协商达成对各自义务的相互了解，以便减少日后的摩擦。
①先导入管理思想，再梳理业务流程。
“百闻不如一见，百见不如一尝。”没有亲历过信息化建设的人，对信息化的理解总是比较肤浅，甚至包括一些管理层成员。如上ERP系统时，如果一开始就让业务部门谈需求，业务人员谈得通常是当前工作中的困难或者希望实现的功能等；CIO必须从转变观念入手，先给业务部门导入信息系统所包含的管理思想，然后协助业务部门梳理业务流程。
②表达要符合业务部门语言习惯  
需求讨论集中于业务需求和任务，必然使用各种业务术语。如果开发人员是IT厂商，CIO应将有关业务术语教给开发人员，同时还要把IT人员常用的一些术语“翻译”给业务人员，做到交流畅通无阻。