什么是需求如何使用UML对需求建模需求建模实例本章小结.ppt

《UML分析与设计》 需求建模基础与实例 授课人：唐一韬 知识图谱 要点 什么是需求 如何使用UML对需求建模 需求建模实例 本章小结 什么是需求 如何使用UML对需求建模 需求建模实例 本章小结 要点 需求—导致项目失败的罪魁祸首 根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。 而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。 也就是说，有近45%的项目最终因为需求的问题最终导致失败。 我们在哪重重摔了一跤 在Standish Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关： 不完整的需求； 没有用户的介入； 不实际的客户期望； 需求和规范的变理； 提供了不再需要的 需求的定义 需求层次 内容 业务需求 反映组织机构或客户对系统、产品高层次的目标要求。通常问题定义就是业务需求 用户需求 描述用户使用产品必须要完成什么任务，怎么完成，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求 系统需求 从系统的角度来说明软件的需求，它就包括了用特性说明的功能需求，质量属性以及其它非功能需求，还有设计约束 软件需求曾经让我们如此狼狈 需求工程 需求开发活动 需求开发与需求管理的分界线 需求捕获 明确业务需求：业务需求是整个系统最为宏观层面的东西，也就是“项目的目标” ；通常来说，业务需求是构建在“项目发起人”的脑子里的 ；“业务需求”可以分为“产品/项目目标”和“子目标描述”两个方面的内容 理解业务流程：-- 若项目较大或者业务较陌生：应进行业务建模；-- 如果业务较陌生：聘请领域专家，领域培训；-- 如果术语较多，易于混淆：业务术语表-- 无论如何，都应该建立跨部门职能流程图 需求捕获 明确用户需求：-- What（收集什么信息）-- Where（从哪收集）-- How（如何收集） 捕获技术 优点 缺点 用户访谈 直接有效、灵活、深入，主要技术 占用时间长，信息面窄、较片面 用户调查 面广、可以获得更多反馈 不够深入，容易形式主义、失真 现场观摩 容易建立直接的认识 消耗时间长，易失真 文档考古 能够详细、直观对数据流细节进行分析 易陷入文山书海，甚至产生误导 联合开发 直接的头脑风暴，可以击破需求盲点 成本高，需要较高的控制技巧 什么是需求 如何使用UML对需求建模 需求建模实例 本章小结 要点 用例模型—组织需求 用例特性--用例描绘的场景（或事件流）展示了参与者如何使用系统。这都应基于系统要完成的任务及其重要性来决定如何确定主要场景、次要场景，以及需要多少场景|--用例的粒度问题很关键，既不能太大也不能够太小 测试项 含义 说明 W What to do 用例是否描述了应用做什么？而非如何做？ A Actor’s point of view 用例的描述是否体现了参与者的视角？ V Value for the actor? 用例是否对参与者有价值？ E Entire scenario 用例描述时间流是否为一个完整的场景？ 用例模型—组织需求 用例建模工作流-- 识别参与者-- 寻找用例-- 描述参与者和用例的交互方式-- 用包来组织用例和参与者（可选）-- 通过用例图表示用例模型-- 细化用例模型-- 评估用例模型 类模型—概念模型 概念模型也称为领域模型，通常把业务建模生成的称为领域模型，而无专门的业务建模生成的称为概念模型 建立概念模型的目的是帮助开发团队理解问题领域的各种概念、各种名词、以及它们之间的各种关系，它的主要表现方式就是类图 在构建这个模型时，最主要的工作是找出相关的类，然后明明类之间的关联关系，必要时加入一些多重性描述和业务规则约束 交互模型—描述事件流 在需求阶段的交互模型是一个起点，随着分析和设计工作的开展，该模型将不断的精化和修正 可借助Robustness分析来推导出交互模型 交互模型中一般只包含概念模型中的实体对象和分析模型中的边界对象，其目标只是帮助分析人员理清整个事件流，而控制对象、设计类的引入都将在后续阶段进行 并非一定要为用例模型中的所有用例构建交互模型，关键在于“是否需要” 可借助状态图表示一些对象状态的变迁及用户界面设计，还可以借助活动图来理解活动与活动之间的控制流 什么是需求 如何使用UML对需求建模 需求建模实例 本章小结 要点 确定业务需求 确定业务需求 确定业务需求 为开发人员提供一个PSP工具，简化时间记录工作；同时提供数据使用的工具，帮助开发人提高估算能力。 需求捕获 需求捕获 获取需求特性