信息技术:进行需求分析的十项基本法则

来源:项目管理师    发布时间:2012-05-06    项目管理师视频    评论

  如果CIO尝试着问一些愚蠢问题,例如:“以我的理解,你们收到订单后,会……”。业务人员立刻就会指出你的错误,并开始滔滔不绝谈论业务,这一招就叫“抛砖引玉”。
  开发人员与业务部门的交流需要好的方法。下面建议10条法则,开发人员和业务部门可以通过评审以下内容并达成共识;如果遇到分歧,可通过协商达成对各自义务的相互了解,以便减少日后的摩擦。
  ①先导入管理思想,再梳理业务流程
  “百闻不如一见,百见不如一尝。”没有亲历过信息化建设的人,对信息化的理解总是比较肤浅,甚至包括一些管理层成员。如上ERP系统时,如果一开始就让业务部门谈需求,业务人员谈得通常是当前工作中的困难或者希望实现的功能等;CIO必须从转变观念入手,先给业务部门导入信息系统所包含的管理思想,然后协助业务部门梳理业务流程。
  ②表达要符合业务部门语言习惯
  需求讨论集中于业务需求和任务,必然使用各种业务术语。如果开发人员是IT厂商,CIO应将有关业务术语教给开发人员,同时还要把IT人员常用的一些术语“翻译”给业务人员,做到交流畅通无阻。
  ③了解业务部门的业务及目标
  只有充分了解业务部门的具体业务,才能开发出满足其需求的软件。为充分了解业务人员的具体需求,CIO要和开发人员一起到业务部门去观察他们的实际工作流程,甚至与业务部门一起工作一段时间。如果是旧系统切换到新系统,CIO还要亲自用一下目前的旧系统,明白目前系统是怎样工作的,了解其流程情况以及可供改进之处等。
  ④掌握各种沟通技巧
  需求分析的过程实际上是个沟通的过程,CIO要想方设法吸引业务人员说出其需求。有时候,尝试着问一些“愚蠢”的问题也有助于用户打开话匣子。如果CIO直接要求业务人员写出业务是如何实现的,十有八九无法完成;但如果尝试着问一些实际的问题,例如:“以我的理解,你们收到订单后,会...”。业务人员立刻就会指出你的错误,并滔滔不绝的开始谈论业务,这一招就叫“抛砖引玉”。
  ⑤对业务需求进行逻辑分析
  业务人员对需求的表达通常是笼统、感性、琐碎的,CIO要尽量理解业务人员用于表述他们需求的思维过程,充分研究用户执行任务时决策的过程,并抽象出潜在逻辑关系,把一些“常识”性东西用逻辑来实现。例如,当IT人员与护士交流医嘱处理过程时,护士会告诉IT人员,护理级别有特级护理、一级护理、二级护理、三级护理以等;饮食又分流食、半流食、禁食等种类。如果仅仅把护士的要求用计算机语言表达出来,就可能出现同一个病人既是一级护理又是二级护理,既吃流食又吃半流食的可笑情况;这些矛盾的避免原来是靠护士的大脑来判断的常识性问题,而用计算机来判断“常识”是最难的,也是最容易忽视的。经过反复探索,协和医院信息中心主任李包罗抽象出了一个互斥组的概念。特级、一级、二级、三级护理组成一个互斥组,当护士选择特级护理的时候,自然排斥了一级、二级和三级护理。李包罗说:“在与医生、护士沟通的过程中,IT人员不是要成为临床专家或者护理专家,而是要用IT知识去梳理医生护士的要求,变成一种计算机可以实现的概念,超越了手工的功能才会受到业务部门的欢迎。”
  ⑥以通俗的语言编写软件需求报告
  IT人员应将从业务人员那里获得的所有信息进行整理,以区分业务需求及规范、功能需求、质量目标、解决方法等,然后编写软件需求报告。“需求分析报告”是IT人员和业务人员之间针对要开发的产品内容达成的协议。报告应以一种业务人员认为易于翻阅和理解的方式组织编写;报告中可以大量使用图表,但必须向业务人员解释清楚每个图表的作用、符号的意义和需求开发工作的结果,以及怎样检查图表有无错误及不一致等。
  ⑦描述产品的使用特性
  业务人员可以要求IT人员在实现功能需求的同时还注意软件的易用性,因为易用性或质量属性能使客户更准确、高效地完成任务。例如业务人员有时要求产品要“界面友好”或“健壮”、“高效率”,但对IT人员来讲,太主观了并无实用价值。IT人员可以通过询问和调查了解客户所要的“友好、健壮、高效”所包含的具体特性,具体分析哪些特性对哪些特性有负面影响,在性能代价和所提出解决方案的预期利益之间做出权衡,以确保做出合理的取舍。
  ⑧业务人员和IT人员互相尊重
  如果业务人员与IT人员不能相互尊重,那关于需求的讨论将会遇到障碍。参与需求分析的业务人员有权要求IT人员尊重他们并珍惜他们为项目成功所付出的时间;但业务人员也要尊重IT人员的需求可行性及成本评估。所有软件功能都是有成本的,业务人员所希望的某些产品特性可能在技术上行不通,或者实现它要付出极高的代价,而某些需求试图达到在操作环境中不可能达到的性能,或试图得到一些根本得不到的数据。IT人员会拒绝或实现不了业务人员的一些要求,业务人员也应该尊重IT人员的意见。
  ⑨有需求变更要立即联系
  不断的需求变更,会给在预定计划内完成的产品质量带来严重的不利影响,但需求变更又是不可避免的。在开发周期内变更越在晚期出现,其影响越大;变更不仅会导致代价极高的返工,而且工期将可能被延误,特别是在主体架构已完成后又需要增加新特性时。所以,一旦客户发现需要变更需求时,请立即通知IT人员。
  ⑩需求确认仅仅是以后讨论的“基线”
  在“需求分析报告”上签字,通常被认为是业务部门同意需求分析报告的标志性行为,然而在实际操作中,业务人员往往把“签字”看作毫无意义的事情。有时这个领导同意了,那个领导却不同意;即使每个相关人员都签了字,也照样“翻供”,通常的理由是:“他们要我在需求文档的最后一行签名,于是我就签了,否则他们不开始编码!”同样的问题也发生在仅把“签字确认”看作是完成任务的IT人员身上,一旦有需求变更出现,便指着“需求分析报告”说:“您已经在需求分析报告上签字了,所以这都是按照您的要求开发的。”-这两种态度都是不对的,因为业务人员不可能在项目早期就能说清楚所有业务需求,变更需求是必然现象。在“需求分析报告”上签字确认,仅仅是需求分析过程结束的标志,它意味着“需求分析报告”是以后讨论的基线,进一步的变更可在此基线上通过项目定义的变更过程来进行。来源于我考网
  拨开需求分析的迷雾,将给初步的需求开发工作画上双方都明确的句号,将有助于形成一个持续良好的客户与开发人员的关系,为项目成功奠定坚实的基础。

视频学习

我考网版权与免责声明

① 凡本网注明稿件来源为"原创"的所有文字、图片和音视频稿件,版权均属本网所有。任何媒体、网站或个人转载、链接转贴或以其他方式复制发表时必须注明"稿件来源:我考网",违者本网将依法追究责任;

② 本网部分稿件来源于网络,任何单位或个人认为我考网发布的内容可能涉嫌侵犯其合法权益,应该及时向我考网书面反馈,并提供身份证明、权属证明及详细侵权情况证明,我考网在收到上述法律文件后,将会尽快移除被控侵权内容。

最近更新

社区交流

考试问答