资源描述
,#,单击此处编辑母版标题样式,#,单击此处编辑母版标题样式,湖南科创信息技术股份有限公司,单击此处编辑母版标题样式,#,单击此处编辑母版标题样式,#,单击此处编辑母版标题样式,#,单击此处编辑母版标题样式,#,湖南科创信息技术股份有限公司,单击此处编辑母版标题样式,#,单击此处编辑母版标题样式,#,单击此处编辑母版标题样式,#,单击此处编辑母版标题样式,#,单击此处编辑母版标题样式,北京科创鑫源信息技术有限公司,2014-11-6,唐玉林,1,需求开发与需求管理,消除软件开发百病之源,需求概述,1,需求分析,3,需求定义,4,2,需求,管理,5,需求获取,2,汇报内容,_,需求概述,了解客户、最终用户、间接用户,客户,掏钱买软件的用户称为客户。,客户,永远是本公司的,座上客，是上帝。,客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。,从未有人曾在与客户的争辩中获胜。,客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益,。,最终用户,真正操作软件的用户。即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。,间接用户,既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。,需求的层次,需求,的层次,业务,需求,反映,了组织机构或客户对系统、产品高层次的目标,要求。,用户,需求,功能需求,(,非功能需求,),描述用户使用产品必须要完成,的任务,。,定义开发,人员必须实现的,软件,功能，使得用户能完成他们的任务，从而满足了业务需求,。,IEEE,对需求的定义为：,（,1,）用户解决问题或达到目标所需的条件或能力。,-,针对用户,（,2,）系统或系统部件要满足合同、标准、规范或其他正式规定,文件文档,所需具有的条件或能力。,-,针对开发,者,需求的基本,概念,需求,是产品的,根源,，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。,国内软件业的,通病,：人们,并不真正清楚,究竟该做什么，但却一直忙碌不停地开发。,需求的,重要性,什么是需求,被动型,被动,地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。,主动型,积极,地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说,“,良好的开端是成功的一半,”,，,“,主动型,”,需求工程是开发成功产品的必备条件。,领先,型,是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。,对待需求工程的三种态度,花时间了解用户需求是确保项目成功的必要投入,1,5,20,5,0,1,00,需求,设计,编码,测试,维护,需求分析员需要的技能,1,、倾听的技巧,2,、交谈和提问的技巧,3,、分析能力,4,、协调能力,5,、观察能力,6,、写作能力,7,、组织能力,8,、建模能力,9,、人际交往能力,10,、创造力,需求分析员必备的技能,1,、定义业务需求,2,、确定项目涉众,3,、获取需求,4,、分析需求,6,、编写需求规格说明书,7,、为需求建模,8,、需求验证,9,、优先级划分,10,、管理需求,需求分析员的工作,需求获取,2,需求分析,3,需求定义,4,9,需求管理,5,需求概述,1,汇报内容,_,需求,获取,需求调研的内容,客户,想要什么,?,要,这干什么,?,为什么,这么想,?,会不会,有别的想法,?,ThemeGallery,is a Design Digital Content&Contents mall developed by Guild Design Inc.,需求获取,需求调研的目的,搞清,客户的,要求,找出,要求的,逻辑,客户,想要的,结果,排除开发风险,，,挖掘控制潜在,的,需求,需求调研的内容和目的,关于,需求的,漫画,客户的描述与,实际,需求不,一致,需求,人员的理解与客户描述的,不一致,程序员实现的与,需求表达的,不一致。,项目,文档严重缺失,市场,人员忽悠得,天花乱坠,。,项目,双方投入巨大,冰山理论,客户心里想的,100%,客户嘴里说的,80%,你听到的,60%,你听懂的,40%,开发实现的,20%,需要多次从多个角度与客户、开发人员沟通、复述、确认,需求获取,聆听需求,首先，需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。,其次，需求分析员应当确定需求调查的方式，例如：,与用户交谈，向用户提问题。向用户群体发调查问卷。,参观用户的工作流程，观察用户的操作。,与同行、专家交谈，听取他们的意见。,分析已经存在的同类软件产品，提取需求。,从行业标准、规则中提取需求。,从,Internet,上搜查相关资料。,最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型的用户。,准备调查,建议：,养成收集日常问题的习惯，比如整理,日常,问题,归集,文档,执行调查,建议：,每次调研后编写,会议纪要,或,用户需求调查单,准备,工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息,。,需求分析员与用户面谈时应当注意以下事项：,如果,与用户约好了时间，切勿迟到或早退。要注意礼节，尽可能获得用户的好感，并为下次打扰他们埋下伏笔。,需求分析,员应事先了解用户的身份、背景，以便随机应变,。,需求,调查不象侦探推理那样从蛛丝马迹着手，应该先了解宏观问题，再了解细节问题。,如果,双方气氛融洽，可以采用灵活的访谈形式，轻易不要打断用户的谈话。当双方对某些问题的交流合乎逻辑地结束后，即可继续讨论问题表中的其它问题。,尽可能,避免为用户添麻烦，但也不能怕给用户添麻烦而降低需求调查的力度。,避免,片面地听取某些用户的需求而忽视其它用户的需求。,需求分析,3,需求,获取,2,需求定义,4,16,需求管理,5,需求概述,1,汇报内容,_,需求,分析,为了得到用户的金钱，企业不得不鼓吹：用户就是上帝，用户永远是正确的。,谁都知道这不是真的。事实上，很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。,需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类：,“,问答分析法,”,和,“,建模分析法,”,。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用，很有实用价值。,需求分析的基本概念,需求分析,是指在,需求,开发,过程,中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。,问题分析方法,问答,分析,方法：,刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”,。,问答,分析最重要的,问题：,“是什么”、“为什么”,、“不是什么”,。,其它,常见的问题有：,需求,存在二义性吗？,需求文档的上下文有矛盾吗？,需求完备吗？,需求是必要的吗？,需求可实现吗？,需求可验证吗？,需求的优先级确定了吗？,人们都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人一目了然，所谓,“,一图顶千言,”,就是这个道理。,在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。,需求建模就是指用图形符号来表示、刻画需求。,建模分析方法主要有两大类：,“,结构化分析法,”,和,“,面向对象分析法,”,。,恰当地使用图形符号：,现代建模工具如,Rose,有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。,世上不存在一个包罗万象的图,它能完整地描述需求。需求建模不可能取代文字描述。,在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。,建议将模型存放在需求文档的附录中，便于正文引用。,建模分析法,大家,都,有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人一目了然,，,可,谓,“,一图顶千言,”。,需求,建模就是指用图形符号来表示、刻画需求,。,建模,分析,方法有,两大类：“结构化分析法”和“面向对象分析法”。,恰当,地使用图形符号：,现代,建模,工具很多，都有,非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。,世上,不存在一个包罗万象的图它能完整地描述需求。需求建模不可能取代文字描述。在需求文档中，,文字描述是第一重要的，建模主要是起分析、解释作用。,建议将,模型与文字有机结合，相辅相成。,需求分析常用元素,总体功能框图,流程图,用例图,状态转换图,原型界面图,需求分析常用工具,WORD,EXCEL,VISIO,Axure RP Pro,Rationl Rose,PowerDesigner,需求分析,常用元素和,工具,数据模型图,总统功能框图,总统功能框图,功能框图,审批流程图,业务流程图,用例图,状态转换图,采购方式状态,原型界面（一）,需求定义,4,需求,获取,2,需求分析,3,30,需求管理,5,需求概述,1,汇报内容,_,需求定义,内容不完整,格式不统一,书写不严谨,照搬照抄,需求,太,简单,描述不清晰,Title in here,需求规格,说明书常见问题,需求阶段的文档种类,真实的记录,与用户的,交流情况，,包括交流的时间、地点,、与会人员、交流的主题等，以及每个人员的想法、建议、要求，逻辑上不需要严谨，重点是真实。,采用,自然语言（和应用域术语）来表达用户需求，其内容相对,于规格说明书而言,比较粗略，不够,详细。但具有较完整的逻辑。,是用户需求,说明书的,细化，更多地采用计算机语言和图形符号来刻画需求,，是,软件系统设计的直接依据。,会议纪要,或,用户需求调查单,用户需求说明书,软件需求规格说明书,需求规格说明书的格式,1.,引言,1.1,目标,1.2,项目范围,1.3,术语和缩略语,2.,系统概述,2.1,产品描述,2.2,产品功能,2.3,一般约束,3.,功能性需求分类,3.1,功能性需求分类方法,3.2,功能描述,1,3.3,功能描述,2,3.3.1,业务需求描述,3.3.2,用例图（角色描述）,3.3.3,功能需求,1,）,流程图（,审批或业务）,2,）功能描述,3,）主要数据元素,4,）原型界面,4.,外部接口,1.1,用户接口,1.2,软件接口,5.,产品非功能性需求,对象,目的,客户、用户、市场人员,了解他们期望得到什么样的产品,项目经理,根据产品描述来估计项目的进度,工作量和所需资源,开发团队,根据需求规格说明来了解需要开发什么样的产品,测试人员,使用需求规格说明来开发测试计划,测试用例和测试过程,文档编写人员,根据需求规格说明和用户界面设计来编写用户手册和帮助屏幕,系统维护和支持人员,根据需求规格说明了解产品的每一部分的功能是什么,培训人员,根据需求规格说明和用户文档来编写培训材料,软件需求要达到的目的,什么是好的需求规格说明书,1,正确,需求规格说明书应当正确地反映用户的真实意图，,“,正确,”,是产品需求规格说明书最重要的属性。如果,“,不正确,”,仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟,“,想要
展开阅读全文