软件需求工程3.pptVIP

业务序列图 * 业务序列图 * 业务序列图 * 循序图 * 传入：表示责任 传出：表示协作 检索零件UC的责任有哪些？ 寻找改进点 * 业务序列图 * 寻找改进点 * 业务序列图 * 业务序列图 * 改进点 * 改进点 * 改进点 * * 改进点 * * 改进点 * 水电站财务处业务用例 * 找出改进的流程 如用例：其他部门人员-申报费用中哪些是愿景中提出要改进的地方（业务单元）？ * 水电站财务处用例 * 其他部门人员申报费用---基本路径 * 循序图 消息的方向代表责任不代表数据。 数据流用虚线表示，可以不画。 循序图侧重描述责任如何在业务工人和业务实体之间转移。 画循序图的目的是从图中找改进点。 找改进点就是在找需求。 * 业务建模的步骤 选定业务单元 识别业务执行者 识别业务用例 详述业务用例 建立对象模型 * 业务对象模型 * 申报费用---业务对象模型 * 从业务模型到系统模型 至此业务模型阶段已完成，现在需要把目光从业务模型转到系统模型。 * 业务用例和系统用例 * 一个业务用例和多个系统用例 * 多个业务用例和一个系统用例 * 识别业务用例 * 识别用例 * 识别用例 * 识别用例 * 识别用例 * 表示用例 * 表示用例 * 错误表示 * 用 例 下面哪些是用例？ 1、支持跨行业务 × 这是一个业务规则，限定业务的范围。 2、插入卡片 ×这是一个过程步骤，不是完整的目标。 3、输入密码 ×这是一个过程步骤，不是完整的目标。 4、选择服务 ×这是一个过程步骤，不是完整的目标。 * 用 例 5、取钱 √ 这是一个有效的完整目标。 6、存钱 √ 这是一个有效的完整目标。 7、挂失卡片 √ 这是一个有效的完整目标。 8、交纳费用 √ 这是一个有效的完整目标。 9、三次错误吞没卡片 ×这是一个业务规则，限定业务的范围。 * 用例和功能的误区 一个错误的理解认为用例就是功能的划分和描述。 虽然用例是捕获功能性需求的，但有一个前提条件，即这个功能性需求是从参与者的角度出发的，用例并不是功能。 功能是脱离使用者的愿望而存在的。 * 粒 度 * 粒 度 * 粒 度 * 粒 度 尽量不要用CRUD为用例，因为它们一般不提供价值，过于在乎细节，是从数据库角度进行考虑的。 如果确定为CRUD，则合并为管理***，可以把Create当作主路径，Read，Update，Delete当作其它可选的路径。 * 粒 度 * 业务建模的步骤 选定业务单元 识别业务执行者 识别业务用例 详述业务用例 建立对象模型 * 详述业务用例的可选技术 * 文字 * 书写用例文档 * 详述业务用例---活动图 * 详述业务用例---循序图 * * 详述业务用例 * * 业务序列图 *