需求建模基础和实例.pptVIP

建立用例模型—合并特性获得用例 UC10.统计团队产能 FEAT13.研发经理及管理层可以按个人、任务、项目、关键字查看工作时长、统计产能 管理层 UC09.管理项目信息 FEAT01.研发经理能够创建项目、指定或修改项目经理、删除尚未分配工作任务的项目 研发经理 UC08.统计项目产能 FEAT12.项目经理可以按项目、任务、关键字统计实际工作时长、产能 UC07.关闭工作任务 FEAT08.当任务完成之后，项目经理负责Close任务，并填入实际的完成情况（KLOC、实际结束时间） UC06.更新日程表 FEAT07.开发人员任务执行将超计划时，应报告项目经理，项目经理通过系统更新其日程表 UC05.分配工作任务 UC5A.查看日程安排(扩展用例) FEAT03.项目经理可以为开发人员指派工作任务，工作任务属于特定的工作包 FEAT04.项目经理在分配工作任务时，能够查阅开发人员的日程安排表，可以按开发人员查询、也可按日程查询 UC04.设置工作包 FEAT02.项目经理可以对项目设置工作包，工作包允许多级嵌套，它只用来组织工作任务 项目经理 建立用例模型—绘制用例图 建立用例模型—简要描述用例 在填入计划开始时间和计划完成时间时，开发人员可以查询与该任务的关键字相关的历史任务的数据。 补充说明 开发人员 主参与者 开发人员对项目经理安排给自己的工作任务进行计划，填入计划开始时间和计划完成时间。 用例概述 填写任务计划 用例名称 UC01 用例编号 《UML面向对象建模基础》 需求建模基础与实例 知识图谱 Agenda 什么是需求 如何使用UML对需求建模 需求建模实例 本章小结 Agenda 什么是需求 如何使用UML对需求建模 需求建模实例 本章小结 需求—导致项目失败的罪魁祸首 根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。 而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。 也就是说，有近45%的项目最终因为需求的问题最终导致失败。 我们在哪重重摔了一跤 在Standish Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关： 不完整的需求； 没有用户的介入； 不实际的客户期望； 需求和规范的变理； 提供了不再需要的 软件需求曾经让我们如此狼狈 需求的定义 从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其它非功能需求，还有设计约束 系统需求 描述用户使用产品必须要完成什么任务，怎么完成，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求 用户需求 反映组织机构或客户对系统、产品高层次的目标要求。通常问题定义就是业务需求 业务需求 内容 需求层次 需求工程 需求开发活动 需求开发与需求管理的分界线 需求捕获 明确业务需求：业务需求是整个系统最为宏观层面的东西，也就是“项目的目标” ；通常来说，业务需求是构建在“项目发起人”的脑子里的 ；“业务需求”可以分为“产品/项目目标”和“子目标描述”两个方面的内容 理解业务流程：-- 若项目较大或者业务较陌生：应进行业务建模；-- 如果业务较陌生：聘请领域专家，领域培训；-- 如果术语较多，易于混淆：业务术语表-- 无论如何，都应该建立跨部门职能流程图 需求捕获 明确用户需求：-- What（收集什么信息）-- Where（从哪收集）-- How（如何收集） 成本高，需要较高的控制技巧 直接的头脑风暴，可以击破需求盲点 联合开发 易陷入文山书海，甚至产生误导 能够详细、直观对数据流细节进行分析 文档考古 消耗时间长，易失真 容易建立直接的认识 现场观摩 不够深入，容易形式主义、失真 面广、可以获得更多反馈 用户调查 占用时间长，信息面窄、较片面 直接有效、灵活、深入，主要技术 用户访谈 缺点 优点 捕获技术 Agenda 什么是需求 如何使用UML对需求建模 需求建模实例 本章小结 用例模型—组织需求 用例特性--用例描绘的场景（或事件流）展示了参与者如何使用系统。这都应基于系统要完成的任务及其重要性来决定如何确定主要场景、次要场景，以及需要多少场景|--用例的粒度问题很关键，既不能太大也不能够太小 用例描述时间流是否为一个完整的场景？ Entire scenario E 用例是否对参与者有价值？ Value for the actor? V 用例的描述是否体现了参与者的视角？ Actor’s point of view A 用例是否描述了应用做什么？而非如何做？ What to do W 说明 含义 测