C_需求建模基础与实例

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