04需求分析员.doc_第1页
04需求分析员.doc_第2页
04需求分析员.doc_第3页
04需求分析员.doc_第4页
04需求分析员.doc_第5页
已阅读5页,还剩3页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件需求(第2版),清华大学出版社,2004-11-1 【原书名】 Software Requirements,Second Edition 原书信息 【原出版社】 Microsoft Press 【作者】 (美)Karl E.Wiegers 【译者】 刘伟琴 刘洪涛 【开本】 185260 【页码】 357 4需求分析员14.1需求分析员的职责14.1.1需求分析员的工作24.1.2需求分析员必备的技能44.1.3需求分析员必备的知识54.2如何培养需求分析员54.2.1从用户转为分析员64.2.2从开发人员转为分析员64.2.3主题专家74.3营造合作的氛围74 需求分析员即使没有明确指定,软件项目组中也会有某个人会担当需求分析员的角色。企业的IS组织中,行使这一职责的专家被称为业务分析员。对需求分析员的不同称谓还包括系统分析员、需求工程师、需求经理,也有简称分析员的。软件开发组织中,这项工作往往落在产品经理或营销人员肩上。需求分析员把其他涉众的看法阐释并纳入需求规格说明,并将相关信息反馈给他们。需求分析员帮助涉众找出他们所说的需求与他们实际的需求之间的差异。需求分析员要进行讲解、提问、倾听、组织和学习,这决不是一项轻松的工作。这一章将介绍需求分析员承担哪些重要职责,称职的需求分析员应具备哪些知识和技能,以及如何在组织中培养需求分析员(wiegers 2000)。读者可以从http://goodies.shtml下载一份需求分析员工作说明书的样本。4.1 需求分析员的职责需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。如图4. 1所示,需求分析员是用户群体与软件开发团队间进行需求沟通的主要渠道。项目还有许多其他沟通渠道,因此,项目的信息交换并非仅由需求分析员独自承担。需求分析员是收集和传播产品信息的中心角色,而项目信息交流的主导者则是项目经理。图4-1 需求分析员是客户和开发人员沟通的桥粱需求分析员是一种项目角色,而不是职务头衔。这个角色可由一个或多个专家专任,也可由同时担负其他职责的团队成员兼任,包括项目经理、开发经理、主题专家(SME)、开发人员甚至用户。他们在项目中兼任什么角色并不重要,关键是要具备一个合格的需求分析员所必需的能力、知识和良好个性。注意 不要指望优秀的开发人员或知识渊博的用户可以自动成为优秀的业务分析员,而不需要为他们提供培训、资料和指导。开发人员、用户和需求分析员这3种角色对技能、知识和性格特点的要求都不相同。需求分析员称职与否可以影响项目的成败。我的一家咨询客户发现,他们检查有经验的分析员写的需求说明所花的时间只是检查新手写的需求说明所花时间的一半,因为前者缺陷更少。在广泛使用的Cocomo II项目估算模型中,需求分析员的经验和能力对项目所需的工作量和成本有很大影响(Boehm et a1,2000)。相比缺乏经验的需求分析员,使用经验丰富的需求分析员能使项目所需的工作量减少三分之一。需求分析员的能力对项目的影响比经验更大。如果使用最出色的分析员,则项目所需的工作量只是使用最差的分析员时的一半。4.1.1 需求分析员的工作需求分析员是客户与开发人员交流的中间人,负责将客户对产品的初步想法转化为明确的需求说明,用来指导开发工作。需求分析员必须先充分理解用户对新系统的目标,然后再定义功能和质量需求。有了功能和质量需求,项目经理才能对项目进行估算,开发人员才能进行设计和开发,测试人员才能对产品进行验证。这一节将描述需求分析员需要进行的一些典型的活动。序号需求员的工作工作内容1.定义业务需求需求分析员的第一项工作是帮助业务或投资管理人、产品经理或销售经理定义项目的业务需求。第一个问题可能是:“我们为什么要进行这个项目?”业务需求应该说明组织的业务目标以及对系统最终版本、具备哪些功能的长远规划。需求分析员可以先提供一个前景与范国文档的模板(参见第5章),然后跟负责前景规划的客户据此展开讨论,帮助他们表达业务需求。2.确定项目涉众和用户类别前景和范围文档可帮助需求分析员分辨出产品的重要用户群和其他涉众。接下来,需求分析员可以与业务负责人一起为每一类用户挑选出合适的代表,说服他们同意参与需求开发,并就他们的责任进行协商。如果用户代表不能确切知道你希望他们做些什么,它们就可能拒绝参加需求开发。需求分析员应该把希望用户代表提供哪些协助写下来,并与每位代表商定合适的参与程度。第6章列出了一些需求分析员可以要求用户代表执行的任务。3.获取需求需求分析员不应被动地等待软件产品的需求送上门来,而是应该主动帮助用户把他们需要的系统功能表达清楚。第7章和第8章将对此作进一步讨论。需求分析员可能要用到下列信息收集方法:n 交谈n 需求讨论会n 文档分析n 调查n 现场访问客户n 业务流程分析n 工作流程分析和任务分析n 事件列表n 同类产品分析n 根据现有系统推导出需求n 回顾以往项目用户通常很重视系统的功能需求,所以,需求分析员需要对讨论进行引导,把质量属性、性能指标、业务规则、外部接口和约束等内容包括进来。对用户的假设提出质疑是正当的,但要尽量避免将自己的想法强加给用户。有些用户需求可能看起来很荒谬,但如果用户证实了它的正确性,再去争论它就没有任何意义了。4.分析需求需求分析员还要对收集到的需求进行分析,找出那些客户没有明确说明的需求。这类需求包括客户已提出的需求的逻辑结论,以及客户认为没有必要明说的需求。分析员还应找出含义不清、表达不充分的词,这些词将引起歧义(参见第10章给出的例子)。指出需求中有哪些地方相互矛盾或需要更进一步明确。功能需求说明的详细程度应以适合开发人员实现这些需求为准,不同项目对于详细程度有不同的要求。由紧密合作的小型团队采用增量方法开发的网站项目只需要一个简单的需求文档;而外包给国外公司开发的复杂的嵌入式系统则需要准确、详细的需求规格说明。5.编写需求规格说明需求开发的作用是各方对用于解决客户问题的系统形成了一致的理解。需求分析员负责编写条理清晰的需求规格说明,从而清楚地表述出这种理解。标准的用例模板和SRS模板能够提醒需求分析员应该跟用户代表讨论哪些问题,从而加速需求开发的进程。第8章讨论了如何编写用例,第10章研究如何记录功能需求,而第12章则描述了如何记录软件的质量属性。6.为需求建模需求分析员应该适时地选用文字以外的方式来表达需求。可选的表达方式包括各种图形分析模型(参见第11章)、表格、数学方程式、串联图和原型(参见第13章)。相比详细的文字描述,这些分析模型能够对需求信息进行更高层次的归纳和描述。为了便于交流和理解,需求分析员应按照标准建模语言的约定来绘制分析模型。7.主持对需求的验证需求分析员必须保证每一项需求声明都具备第1章中讨论的所有特点,并确保按照这些需求实现的系统能够满足用户的需求。在各方人员对需求文档进行评审时,应该以需求分析员为中心。需求分析员还要对设计、代码和测试用例(源于需求说明)进行检查,以便保证对需求的解释是正确的。8.引导对需求的优先级划分需求分析员安排不同用户群与开发人员进行合作与协商,以保证他们进行合理的优先级划分。第14章中描述的电子制表工具可用于划分需求的优先程度。9.管理需求需求分析员参与了软件开发的整个生命周期,因此,他应该帮助制订、检查和执行项目的需求管理计划。建立需求基线之后,需求分析员的注意力应转向管理需求,以及检查产品是否满足需求。使用商业需求管理工具来存储需求可以方便管理。请参见第21章对需求管理工具的讨论。需求管理包括跟踪每项功能需求的状态,从开始开发直到对集成产品的验证。需求分析员从同事那里收集跟踪信息,将各项需求与它对应的其他系统元素关联起来。在使用变更控制过程和工具来管理对基线需求的变更过程中,需求分析员起重要作用。4.1.2 需求分析员必备的技能希望不经过充分的培训、指导和实习就能成为需求分析员这种想法很不现实。这样的需求分析员必然因做不好工作而灰心丧气。需求分析员需要了解多种获取需求的方法,如何采用语言文字以外的方式来传达信息。优秀的需求分析员应同时具备出色的交流、引导和人际交往能力,具备技术和业务领域的丰富知识,以及适合这项工作的相应个性(Fcrdinandi 2002)。耐心和真诚的合作愿望是关键的成功因素。下面列出的这些技能对需求分析员特别重要:倾听的技巧 要善于双向交流,就必须知道如何有效地倾听。有效的倾听要求不能分神,保持专注的姿态和目光接触,以及重复要点以证实你的理解。要抓住对方说的每一句话,并且从字里行间找出他们因犹豫而没有说出来的内容。要熟悉合作者的表达习惯,避免用个人的理解方式来过滤客户所说的话。还要当心各种假设,这些假设可能隐含在你听到的话里,也可能在你对话语的理解中。交谈和提问的技巧 大部分需求是通过讨论得到的,因此,需求分析员必须能够与不同的个人或小组就需求展开讨论。与高级经理或某些固执己见、盛气凌人的人打交道可能会让人产生畏惧情绪。需求分析员必须通过适当的问题,让重要的需求信息显现出来。例如,用户很自然地把注意力集中在系统正常和预期的行为上,然而,很多代码却是为了处理异常情况而写的。所以,需求分析员必须研究可能出错的情形,并决定系统应如何响应。不断积累经验,你就能熟练掌握提问的技巧,从而发现并澄清需求中不确定、不一致的地方,以及假设和未声明的期望(Gause和Wcinbcrg 1989)。分析能力 优秀的需求分析员能够以不同的方式思考问题:有时必须将高层的信息不断细化;另一些情况下可以需要将某个用户提出的一项特定需求推广力一组需求,以满足众多的同类用户。需求分析员需要严格评估各种来源的信息,以便消除需求中的矛盾,将用户的“需要”与真正的需求区分开,并区别解决方案与需求。协调能力 需求获取过程中,对相关人员进行协调也是需求分析员必备的一项能力(Go七tcsdiener 2002)。一位具有良好的提问、观察、协调能力的中间协调人能够帮助团队建立信任,改善业务人员与IT人员之间不时变得紧张的关系。第7章给出了一些用于引导需求获取讨论的原则。观察能力 观察力敏锐的需求分析员能够从不经意的闲谈中发现重要的信息。通过观看用户如何工作,如何使用现有的应用程序,优秀的观察者可以察觉用户不曾提及的细微之处。良好的观察能力有时能让分析员找到需求获取讨论的新方向,发现不曾有人提及的需求。写作能力 需求开发提交的主要结果是书面的需求规格说明,用于在客户、营销人员、管理人员和技术人员之间传递信息。需求分析员应具备良好的语言驾驭能力,能够清晰地表达出复杂的概念。我听说有个组织让几位英语是第二语言的开发人员担任需求分析员。用母语写出优质的需求已经够困难了,用另一种语言来写更是难上加难,因为还要费力气解决表达差异、单词歧义和习惯说法等问题。另一方面,需求分析员还应该是高效和有判断力的读者,他们必须阅读大量资料并能迅速掌握其要点。组织能力 需求分析员需要处理获取和分析过程中收集到的大量杂乱的信息。分析员需要具备非凡的组织能力,以及从混乱和含糊信息中找出意义的耐心和韧性,才能妥善处理快速变化的信息并将其组织成一致的整体。建模能力 每个需求分析员都应该掌握从传统的流程图到结构化的分析模型(数据流图、实体关系图之类),直至当今的统一建模语言(UML)等多种分析工具。这些工具中有些用于与客户交流,另一些则用子与开发人员交流。需求分析员需要告诉其他涉众使用这些技术的重要意义,以及如何解读这些模型。请参见第11章中对几类分析模型的概述。人际交往能力 需求分析员应具备让彼此利益竞争的人们进行合作的能力。能够轻松地与组织中各级别、担任不同工作的人进行交流。也许还要与分布于各地的虚拟团队一起工作虚拟团队的成员来自不同的地域,拥有不同的文化背景或母语。有经验的需求分析员常常会指点新同事,并为客户讲解需求工程和软件开发过程。创造力 需求分析员不能像抄录员那样只记下客户说过的每句话。一流的分析员能够创造需求(Robcrtson 2002)。他们构思新颖的产品功能,推测新的市场和商业机会,并且思考让客户感到惊喜的方法。真正有价值的需求分析员能够帮助用户发现隐含的需求,并且找到新方法来满足这些需求。4.1.3 需求分析员必备的知识除了前面提到的专门技能以及性格特点,需求分析员还需具备从实践经验中积累的广博知识。其中最基本的是对当代需求管理技术的深刻理解,以及在各种不同的软件开发生命周期环境中应用这些技术的能力。称职的需求分析员应掌握多种技术,并能够根据具体情况选择运用。需求分析员需要将需求开发与管理活动贯穿于整个产品生命期中。如果需求分析员能够充分理解项目管理、风险管理和质量工程,则有助于避免因需求问题导致项目失败。在进行商业软件开发时,掌握产品管理概念,了解如何定位和开发企业软件产品,对需求分析员很有帮助。对优秀的需求分析员而言,掌握应用领域的知识也是一项重要的能力。熟悉业务的需求分析员可以最大限度地减少与客户间的误解。对应用领域有较深了解的需求分析员,常常可以发现未声明的假设和隐含的需求。他们能够为客户找出业务流程的改进方法。这样的需求分析员能够不时地提出用户想不到的有用的功能。另一方面,他们比不熟悉应用领域的同行更善于发现镀金问题。4.2 如何培养需求分析员优秀的需求分析员是培养出来的,而不是训练出来的。这项工作包括很多面向人而不是技术的“软性技能”。对于需求分析员的工作并没有标准的描述,因而也没有标准的培训课程。同一组织中的分析员可以具有不同的背景,他们掌握的知识和技能也可能不尽相同。每一位需求分析员都应该明确本章所描述的知识和技能中,哪些适用于自己的工作,并主动去查找有用的信息。Patricia Fcrdinandi(2002)描述了初级的、熟练的和顶尖的需求分析员应该展现的不同的能力水平:实践经验、工程技术、项目管理、技术和工具、质量以及个性。每一名分析员新手都能得益于更有经验的分析员对他的指导和训练,二者也许是一种师徒关系。现在让我们看看不同背景的人如何转而成为需求分析员。4.2.1 从用户转为分析员很多企业的IT部门中都有由用户转行而来的业务分析员。这些用户对业务和工作环境有着深刻的理解,很容易获得原来同行们的信任。他们讲的是用户的语言,了解现有的系统和业务流程。然而,让用户来担任需求分析员也有不利的一面。他们对软件工程知之甚少,也不知道如何与技术人员进行交流。由于不熟悉分析建模技术,他们往往只会用文字来表述所有信息。要想成为需求分析员,用户需要多学习一些软件开发技术,这样才能以最恰当的方式,有针对性地把信息传达给不同受众。有些转为分析员的用户认为自己比现在的用户更了解需求,因而不征求或不尊重这些系统实际使用者的意见。当前用户有时会局限于现有的工作模式,因而看不到利用新的信息系统来改进业务流程的机会。而转为分析员的用户在考虑需求时也很容易拘泥于用户界面。过早地专注于解决方案会为设计强加不必要的限制,往往不能解决实际的问题。从医疗专家到需求分析员一家大公司医疗设备部门的高级经理遇到了难题。“两年前,找聘请了3位医疗专家专门捉供用户需求,”他说,“他们干得不错,可没能跟上医疗技术的最新友展,所以不能准确说出现在的用户需要什么。现在他们该如何为自己选择合适的亭业发展方向呢?”我认为可以考虑让这3位前医疗专家成为部门的需求分析员。他们虽然不熟悉医院试验室里现在发生的事情,却擅长与其他医疗专家进行交流。而且在产品开发部门的两年经历又让他们了解了开发工作的机制。他们可能还要在需求编写能力方面进行一些训练,但多年来积累的多种宝贵经验使他们完全有可能成为称职的需求分析员。4.2.2 从开发人员转为分析员如果没有专职的需求分析员,项目经理往往会让开发人员来担任这一工作。但是,需求开发工作对人员技能和个性的要求与软件开发工作不同,正如马戏团的杂耍演员往往不是现实生活中最灵活的人。不少开发人员对用户缺乏耐心,认为只有赶紧把他们打发掉才能尽快开始编码这类真正的工作。当然,很多开发人员己经认识到了需求过程的重要性,也愿意在需要时担任需求分析员。有些开发人员喜欢与客户合作,借此了解需求以便指导软件开发。他们是最佳的专职需求分析员培养对象。开发人员要想成为需求分析员,需要多掌握一些业务领域的知识。开发人员很容易陷入技术思考和讨论,把注意力集中在要开发的软件本身,而不是用户的需求。开发人员应该接受一些软性技能的培训和指导,例如怎样有效地倾听、协商和引导。这些都是优秀需求分析员必须掌握的技能。4.2.3 主题专家Ralph Young(2001)建议让需求分析员成为应用领域的专家或主题专家,而不是一般的用户。他认为:“SME能够决定需求是否合理、应如何扩展现有系统、如何设计提议的结构、以及对用户有什么影响等一系列问题。”有些软件开发组织雇用某些用户担任需求分析员或用户代表,这些用户应精通公司的产品,并且在应用领域内有着丰富的经验。由领域专家担任需求分析员可能产生这样的问题:他根据自己的偏好来定义系统的需求,而没有说明各类用户的合理需求。SME往往希望实现高端、全能的系统,而实际上不需要那么复杂的解决方案就能满足大部分用户的需求。更合理的方式是让开发团队中的一位成员担任需求分析员,而SME作为主要的用户代表(即用户代言人)配合其工作(对用户代言人的介绍参见第6章)。4.3 营造合作的氛围很多时候,软件项目中需求分析员、开发人员、用户、管理人员、以及营销人员之间的关系会变得紧张。有时是因为不相信对方的动机,有时则因为不能理解对方的需要和所受的约束。其实,软件产品的生产者和消费者的目标是一致的。开发企业信息系统时,各方都是为同一家公司工作,项目成功后,他们的收入自然会随公司的效益水涨船高。对商业软件而言,客户满意就会给生产者带来收益,让开发人员得到满足。在建立与客户代表和其他涉众的合作关系问题上,需求分析员负有主要责任。称职的需求分析员应该及时意识到涉众遇到的难题,无论是业务问题还是技术问题。他还要自始至终表现出对合作者的尊重。需求分析员引导项目参与者就需求取得一致,进而达到三赢的目的: 客户对产品感到满意 开发组织因产品在商业上取得的成就而兴奋 开发团队成员为在具有挑战性和高回报的项目中取得的成果而骄傲下一步 如果您是一名需求分析员,请与本章介绍的知识与技能进行比较。如果发现有差距,选择两个方面立刻开始改进,通过阅读、实践、请教导师或参加培训班等方式缩小差距。 选择一项书中介绍的软件工程实践进行仔细研究,从下周开始实施。另外选出两到三项安排在一个月内开始实施。其他的则可以作为长期的改进项目,在五到六个月内开始实施。明确你打算怎样应用每一项新实践,希望它能带来什么好处,还需要哪些帮助和额外的信息。考虑一下应用这些新技术需要得到谁的合作。找出所有可能妨碍你应用这些实践的障碍,想想谁能帮你克服它们。需求分析员的工作简化版序号需求分析员的工作工作内容1.定义业务需求帮助业务或投资管理人、产品经理或销售经理,定义

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论