《《UML面向对象建模基础》需求建模基础与实例课件》由会员分享，可在线阅读，更多相关《《UML面向对象建模基础》需求建模基础与实例课件（40页珍藏版）》请在装配图网上搜索。
1、单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,UML,面向对象建模基础,需求建模基础与实例,知识图谱,Agenda,什么是需求,如何使用,UML,对需求建模,需求建模实例,本章小结,Agenda,什么是需求,如何使用,UML,对需求建模,需求建模实例,本章小结,需求,导致项目失败的罪魁祸首,根据,Standish Group,对,23000,个项目进行的研究结果表明，,28%,的项目彻底失败，,46%,的项目超出经费预算或者超出工期，只有约,26%,的项目获得成功。
2、,而在于这些高达,74%,的不成功项目中，有约,60%,的失败是源于需求问题。,也就是说，有近,45%,的项目最终因为需求的问题最终导致失败。,我们在哪重重摔了一跤,在,Standish Group,的报告中总结了导致项目失败的最重要的,8,大原因中，有,5,个与需求相关：,不完整的需求；,没有用户的介入；,不实际的客户期望；,需求和规范的变理；,提供了不再需要的,软件需求曾经让我们如此狼狈,需求的定义,需求层次,内容,业务需求,反映组织机构或客户对系统、产品高层次的目标要求。通常问题定义就是业务需求,用户需求,描述用户使用产品必须要完成什么任务，怎么完成，通常是在问题定义的基础上进用户访谈、
3、调查，对用户使用的场景进行整理，从而建立从用户角度的需求,系统需求,从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其它非功能需求，还有设计约束,需求工程,需求开发活动,需求开发与需求管理的分界线,需求捕获,明确业务需求：业务需求是整个系统最为宏观层面的东西，也就是“项目的目标”；通常来说，业务需求是构建在“项目发起人”的脑子里的；“业务需求”可以分为“产品,/,项目目标”和“子目标描述”两个方面的内容,理解业务流程：,-,若项目较大或者业务较陌生：应进行业务建模；,-,如果业务较陌生：聘请领域专家，领域培训；,-,如果术语较多，易于混淆：业务术语表,-,无论如何，都
4、应该建立跨部门职能流程图,需求捕获,明确用户需求：,-What,（收集什么信息）,-Where,（从哪收集）,-How,（如何收集）,捕获技术,优点,缺点,用户访谈,直接有效、灵活、深入，主要技术,占用时间长，信息面窄、较片面,用户调查,面广、可以获得更多反馈,不够深入，容易形式主义、失真,现场观摩,容易建立直接的认识,消耗时间长，易失真,文档考古,能够详细、直观对数据流细节进行分析,易陷入文山书海，甚至产生误导,联合开发,直接的头脑风暴，可以击破需求盲点,成本高，需要较高的控制技巧,Agenda,什么是需求,如何使用,UML,对需求建模,需求建模实例,本章小结,用例模型,组织需求,用例特性,
5、-,用例描绘的场景（或事件流）展示了参与者如何使用系统。这都应基于系统要完成的任务及其重要性来决定如何确定主要场景、次要场景，以及需要多少场景,|-,用例的粒度问题很关键，既不能太大也不能够太小,测试项,含义,说明,W,What to do,用例是否描述了应用做什么？而非如何做？,A,Actors point of view,用例的描述是否体现了参与者的视角？,V,Value for the actor?,用例是否对参与者有价值？,E,Entire scenario,用例描述时间流是否为一个完整的场景？,用例模型,组织需求,用例建模工作流,-,识别参与者,-,寻找用例,-,描述参与者和用例的交
6、互方式,-,用包来组织用例和参与者（可选）,-,通过用例图表示用例模型,-,细化用例模型,-,评估用例模型,类模型,概念模型,概念模型也称为领域模型，通常把业务建模生成的称为领域模型，而无专门的业务建模生成的称为概念模型,建立概念模型的目的是帮助开发团队理解问题领域的各种概念、各种名词、以及它们之间的各种关系，它的主要表现方式就是类图,在构建这个模型时，最主要的工作是找出相关的类，然后明明类之间的关联关系，必要时加入一些多重性描述和业务规则约束,交互模型,描述事件流,在需求阶段的交互模型是一个起点，随着分析和设计工作的开展，该模型将不断的精化和修正,可借助,Robustness,分析来推导出交
7、互模型,交互模型中一般只包含概念模型中的实体对象和分析模型中的边界对象，其目标只是帮助分析人员理清整个事件流，而控制对象、设计类的引入都将在后续阶段进行,并非一定要为用例模型中的所有用例构建交互模型，关键在于“是否需要”,可借助状态图表示一些对象状态的变迁及用户界面设计，还可以借助活动图来理解活动与活动之间的控制流,Agenda,什么是需求,如何使用,UML,对需求建模,需求建模实例,本章小结,确定业务需求,确定业务需求,确定业务需求,为开发人员提供一个,PSP,工具，简化时间记录工作；同时提供数据使用的工具，帮助开发人提高估算能力。,需求捕获,需求捕获,获取需求特性表,编号,特性,FEAT0
8、1,研发经理能够创建项目、指定或修改项目经理、删除尚未分配工作任务的项目,FEAT02,项目经理可以对项目设置工作包，工作包允许多级嵌套，它只用来组织工作任务,FEAT03,项目经理可以为开发人员指派工作任务，工作任务属于特定的工作包,FEAT04,项目经理在分配工作任务时，能够查阅开发人员的日程安排表，可以按开发人员查询、也可按日程查询,FEAT05,开发人员接到任务时，通过系统填写计划时间（计划开始时间和计划结束时间），项目经理确认后，更新日程安排表,FEAT06,开发人员可以查询相近工作任务的历史数据（估算数据、实际数据）,FEAT07,开发人员任务执行将超计划时，应报告项目经理，项目经
9、理通过系统更新其日程表,FEAT08,当任务完成之后，项目经理负责,Close,任务，并填入实际的完成情况（,KLOC,、实际结束时间）,FEAT09,开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”，在停止时，填入任务编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、暂停时间、停止时间、总时长、有效时长（总时长,-,中断时长）,FEAT10,开发人员可以根据任务编号、关键字、起止时间进行分类组合查询与统计,FEAT11,时间记录程序会自动连接服务器，完成时间日志上传的工作，未能连接服务器，则在本机暂存时间日志,FEAT12,项目经理可以按项目、
10、任务、关键字统计实际工作时长、产能,FEAT13,研发经理及管理层可以按个人、任务、项目、关键字查看工作时长、统计产能,建立概念模型,发现类,研发经理,项目,项目经理,工作任务 工作包,开发人员,日程安排表,计划时间,历史数据 估算数据,实际数据,任务编号 工作关键字 开始时间 暂停时间,停止时间 总时长 有效时长,服务器 产能,管理层,时间日志,项目 工作任务 工作包 开发人员,日程安排表 时间日志,建立概念模型,关联分析,建立概念模型,职责分析,建立用例模型,识别参与者,建立用例模型,合并特性获得用例,参与者,特性,用例,开发人员,FEAT05.,开发人员接到任务时，应通过系统填写计划时间
11、（计划开始时间和计划结束时间），项目经理确认后，更新日程安排表,UC01.,填写任务计划,FEAT06.,开发人员可以查询相近工作任务的历史数据（估算数据、实际数据）,FEAT10.,开发人员可以根据任务编号、关键字、起止时间进行分类组合查询与统计,UC02.,查询历史任务数据,(UC01,的扩展,),FEAT09.,开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”，在停止时，填入任务编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、暂停时间、停止时间、总时长、有效时长（总时长,-,中断时长）,FEAT11.,时间记录程序会自动连接服务器，完成时
12、间日志上传的工作，未能连接服务器，则在本机暂存时间日志,UC03.,记录时间日志,建立用例模型,合并特性获得用例,项目经理,FEAT02.,项目经理可以对项目设置工作包，工作包允许多级嵌套，它只用来组织工作任务,UC04.,设置工作包,FEAT03.,项目经理可以为开发人员指派工作任务，工作任务属于特定的工作包,FEAT04.,项目经理在分配工作任务时，能够查阅开发人员的日程安排表，可以按开发人员查询、也可按日程查询,UC05.,分配工作任务,UC5A.,查看日程安排,(,扩展用例,),FEAT07.,开发人员任务执行将超计划时，应报告项目经理，项目经理通过系统更新其日程表,UC06.,更新日
13、程表,FEAT08.,当任务完成之后，项目经理负责,Close,任务，并填入实际的完成情况（,KLOC,、实际结束时间）,UC07.,关闭工作任务,FEAT12.,项目经理可以按项目、任务、关键字统计实际工作时长、产能,UC08.,统计项目产能,研发经理,FEAT01.,研发经理能够创建项目、指定或修改项目经理、删除尚未分配工作任务的项目,UC09.,管理项目信息,管理层,FEAT13.,研发经理及管理层可以按个人、任务、项目、关键字查看工作时长、统计产能,UC10.,统计团队产能,建立用例模型,绘制用例图,建立用例模型,简要描述用例,用例编号,UC01,用例名称,填写任务计划,用例概述,开发
14、人员对项目经理安排给自己的工作任务进行计划，填入计划开始时间和计划完成时间。,主参与者,开发人员,补充说明,在填入计划开始时间和计划完成时间时，开发人员可以查询与该任务的关键字相关的历史任务的数据。,建立用例模型,划分用例优先级,优先级,用例,说明,1,UC11.,登录系统,系统使用的基础，并且可复用原有资源,UC09.,管理项目信息,UC04.,设置工作包,UC05.,分配工作任务,UC01.,填写任务计划,任务管理的完整流程，是记录时间日志的基础,UC03.,记录时间日志,系统核心功能,2,UC07.,关闭工作任务,只是对任务信息进行更新，重要性次之,UC06.,更新日程表,UC5A.,查
15、看日程安排,对日程安排进行优化，使任务安排合理化,3,UC02.,查询历史任务数据,UC08.,统计项目产能,UC10.,统计团队产能,对系统记录的时间记录进行有效的利用，必须有前面的信息才能够开发,UC12.,管理用户,前期可以通过直接往数据库中写值的方式进行使用，最后提供界面操作即可,建立用例模型,详细描述用例,用例编号,UC03,用例名称,记录时间日志,用例概述,开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”等功能，在停止时，填入任务编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、暂停时间、停止时间、总时长、有效时长（总时长,-,中断时
16、长）。,主参与者,开发人员,前置条件,用户进入“记录时间日志”程序,后置条件,将本次时间日志存入数据库,基本事件流,步骤,活动,1,系统显示“开始”、“暂停”和“停止”按钮，但仅“开始”可用,2,用户点击“开始”，系统记录开始时间，并将“开始”置为不可用，使“暂停”和“停止”按钮可用,3,用户点击“停止”按钮，系统记录停止时间，并统计暂时时间、暂停次数、总时长、有效时长，并要求用户选择任务编号、输入工作关键字和相关信息。填写完成后，点击确定，用例完成。,扩展事件流,3a,在此期间，若用户点击“暂停”按钮，系统则记录暂停开始时间，并使暂停次数增加,1,次，并使“暂停”按钮变为“恢复”，使“停用”按钮不可用,3a1,当用户点击“恢复”按钮，用当前时间减去暂停开始时间得到本次暂停时间，并累加到“暂停时间”时间中，并使“恢复”按钮变为“暂停”，使“停用”按钮恢复可用,规则与约束,时间记录程序应以离线式工作，该程序会自动连接服务器，完成时间日志上传的工作，如果未能连接服务器，则在本机暂存时间日志,建立交互,/,状态模型,用户界面设计,Agenda,什么是需求,如何使用,UML,对需求建模,需求建
《UML面向对象建模基础》需求建模基础与实例课件
