用例(Use Case)是一种描述产品需求的方法,使用用例的方法来描述产品需求的过程就是用例模型,用例模型是由用例图和每个用例的详细描述文档所组成的。在技术和产品的工做领域里都有用例模型的技能知识。技术人员的用例主要是为了方便在多名技术人员协同工做,或者技术人员任务交接时,让参与者更好的理解代码的逻辑结构。产品人员的用例主要是为了方便技术研发和功能测试时,让参与者更好的理解功能的逻辑。安全
用例起源和发展于软件时代的产品研发,后来被综合到UML规范之中,成为一种标准化的需求表述体系。虽然用例在软件研发和技术工做中应用的很是普遍,可是在互联网产品规划和设计中,并不常用,互联网产品的需求表达为了敏捷效率,一般采用原型加产品需求文档。工具
UML是英文Unified Modeling Language的缩写,中文称为统一建模语言或标准建模语言,是用例模型的建模语言,经常使用工具是Microsoft Office Visio。产品用例是一种经过用户的使用场景来获取需求的方式,每一个用例提供了一个或多个场景,该场景说明了产品是如何和最终用户或其它产品互动,也就是谁能够用产品作什么,从而得到一个明确的业务目标。测试
用例图并非画成了图形的用例。用例图包含一组用例,每个用例用椭圆表示,放置在矩形框中;矩形框表示整个系统。矩形框外画如图所示的小人,表示参与者。参与者不必定是人,能够是其它产品、软件或硬件等等。某一参与者与某一用例用线连起来,表示该参与者和该用例有交互。spa
许多人经过UML认识了用例,UML定义为展示用例的图形符号。UML并非为描述用例定义书写格式的标准,所以许多人误认为这些图形符号就是用例自己;然而,图形符号只能给出最简单的一个或一组用例的概要。UML是用例图形符号最流行的标准,可是除了UML标准,用例也有其它的可选择的标准。设计
用例图只是在整体上大体描述了产品所能提供的各类服务,让咱们对于产品的功能有一个整体的认识。除此以外,咱们还须要描述每个用例的详细信息,这些信息应该包含如下内容:orm
用例名称:本用例的名称或者编号开发
行为角色:参与或操做(执行)该用例的角色文档
简要说明:简要的描述一下本用例的需求(做用和目的)原型
前置条件:参与或操做(执行)本用例的前提条件,或者所处的状态产品
后置条件:执行完毕后的结果或者状态
用例描述文档基本上是用文本方式来表述的,为了更加清晰地描述用例,也能够选择使用状态图、流程图或序列图来辅助说明。只要有助于表达的简洁明了,就能够在用例中任意粘贴用户界面和流程的图形化显示方式,或是其它图形。如流程图有助于描述复杂的决策流程,状态转移图有助于描述与状态相关的系统行为,序列图适合于描述基于时间顺序的消息传递。
在互联网产品和设计中,用例的使用愈来愈少,一般有了产品原型再加上功能流程图和功能说明文档就可以将产品需求详细的表述清楚,因此也没有必须撰写用例了。可是在大公司里,每每会追求产品流程的规范性,要求撰写用例,不过在敏捷开发的时候也会采用其它更有效率的方式,不必定非要撰写用例。
用例图描述了系统提供的一个功能单元。用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求,包括基于基本流程的"角色"(actors,也就是与系统交互的其余实体)关系,以及系统内用例之间的关系。用例图通常表示出用例的组织关系--要么是整个系统的所有用例,要么是完成具备功能(例如,全部安全管理相关的用例)的一组用例。要在用例图上显示某个用例,可绘制一个椭圆,而后将用例的名称放在椭圆的中心或椭圆下面的中间位置。要在用例图上绘制一个角色(表示一个系统用户),可绘制一我的形符号。角色和用例之间的关系使用简单的线段来描述