需求建模实例.ppt

在业务需求充分理解并且收集了最为本质的用户需求之后就可以开始需求分析了，并不是等到需求捕获完全做完之后才开始。 分析的目的是为了理解、整理、合并这些需求 建模的目的是在理解需求的基础上，绘制出系统蓝图，以便统一认识。 目标：为开发人员提供一个PSP工具，简化时间记录工作；同时提供数据使用的工具，帮助开发人提高估算能力。 发起人：总经理 项目干系人：总经理、研发经理、开发人员 对于工程类项目，通过与项目的发起人、主要的项目干系人来沟通，从根本上理解项目的意义。 对于产品类项目，通过详细的产品规划和市场调查来确定产品对用户能够带来的利益和好处。 在业务需求指引下挖掘用户需求的过程 由于是内部项目，技术顾问已经做了一次关于PSP的培训配合公司的政策，开发人员已经比较支持这个项目，因此沟通比较顺畅。可采用用户访谈和联合开发的形式进行需求捕获。 主要步骤：识别参与者、合并需求获得用例、细化用例描述。 用例描述的细化是随着开发过程的推进迭代进行的。 设计约束：时间记录程序应以离线式工作，该程序会自动连接服务器，完成时间日志上传的工作，如果未能连接服务器，则在本机暂存时间日志。（可在需求建模时确定，也可以在设计阶段确定） 解决方案：将时间日志的上传与记录分离，也就是一直都往本地数据库存储。将上传日志用例作为另外一个用例来建模。这个用例是“记录时间日志”的一个扩展。 对于MIS应用系统的开发而言，建议在需求分析阶段对用户界面进行必要的设计，能够对设计阶段的工作起到指引作用。 通过用户界面的设计，能够更好地与用户达成共识，减少理解上的偏差。是对需求建模的一个有益的补充。 处理规则与约束 用户界面设计 需求建模实例 Agenda 什么是需求 如何使用UML对需求建模 需求建模实例 本章小结 如何使用UML对需求建模 用例模型—组织需求 用例特性 --用例描绘的场景（或事件流）展示了参与者如何使用系统。这都应基于系统要完成的任务及其重要性来决定如何确定主要场景、次要场景，以及需要多少场景。 对于规模较大的系统用例数量应控制在几十个；对规模较小的系统应该控制在10个左右。 --用例的粒度问题很关键，既不能太大也不能够太小 用例描述事件流是否为一个完整的场景？ Entire scenario E 用例是否对参与者有价值？ Value for the actor? V 用例的描述是否体现了参与者的视角？ Actor’s point of view A 用例是否描述了应该做什么？而非如何做？ What to do W 说明 含义 测试项 用例模型—组织需求 用例建模工作流 前置条件：需求捕获活动取得阶段性成果 主要参与者：分析人员 次要参与者：设计人员、客户与项目干系人代表 输入：需求捕获生成的特性列表、业务模型或概念模型 输出：用例模型 用例模型—组织需求 用例建模工作步骤-- 识别参与者：参与者的识别是个迭代的过程 -- 寻找用例：结合需求捕获结果来考虑各个参与者对系统的需求 -- 描述参与者和用例的交互方式：导航方向（信号传递方向）-- 用包来组织用例和参与者（可选）：同一个包的用例与同一个参与者交互，相互之间具有包含或扩展关系-- 通过用例图表示用例模型-- 细化用例模型：编写用例规格说明 -- 评估用例模型：WAVE测试和客户验证（是否确定所有必要用例；是否确定任何不必要用例；是否按正确顺序执行各用例的行为；各个用例的事件流是否达到现阶段可能具备的完整性；用例模型的说明是否明白易懂） 类模型—概念模型 概念模型也称为领域模型，通常把业务建模生成的称为领域模型，而无专门的业务建模生成的称为概念模型 建立概念模型的目的是帮助开发团队理解问题领域的各种概念、各种名词、以及它们之间的各种关系，它的主要表现方式就是类图 在构建这个模型时，最主要的工作是找出相关的类，然后明明类之间的关联关系，必要时加入一些多重性描述和业务规则约束 交互模型—描述事件流 文字描述直观、易懂和便于跟用户沟通。但具有歧义性和非规格化，会对开发工作带来一定的困扰。 在需求阶段的交互模型是一个起点，随着分析和设计工作的开展，该模型将不断的精化和修正 可借助Robustness分析来推导出交互模型 交互模型中一般只包含概念模型中的实体对象和分析模型中的边界对象，其目标只是帮助分析人员理清整个事件流，而控制对象、设计类的引入都将在后续阶段进行 并非一定要为用例模型中的所有用例构建交互模型，关键在于“是否需要” 可借助状态图表示一些对象状态的变迁及用户界面设计，还可以借助活动图来理解活动与活动之间的控制流 Agenda 什么是需求 如何使用UML对需求建模 需求建模实例 本章小结 确定业务需求 确定业务需求 确定业务需求 确定业务需求 需求捕获 需求捕获 需