需求分析10条法则.doc

需求分析的10条法则2008-1-7 16:31:43??作者：佚名 HYPERLINK /hrpm11/ \t _blank ??历尽千辛万苦，终于签署合同， HYPERLINK /knowledge/application/itcomm.asp \t _blank IT供应商拿到了用户提供的几页“需求书”；然后就凭借自己的理解立即投入开发，等生米熬成粥才发现满足不了用户需求，接下来就是艰难、反复地修改，最后开发人员厌倦了，用户也厌倦了，当然项目款也遥遥无期。这样的案例可谓比比皆是！ 　　比起不成功的项目，一个成功的项目在开发者和客户之间往往采取了更多交流方式； HYPERLINK /knowledge/application/itcomm.asp \t _blank IT供应商不仅与终端用户或潜在用户群交流，而且对用户感性、朴素的认识进行抽象，提取出潜在逻辑关系，准确把握客户的真正需求，然后才进行 HYPERLINK /software/index.asp \t _blank 软件开发。作为项目开发者和最终用户之间的“桥梁”，CIO如何推进开发人员和终端用户的“对接”？如何从用户笼统、感性的描述中抽象出潜在逻辑关系？ 拨开需求“迷雾” 　　业务部门的主管甚至CIO经常试图代替终端用户说话，但通常又无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中；否则，产品很可能会因缺乏足够的信息而遗留不少隐患。 　　需求分析是 HYPERLINK /software/index.asp \t _blank 软件开发和 HYPERLINK \t _blank 项目管理的基础，但业务部门经常三言五语就把开发人员“打发”了，业务人员笼统、感性的描述对开发人员来说就像“雾里看花”，一些开发人员只好按照自己的理解去写CODE。要拨开需求分析的“迷雾”，就要先了解需求分析的“程序”。　 　需求分析包括业务需求、用户需求、功能需求、非功能性需求和需求分析报告等。业务需求反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定 义与范围文档中予以说明；用户需求描述了用户使用产品必须要完成的任务，应在使用实例或方案脚本中予以说明；功能需求定义了开发人员必须实现的 HYPERLINK /software/index.asp \t _blank 软件功能， 使用户利用系统能够完成他们的任务，从而满足业务需求；非功能性的需求描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约 束，操作界面的具体细节和构造上的限制等；需求分析报告所说明的功能需求充分描述了 HYPERLINK /software/index.asp \t _blank 软件系统所应具有的外部行为，在开发、测试、质量保证、 HYPERLINK \t _blank 项目管理以及相 关项目功能中起着重要作用。?? 　　业务部门的主管通常阐明“业务需求”，即产品的高层次概念和主要业务内容，为后继工作建立指导性框架；但“业务需求”并不能为开发人员提供开发所需的许多细节说明。“用户需求”必须找系统的最终使用者，他们最清楚要使用该产品完成什么任务和一些非功能性的特性需求，如程序的易用性、健壮性和可靠性等，而这些特性将会使用户很好地接受具有该特点的 HYPERLINK /software/index.asp \t _blank 软件产品。业务部门的主管甚至CIO经常试图代替终端用户说话，但通常又无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中；否则，产品很可能会因缺乏足够的信息而遗留不少隐患。 　　在实际需求分析过程中，由于业务部门工作很忙，经常没有时间或者觉得没有必要与 HYPERLINK /knowledge/application/itcomm.asp \t _blank IT 人员讨论需求分析，有时甚至希望 HYPERLINK /knowledge/application/itcomm.asp \t _blank IT人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则千万不能这样做。?? 　　优秀的 HYPERLINK /software/index.asp \t _blank 软件产品建立在优秀的需求分析基础上，而优秀的需求分析又源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。 十项基本法则 　　如果CIO尝试着问一些愚蠢问题，例如：“以我的理解，你们收到订单后，会……”。业务人员立刻就会指出你的错误，并开始滔滔不绝谈论业务，这一招就叫