面向对象需求分析实例PPT.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,#,北京北大方正电子有限公司,面向对象需求分析实例,用例分析方法及需求描述介绍,张云贵,2009.10.31,1,内容提要,用例分析技术概述,业务用例建模,业务用例描述,系统用例建模,系统用例描述,功能需求描述,方法讨论,2,一、用例分析技术概述,面向过程分析,vs,面向对象分析,SA,：顺藤摸瓜得到全貌，结构化分解为子系统和各级功能，重点关注流程,例如：数据流程图、需求规格说明书的功能划分,问题：在随需应变的商业环境下，流程不再稳定,OOA,：着眼于个体和局部，了解个体的特征、行为、需求，找到相邻的联系，按不同视角分析，最终得到整体任务全景,用例的场景仍是面向过程的,3,一、用例分析技术概述,用例分析技术,特定的,人,，做一些,事,，需要一些,物,，产生一些物，按照一定的,规则,以人为本，描述参与者的业务目标和场景,用例分析关键点,站在客户立场，想用户所想,分清客户想要什么,不要急于思考如何实现,4,一、用例分析技术概述,用例与需求调研,面对的是局部个体，问对人，做份内之事，看到关心的结果,请比较调研分析的角度：,A.,您希望系统帮你做些什么事情？,B.,您希望系统怎么做比较好？,C.,系统这样做，你看如何？,D.XX,部门需要什么功能？提供这些功能如何？,E.,我们有这些很有用的功能,5,一、用例分析技术概述,快速原型法,vs,面向对象分析,快速原型法的前提是必须了解实际业务需求,前者是具体的一种实现方式，易丢失原始需求，掺入过多细节、华丽功能、个人设计习惯,可结合起来，用后者来分析，当成编写电影脚本，用前者来直观呈现和印证挖掘，佐证结果按使用者角度记载下来，保留业务需求,不要以建模成本高而放弃,OOA,思想,6,二、业务用例建模,区分概念,功能、需求、,业务需求,、用例,系统用例、业务用例、业务场景,为什么要进行业务建模？,成为业务专家，全面了解业务目标和内涵,在新领域内长期发展、拓展业务,让团队成员了解需求、理解一致,7,二、业务用例建模,内容提要,界定业务目标、划分业务视角,识别业务主角、业务用例，要点,业务场景建模，要点,修正业务用例和场景,8,2.1,界定业务目标,目的,时刻提醒需求分析的方向，不偏离边界范围,做法,先将业务目标简明准确的概括出来,对具体目标编号、标题,+,说明,在业务建模图中标出各个业务目标,9,2.1,界定业务目标,10,2.2,划分业务视角,目的,限定分析范围、业务边界，避免用例混乱,在特定业务视角中满足业务需求,做法,按照不同的业务目标分别建立用例“包”,每个包中一个用例图,11,2.2,划分业务视角,12,2.3,识别业务主角,业务主角（,Business Actor,）,与业务系统有交互的人或事物，用于确定业务范围，区分与业务工人,注意,业务主角是客户实际业务里的参与者，没有计算机系统这些业务主角也客观存在，没有抽象的计算机角色,13,2.3,识别业务主角,14,2.3,识别业务主角,先找业务主角，再找对应的业务用例,业务主角的特点,在当前业务边界外，为其提供服务,建立该项目能对外提供什么服务？,主动发起要求，有预期目的并得到结果,业务工人在此无权提出业务用例,识别举例,15,2.4,识别业务用例,用例,用例就是做一件事情，完成某个目标。,一件事要按一系列步骤完成,活动,做事有不同的方式和相应的步骤,用例场景,业务用例,用于描述客户现有业务，和新系统无关,16,2.4,识别业务用例,业务用例的特点,实现完整的业务目标,由主角发起，有明确的结果,动宾，避免弱动词和弱名称,如果粒度太大或太小，需要调整边界,如何扩展用例,先完成所有业务边界包、主要业务用例,不要急于扩展用例，现在还在边界外,17,2.4,识别业务用例,18,2.5,业务场景建模,业务场景活动图,使用泳道来区分各个岗位的职责和关系,用于核心或复杂业务流程、跨部门,/,岗位协作,注意点,使用实际业务语言，不要抽象,条件分支不要太多，可用多个场景来描述,忘掉我们的系统，描述目前业务情况,演示,19,三、业务用例描述,内容提要,描述业务目标,描述业务现状、数据结果要求,描述业务分析视角、列出典型业务场景,业务用例描述，详细介绍,演示,20,四、系统用例分析,从业务用例映射到系统用例,识别责任、边界、目标,补充必需的系统用例，如系统管理,标准,参与者：系统之外、直接与系统交互、人或物、有责任和目标,用例：执行者可见、有意义的目标、业务语言、动宾、用户视角、交互完整,粒度：操作者与计算机的一次完整交互,21,五、功能需求描述,有了详细的系统用例，就不用再功能分解,是对结构化分析和,WBS,的挑战,是功能需求，而不是功能,描述功能需求的要点,描述做什么，不描述如何实现,对于界面示意图，必须有文字描述其需求点,22,用例文档分析,用例文档分析（演示）,（后面为另一个,PPT,的部分内容）,23,UML,常用视图分类,模型视图,需求分析,系统设计,详细设计,1,用例图,2,需求图,3,活动图,4,序列图,5,状态图,6,类图,7,组件图,8,协作图,9,部署图,24,二、需求分析视图,用例建模的疑惑,快速原型，让用户先认同原型，再不断开发,软件就是设计很多功能，最终能满足需求,前期无法确定需求，先尽快完成再调整,用户不懂用例，我们也不懂，也没时间建模,直接告诉程序员要做什么，更准确快捷,用例建模的实质,以人为本，从参与者角度规定要做的事,/,规则,25,二、需求分析视图,业务流程分析图,业务用例图,业务场景活动图,系统用例图,需求图,用例实现序列图,（演示）,26,1.,业务用例图,27,1.,业务用例图,使用场合,来源于访谈，表达业务目标，按需定做,多角色、业务流程复杂、长期发展,要领,找出业务参与者、关心的问题,站在客户角度看，忘掉系统，不要急于实现,禁忌,从里往外看、硬套解决方案,28,1.,业务用例图,建模步骤,根据业务目标界定边界，和计算机实现无关,业务主角,边界之外、对系统有明确期望和回报、主动要求,不是系统强加的角色，是实际的岗位或人员,业务用例,由参与者主动发起、可观测、完整的业务目标,粒度：边界要清楚，用例数在,1050,个之间,用例功能，不是能做什么，而是要做什么,29,2.,业务场景活动图,30,2.,业务场景活动图,使用场合,描述复杂、核心的业务流程的各种场景,要领,按角色划分泳道，明确职责和联系,活动为业务用例或关键概念用例,禁忌,强加系统流程、涉及用户不可见的内容,非用户语言,31,3.,系统用例图,32,3.,系统用例图,使用场合,描述应实现哪些任务，系统范围,要领,从业务用例场景中获取，排除、合并、补充,粒度为操作者与计算机的一次完整交互为宜,参与者：系统之外、直接与系统交互、人或物、有责任和目标,用例：执行者可见、有意义的目标、业务语言、动宾、用户视角、交互完整,33,3.,系统用例图,禁忌,急于加入细节、具体的技术实现方法,功能分解,不适合的场合,不是功能密集型，而是技术密集型，单用户,34,35,