需求建模实例

建立用例模型—划分用例优先级
优先级 1 UC11.登录系统
用例
说明 系统使用的基础，并且可复用原有资源
UC09.管理项目信息 UC04.设置工作包 任务管理的完整流程，是记录时间日志的 UC05.分配工作任务 UC01.填写任务计划 基础 UC03.记录时间日志 系统核心功能
2
UC07.关闭工作任务
需求捕获
在业务需求指引下挖掘用户需求的过程 由于是内部项目，技术顾问已经做了一次关于PSP的 培训配合公司的政策，开发人员已经比较支持这个项 目，因此沟通比较顺畅。可采用用户访谈和联合开发 的形式进行需求捕获。
需求捕获
需求捕获
获取需求特性表
编号 FEAT01 特性 研发经理能够创建项目、指定或修改项目经理、删除尚未分配工作任务的项目
建立用例模型—绘制用例图
建立用例模型—简要描述用例
用例编号 UC01 用例名称 填写任务计划 用例概述 开发人员对项目经理安排给自己的工作任务进行计划，填入计 划开始时间和计划完成时间。 主参与者 开发人员 补充说明 在填入计划开始时间和计划完成时间时，开发人员可以查询与 该任务的关键字相关的历史任务的数据。
建立用例模型—识别参与者
根据需求特性表识别参与者；检查参与者之间是否存在关系
建立用例模型—合并特性获得用例
参与者 开发人员 特性 FEAT05.开发人员接到任务时，应通过系统填写计划时间（ 计划开始时间和计划结束时间），项目经理确认后，更新 日程安排表 用例 UC01.填写任务计划
FEAT06.开发人员可以查询相近工作任务的历史数据（估算 数据、实际数据） FEAT10.开发人员可以根据任务编号、关键字、起止时间进 行分类组合查询与统计 FEAT09.开发人员可以随时记录自己的时间，提供“开始计 时”、“暂停计时”、“停止计时”，在停止时，填入任 务编号（在线则选择）、工作关键字（以逗号分隔的多个 ），自动生成开始时间、暂停时间、停止时间、总时长、 有效时长（总时长-中断时长） FEAT11.时间记录程序会自动连接服务器，完成时间日志上 传的工作，未能连接服务器，则在本机暂存时间日志
需求建模实例
Agenda
• • • •
什么是需求 如何使用UML对需求建模
需求建模实例
本章小结
如何使用UML对需求建模
在业务需求充分理解并且收集了最为本质的用户需求 之后就可以开始需求分析了，并不是等到需求捕获完 全做完之后才开始。 分析的目的是为了理解、整理、合并这些需求 建模的目的是在理解需求的基础上，绘制出系统蓝图， 以便统一认识。
FEAT06
FEAT07 FEAT08 FEAT09
开发人员可以查询相近工作任务的历史数据（估算数据、实际数据）
开发人员任务执行将超计划时，应报告项目经理，项目经理通过系统更新其日程表 当任务完成之后，项目经理负责Close任务，并填入实际的完成情况（KLOC、实际结束时间） 开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”，在停止时，填入任务 编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、暂停时间、停止时间、总时长 、有效时长（总时长-中断时长） 开发人员可以根据任务编号、关键字、起止时间进行分类组合查询与统计 时间记录程序会自动连接服务器，完成时间日志上传的工作，未能连接服务器，则在本机暂存时间日志 项目经理可以按项目、任务、关键字统计实际工作时长、产能 研发经理及管理层可以按个人、任务、项目、关键字查看工作时长、统计产能
•
用例模型—组织需求
•
用例建模工作流
• • • •
•
前置条件：需求捕获活动取得阶段性成果
主要参与者：分析人员
次要参与者：设计人员、客户与项目干系人代表 输入：需求捕获生成的特性列表、业务模型或概念 模型 输出：用例模型
用例模型—组织需求
•
用例建模工作步骤
-- 识别参与者：参与者的识别是个迭代的过程
类模型—概念模型
•
•
•
概念模型也称为领域模型，通常把业务建模生成的称为 领域模型，而无专门的业务建模生成的称为概念模型
建立wenku.baidu.com念模型的目的是帮助开发团队理解问题领域的各 种概念、各种名词、以及它们之间的各种关系，它的主 要表现方式就是类图
在构建这个模型时，最主要的工作是找出相关的类，然 后明明类之间的关联关系，必要时加入一些多重性描述 和业务规则约束
工作包
开发人员
建立概念模型—关联分析
建立概念模型—职责分析
建议召集一些主要的分析、设计 人员在白板上共同构建概念模型。 对于规模比较大的系统，可以先 根据业务的关联关系将其先分解 成小的子系统，然后在通过这种 流程进行建模。
建立用例模型
主要步骤：识别参与者、合并需求获得用例、细化用 例描述。 用例描述的细化是随着开发过程的推进迭代进行的。
• •
• •
Agenda
• • • •
什么是需求 如何使用UML对需求建模
需求建模实例
本章小结
确定业务需求
确定业务需求
确定业务需求
确定业务需求
目标：为开发人员提供一个PSP工具，简化时间记录 工作；同时提供数据使用的工具，帮助开发人提高估 算能力。 发起人：总经理 项目干系人：总经理、研发经理、开发人员 对于工程类项目，通过与项目的发起人、主要的项目 干系人来沟通，从根本上理解项目的意义。 对于产品类项目，通过详细的产品规划和市场调查来 确定产品对用户能够带来的利益和好处。
FEAT02
FEAT03 FEAT04 FEAT05
项目经理可以对项目设置工作包，工作包允许多级嵌套，它只用来组织工作任务
项目经理可以为开发人员指派工作任务，工作任务属于特定的工作包 项目经理在分配工作任务时，能够查阅开发人员的日程安排表，可以按开发人员查询、也可按日程查询 开发人员接到任务时，通过系统填写计划时间（计划开始时间和计划结束时间），项目经理确认后，更新日程 安排表
UC06.更新日程表 UC5A.查看日程安排
只是对任务信息进行更新，重要性次之
对日程安排进行优化，使任务安排合理化
3
UC02.查询历史任务数据 对系统记录的时间记录进行有效的利用， UC08.统计项目产能 UC10.统计团队产能 必须有前面的信息才能够开发 UC12.管理用户 前期可以通过直接往数据库中写值的方式 进行使用，最后提供界面操作即可
交互模型—描述事件流
• •
文字描述直观、易懂和便于跟用户沟通。但具有歧义性和非规格化， 会对开发工作带来一定的困扰。 在需求阶段的交互模型是一个起点，随着分析和设计工作的开展， 该模型将不断的精化和修正 可借助Robustness分析来推导出交互模型 交互模型中一般只包含概念模型中的实体对象和分析模型中的边界 对象，其目标只是帮助分析人员理清整个事件流，而控制对象、设 计类的引入都将在后续阶段进行 并非一定要为用例模型中的所有用例构建交互模型，关键在于“是 否需要” 可借助状态图表示一些对象状态的变迁及用户界面设计，还可以借 助活动图来理解活动与活动之间的控制流
用户界面设计
对于MIS应用系统的开发而言，建议在需求分析阶段 对用户界面进行必要的设计，能够对设计阶段的工作 起到指引作用。 通过用户界面的设计，能够更好地与用户达成共识， 减少理解上的偏差。是对需求建模的一个有益的补充。
UC02.查询历史任务 数据(UC01的扩展)
UC03.记录时间日志
建立用例模型—合并特性获得用例
项目经 理 FEAT02.项目经理可以对项目设置工作包，工作包允许多级嵌 套，它只用来组织工作任务 FEAT03.项目经理可以为开发人员指派工作任务，工作任务属 于特定的工作包 FEAT04.项目经理在分配工作任务时，能够查阅开发人员的日 程安排表，可以按开发人员查询、也可按日程查询 FEAT07.开发人员任务执行将超计划时，应报告项目经理，项 目经理通过系统更新其日程表 FEAT08.当任务完成之后，项目经理负责Close任务，并填入 实际的完成情况（KLOC、实际结束时间） FEAT12.项目经理可以按项目、任务、关键字统计实际工作时 长、产能 研发经 理 管理层 FEAT01.研发经理能够创建项目、指定或修改项目经理、删除 尚未分配工作任务的项目 FEAT13.研发经理及管理层可以按个人、任务、项目、关键字 查看工作时长、统计产能 UC04.设置工作包 UC05.分配工作任务 UC5A.查看日程安排 (扩展用例) UC06.更新日程表 UC07.关闭工作任务 UC08.统计项目产能 UC09.管理项目信息 UC10.统计团队产能
建立用例模型—详细描述用例
用例编号 用例名称 用例概述 UC03 记录时间日志 开发人员可以随时记录自己的时间，提供“开始计时”、“暂停计时”、“停止计时”等功能，在 停止时，填入任务编号（在线则选择）、工作关键字（以逗号分隔的多个），自动生成开始时间、 暂停时间、停止时间、总时长、有效时长（总时长-中断时长）。 开发人员 用户进入“记录时间日志”程序 将本次时间日志存入数据库 步骤 1 2 3 活动 系统显示“开始”、“暂停”和“停止”按钮，但仅“开始”可用 用户点击“开始”，系统记录开始时间，并将“开始”置为不可用，使“暂停”和“ 停止”按钮可用 用户点击“停止”按钮，系统记录停止时间，并统计暂时时间、暂停次数、总时长、 有效时长，并要求用户选择任务编号、输入工作关键字和相关信息。填写完成后，点 击确定，用例完成。 在此期间，若用户点击“暂停”按钮，系统则记录暂停开始时间，并使暂停次数增加1 次，并使“暂停”按钮变为“恢复”，使“停用”按钮不可用 当用户点击“恢复”按钮，用当前时间减去暂停开始时间得到本次暂停时间，并累加 到“暂停时间”时间中，并使“恢复”按钮变为“暂停”，使“停用”按钮恢复可用
测试项 W A V E 含义 What to do Actor’s point of view Value for the actor? Entire scenario 说明 用例是否描述了应该做什么？而非如何做？ 用例的描述是否体现了参与者的视角？ 用例是否对参与者有价值？ 用例描述事件流是否为一个完整的场景？
-- 寻找用例：结合需求捕获结果来考虑各个参与者对系统的需求
-- 描述参与者和用例的交互方式：导航方向（信号传递方向） -- 用包来组织用例和参与者（可选）：同一个包的用例与同一个参 与者交互，相互之间具有包含或扩展关系 -- 通过用例图表示用例模型 -- 细化用例模型：编写用例规格说明 -- 评估用例模型：WAVE测试和客户验证（是否确定所有必要用例； 是否确定任何不必要用例；是否按正确顺序执行各用例的行为；各 个用例的事件流是否达到现阶段可能具备的完整性；用例模型的说 明是否明白易懂）
用例模型—组织需求
•
用例特性
•
--用例描绘的场景（或事件流）展示了参与者如何使用系统。 这都应基于系统要完成的任务及其重要性来决定如何确定主要 场景、次要场景，以及需要多少场景。 对于规模较大的系统用例数量应控制在几十个；对规模较小的 系统应该控制在10个左右。 --用例的粒度问题很关键，既不能太大也不能够太小
FEAT10 FEAT11 FEAT12 FEAT13
建立概念模型—发现类
研发经理 开发人员 实际数据 停止时间 管理层
项目 日程安排表 任务编号 总时长 时间日志
项目经理 计划时间 工作关键字 有效时长
工作任务 历史数据 开始时间 服务器
工作包 估算数据 暂停时间 产能
项目 工作任务 日程安排表 时间日志
主参与者 前置条件 后置条件 基本事件流
扩展事件流
3a 3a1
规则与约束
时间记录程序应以离线式工作，该程序会自动连接服务器，完成时间日志上传的工作，如果未能连 接服务器，则在本机暂存时间日志
建立交互模型
建立状态模型
处理规则与约束
设计约束：时间记录程序应以离线式工作，该程序会 自动连接服务器，完成时间日志上传的工作，如果未 能连接服务器，则在本机暂存时间日志。（可在需求 建模时确定，也可以在设计阶段确定） 解决方案：将时间日志的上传与记录分离，也就是一 直都往本地数据库存储。将上传日志用例作为另外一 个用例来建模。这个用例是“记录时间日志”的一个 扩展。