需求分析与用例

一、需求分析与用例：需求：就是系统必须提供的能力和必须遵从的条件，包括：功能需求和非功能的需求（性能要求）。需求分析：重要手段是确定和编写用例。用例：是文本形式的情节描述，用于需求的发现和记录。用例会影响后续的OOA/D工作。参与者（Actor）：某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织，例如收银员。场景（Scenario）：是参与者和系统（我们要开发的系统）之间的一系列特定的活动和交互。包括主成功场景和交替场景（主成功场景表示正常功能.；交替场景是如果.）二、用例的目的与形式：用例编写的形式：需求分析早期使用，通常用于主场景（如“管理员向系统提交用户名和密码。系统进行认证。系统向管理员显示功能登录信息”）三、用例编写的格式：用例名称Fyx-001实现名称bur_borrow books用例描述旅客人通过此用例向系统查询并提交订票请求参与者旅客前置条件用户登录界面，通过验证。后置条件1. 创建订票定单2. 更新旅客订票记录主事件流1用户根据以前注册的账号登录系统，计算机显示机票预订界面2.用户选择查询机票，计算机显示查询界面3.用户按出行的始末地以及出现时间查询，计算机显示查询结果4.用户可单选或多选机票，并确认预订。计算机显示确认预订机票清单。5.用户选择确认预订，计算机显示预订机票定单及费用6用户选择提交定单，计算机显示提交结果7.计算机执行后置条件。用例结束备选事件流1.a用户信息不正确1.拒绝登录，用例结束2.a用户选择查看原有定单1.计算机执行主流事件4;3.a用户选择继续订票1.计算机执行2；3.b用户选择放弃1.计算机执行44.a用户选择保存定单1.计算机保存并执行1；4.b用户选择放弃，1.计算机执行1；业务规则可根据自己的实际情况选择订票的数量涉及的业务实体Be_费用记录，Be_机票，Be_订票篮,Be_机票定单,Be_个人信息验证非功能性需求支持各地区的用户补充说明四、如何发现用例：1 选择系统边界2 确定主要参与者3 确定每个主要参与者的目标4 定义满足用户目标的用例，根据其目标对用例命名在真实项目中发现用例，遵循如下思维习惯：调研需求时最先弄清楚有多少部门，多少岗位（参与者），然后找到每一个岗位的业务代表，问他们类似的问题：你平时都做什么？（参与者目标）这件事是谁交办的 ？做完了你需要通知或传达给认证吗？做这件事情你都需要填写些什么表格吗？五、用例关联及一些术语用例彼此之间可能具有联系，比如：处理信用卡支付用例可倾向于为处理销售、处理租金等常见用例的一部分。（1）关联在用例图中，用例和执行者之间的关系用一条连接二者带箭头的连线表示，如图所示，该连线称为关联。它表示了一个执行者和一个用例之间的关系。在用例图中，关联关系只用在执行者和用例之间，用例和用例之间不会存在关联关系。关联关系采用的是单箭头的连线，表示在该关联中执行者是主动的，是执行者启动的用例。如下图所示。（2）包含包含是指一个用例作为另一个用例必需的部分被使用，包含关系是依赖关系的一种。包含关系用一条连接二者带箭头的虚线表示，并在虚线的上面标注include，箭头方向由基本用例指向包含用例，如下图所示。包含的使用场合： 如果多个用例有大量一致的功能，可以将这个功能分解到一个用例中，其他用例和这个用例建立包含关系。 一个用例功能太多，可以使用包含关系建立若干小用例。（3）扩展扩展是指一个用例扩充了另一个用例的功能，但这个扩充功能不是必需的，扩展关系也是依赖关系的一种。扩展关系用一条连接二者带箭头的虚线表示，但在虚线的上面标注的是extend，箭头方向由扩展用例指向基本用例，如下图所示。扩展关系和包含关系的区别。 包含用例是一个完整的用例，它可以独立的存在，也可以单独被执行者所调用。 扩展用例并不是一个完整的用例，它只是由部分扩展功能组成的，它不能独立的存在，必须依赖于基本用例。 （4）泛化 用例间的泛化关系是指一个概念较为抽象的用例可以被一般化为一个或多个概念