Use Case 入门
什么是 Use Case
Use Case 是一种在开发新系统或者软件改造时捕获潜在需求的技术。每个用例提供了一个或多个场景,该场景揭示了系统是如何同最终用户或其它系统交互的,从而获得一个明确的业务目标。它描述的是一个操作,而不是一个功能。
为什么需要 Use Case
传统的软件模型设计喜欢在需求分析把业务分解成功能模块,这样的弊端就是混淆了需求和设计的界限,因为功能模块的划分牵涉到系统的概要设计。
与功能模块不同的是,用例不是站在开发者的角度,而是站在用户的角度来分解系统,因为用户并不想了解系统的内部结构和设计,他们关心的是系统的服务,即系统是如何去操作的,这就是用例的基本思想。
和 User Story 的区别
User Story 描述对用户或客户有价值的功能,只是需求描述,而不是详细的需求规范。
Use Case 在不展现一个系统或子系统内部结构的情况下,对系统或子系统的某个连贯的功能单元的定义和描述。
如何书写 Use Case
用例描述文档的书写是系统分析人员对用户需求的深刻理解的体现。是后期时序图和实际开发的重要依据。也可以对作为项目估算的依据。要避免技术术语,取而代之的是最终用户或者领域专家的语言。
Use Case 文档前的准备
Use Case 文档的目标
- 确保能够解决用户的所有问题
- 把用户的需求真正地反应到商业模型
- 对以后的设计和开发过程提供说明和框架
Use Case 文档的内容模板
- 首先有用例名称:一般是模块名称或者模块中功能点的名称。
- 其次文档变更记录(Revision History) - 包含 Date, Version, Description, Author。
- 本文部分包含如下:
- 基本描述(Brief Description) - 简要介绍该用例的作用和目的。比如此用例的使用者是谁、使用者所要做的操作。
- 前置条件(Pre-Condition) - 描述该用例执行前所要满足的条件和系统必须所处的状态。比如用例B执行前,必须先执行A,则用例的前置条件是执行A。
- 事后状态(Post-Condition) - 用例执行完毕后系统可能处于的一组状态。
- 事件流(Flow of Event)
- 基本流程(Basic Flows) - 用户操作该用例的基本流程 (是后期时序图的主要参考)
- 选择性流程(Alternative Flows) - 在操作主要流程过程中,出现的一些分支流程 (是后期时序图的主要参考)
- 特别需求(Special Requirement) - 描述与该用例相关的非功能性需求。
- 包括性能、可靠性、可用性和可扩展性等和设计约束
- 所使用的操作系统、开发工具等
- 对一些细微功能点进行描述,比如用户身份验证规则、订单号码产生规则、是否需要SSL加密等等 。
- 使用界面(User Interface) - 根据需求制作的UI,及其对UI中栏位进行的说明。
- 附加资讯(Addition Information) - 一些商务逻辑的描述 (可以把系统逻辑试图 Logic View 放到这里)
基本流的描述一般按照这样的格式:
- 每个步骤都有数字编号来表明它的先后顺序
- 每个步骤都有简短的标题来概括它的内容
- 每个步骤要详细描述参与者跟系统之间的交互,一般按照正反两个方面来描述
备选流除了包括基本流类似的描述外,还包括:
- 起点:备选流从事件流的哪一步开始
- 条件:在什么条件下触发
- 动作:备选流下系统采取了哪些操作
- 恢复:备选流结束后,用例如何继续
什么情况下可以削产品经理
- 基本流程和选择性流程描述的不够清楚或者不够详细
- 基本流程描述中不能体现出明确的对象
- 其它事件流有遗漏
因为这属于他 对需求理解的不够透彻,分析的不够彻底。
例子
名称 |
内容 |
用例名称 |
网站公告发布 |
用例标识号 |
202 |
参与者 |
负责人 |
基本描述 |
负责人用来填写和修改家教网站首页的公告,公告最终显示在家教网站的首页上。 |
前置条件 |
负责人已经登陆家教网站管理系统 |
基本流程 |
1. 负责人鼠标点击“修改公告”按钮 2. 系统出现一个文本框,显示着原来的公告内容 3. 负责人可以在文本框上修改公告,也可以完全删除,重新写新的公告 4. 负责人编辑完文本框,按“提交”按钮,首页公告就被修改 5. 用例终止 |
选择性流程 A1 |
在按“提交”按钮之前,负责人随时可以按“返回”按钮,文本框的任何修改内容都不会影响网站首页的公告 |
异常流程 |
1. 提示错误信息,负责人确认 2. 返回到管理系统主页面 |
事后状态 |
网站首页的公告信息被修改 |
参考
延伸阅读