用例.docx
- 文档编号:12233897
- 上传时间:2023-04-17
- 格式:DOCX
- 页数:16
- 大小:51.84KB
用例.docx
《用例.docx》由会员分享,可在线阅读,更多相关《用例.docx(16页珍藏版)》请在冰豆网上搜索。
用例
用例(UseCase)
是一种被广泛使用的用于发现和记录需求(特别是功能需求)的机制。
写出用例是一种最好的理解和描述需求的技巧。
6.1目标和情节
客户和最终用户都有自己的目标(需要),并希望计算机系统能够帮助他们实现这些目标。
用例可以为项目相关人员提供一种简单而易懂的机制来了解目标和系统需求。
用例就是如何使用系统来达到目标的一组情节。
简洁用例例:
处理销售:
一个顾客携带采购的商品来到收费口,收银员使用POST系统记录每件商品,系统给出商品的清单和累加值,顾客输入支付信息,系统对信息进行验证和记录。
系统更新库存信息,顾客从系统得到收据,然后携带商品离开。
6.2背景
1986年Jacobson提出,Cockburn也作出贡献。
6.3用例和附加价值
参与者(actor):
是具有行为能力的事物,可以是一个人、计算机系统或组织;
场景(scenario):
是参与者和被讨论系统之间的一系列特定的活动和交互,通常被称为“用例的实例”。
场景是使用系统的一个特定情节或用例的一条执行路径。
用例就是描述参与者使用系统来达成目标的时候一组相关的成功场景和失败的场景的集合。
处理返回
主要成功场景:
一个顾客携带商品到达收费口。
收银员使用POST系统记录并返回每件商品的信息。
。
。
。
。
。
替代场景:
如果信用卡授权被拒绝,则通知顾客并询问是否可以采用其他支付方式。
用例分析的关键是专注于“怎样才能使系统为用户提供可观察的数值,或帮助用户实现他们的目标”,而不是仅仅将系统需求用特性和功能的细目清单罗列出来。
6.4用例和功能性需求
用例就是需求,用例是功能性需求。
用例的主要思想:
为功能性需求写出用例,从而降低老式的详尽的特性列表的重要性或减少这种列表的使用。
6.5用例的类型和格式
黑箱用例:
描述系统具有那些职责,对系统的内部工作、组件或设计方法都不进行详细描述。
形式化类型
●简洁用例:
简明扼要的一段概括,通常用在主要成功场景。
●临时用例:
非正式的段落格式,用一段话来说明几个不同的场景。
●详述用例:
所有的步骤和其中的变化都被详细写出;还包括前置条件和后置条件。
6.6详述用例实例
用例1:
处理销售
主要参与者:
收银员
项目相关人员及其兴趣:
●收银员:
希望能够准确、快速的输入,而且没有支付错误,因为收银员如果少收了钱,就要从他的薪水中扣除相应的金额。
●售货员:
希望自动更新销售提成。
●顾客:
希望购买过程能够省力,并得到快速的服务,希望得到购买证明,以便退货。
●公司:
希望准确地记录交易,并满足顾客的要求。
希望保证支付授权服务信息被记录。
希望有一定的容错性,即使某些服务暂时不可用(如远程信用卡验证)也能允许收款。
希望能够自动、快速的更新帐目和库存信息。
●政府税务机关:
希望能从每笔交易中抽取税金。
可能存在多个税务机关,比如国家级、州级和县级。
●支付授权服务:
希望按照正确的格式和协议收到数字授权请求。
希望准确计算给商店的应付款。
前置条件:
收银员必须被识别和授权。
后置条件:
存储销售信息。
准确计算税金。
更新帐目和库存信息。
记录提成。
生成收据。
记录支付授权服务的许可。
主要成功场景(或基本流程):
1.顾客携带购买的商品或服务到达POS机收费口。
2.收银员开始一次新的销售。
3.收银员输入商品标识。
4.系统记录单件商品,并显示该商品的描述、价格和累加值。
价格可以根据一套定价规则来计算。
收银员重复3~4步,直到结束。
5.系统显示总值并计算税金。
6.收银员请顾客付款。
7.顾客支付,系统处理支付。
8.系统记录完整的销售信息,并将销售和付款信息发送到外部的记帐系统(进行记帐和提成)和库存系统(更新库存)。
9.系统打印收据。
10.顾客带者商品和收据离开。
扩展(或替代流程):
*a.任何时刻,发生以下情况,系统将失败:
为了支持恢复操作和正确的记帐,要保证所有交易的敏感状态和事件都能够从场景中的任何一步中完全恢复。
1.收银员重启系统,登录,请求恢复上次状态。
2.系统重建之前的状态。
2a.系统恢复过程中检测到异常:
1.系统向收银员指示错误,记录此错误,并进入一个清空状态。
2.收银员开始一次新的销售。
3a.非法标识:
1.系统指示错误并拒绝输入。
3b.有多个具有相同商品类别的商品(如10袋奶粉),不需要跟踪每个商品的惟一身份:
1.收银员可以输入商品类别的标识和数量。
3-6a.顾客要求收银员从已经输入的商品中去掉一个商品:
1.收银员输入商品标识并将其删除。
2.系统显示更新后的累加值。
3-6b.顾客要求收银员取消交易:
1.收银员在系统中取消交易。
3-6c.收银员暂停销售:
1.系统记录销售信息,使收银员能够在任何一台POS终端上恢复操作。
4a.系统生成的商品价格不是顾客想要的价格(顾客抱怨太贵,要求减价):
1.收银员重写价格。
2.系统显示新的价格。
5a.系统检测到与外部的税金计算系统的通信故障:
1.系统在POS机节点上重启此业务,并继续。
1a.系统检测到服务无法重启。
1.系统指示错误发生。
2.收银员可以手工计算税金并输入,也可以取消此销售。
5b.顾客声称他们符合打折条件(例如:
雇员或会员):
1.收银员发出打折请求。
2.收银员输入顾客的个人身份信息。
3.系统按照打折条款给出折扣价值。
5c.顾客要求使用信用卡结帐:
1.收银员发出信用卡结帐请求。
2.收银员输入顾客的个人身份信息。
3.系统从信用卡上扣除货款。
6a.顾客想用现金付款,但随身现金不足:
1a.顾客使用替代的手段。
1b.顾客告诉收银员:
他要取消此销售,收银员在系统上取消此销售。
7a.现金支付:
1.收银员输入收取的现金数额。
2.系统给出应找的余额,并弹出现金抽屉。
3.收银员放入收取的现金,并拿出应找的余额给顾客。
4.系统记录现金支付。
7b.信用卡支付:
1.顾客输入信用卡帐号。
2.系统向外部的信用卡授权服务系统发送支付授权请求,并请求批准此支付。
2a.系统检测到与外部系统的通信故障:
1.系统向收银员指示发生了错误。
2.收银员请求顾客更换支付方式。
3.系统收到批准付款的指示,并向收银员指示付款被批准。
3a.系统收到拒绝付款的指示:
1.系统向收银员指示付款被拒绝。
2.收银员请求顾客更换支付方式。
4.系统记录信用卡支付,其中包括支付的批准。
5.系统给出信用卡支付的签名输入机制。
6.收银员要求顾客作出一个信用卡支付签名。
顾客签名。
7c.支票支付……
7d.记帐支付……
7e.顾客出示优惠券:
1.在付款之前,收银员记录每张优惠券,并从系统中扣除相应的价值。
系统记录已使用的优惠券以备记帐之用。
1a.输入的优惠券并不适用任意购买的商品。
1.系统向收银员指示错误。
9a.有的商品有回扣:
1.系统给出回扣表格,并为每个回扣商品提供回扣收据。
9b.顾客要求礼物收据(不显示价格):
1.收银员请求礼物收据,系统给出礼物收据。
特殊需求:
●使用大型平面显示器上的触摸屏界面。
文本信息要能够在一米之外看清。
●90%的信用卡授权机构的响应时间应该在30秒内收到。
●我们希望在访问远程服务(如库存系统)失败的情况下保证可靠的恢复操作。
●支持多种语言显示。
●在步骤3和步骤7中可以插入新的业务规则。
●……
技术与数据的变化列表:
3a.商品标识可以用条码扫描或键盘输入。
3b.商品标识可以是UPC,EAN,JAN或SKU等不同的编码方式。
7a.信用卡帐号信息可以使用读卡器或键盘输入。
7b.记录在纸面收据上的信用卡支付签名。
但我们预测,两年内会有许多顾客希望使用数字签名。
发生频率:
可能会持续发生。
待解决的问题:
●什么是税法的变化?
●研究远程服务的恢复问题。
●不同的业务需要什么样的定制?
●收银员是否必须在退出系统后带走他们的现金抽屉?
●顾客是否可以直接使用读卡器,而不必收银员代劳?
双列格式:
主要参与者:
。
。
。
。
主要成功场景:
参与者动作系统职责
6.7各部分的解释
●叙言元素:
标题和主要参与者
●项目相关人员及其兴趣:
它建议并界定了系统必须作什么。
Cockburn:
“系统操控项目相关人员之间的一个契约,用例详细规定了这个契约中的行为部分。
。
。
。
。
。
用例作为行为的契约,捕获所有与满足项目相关人员兴趣有关的行为。
”
它说明:
用例应该包含什么?
用例应该包含满足了所有的项目相关人员兴趣的内容。
另外,通过在写出用例的所有部分之前确定项目相关人员及其兴趣,这种方法能够提示我们更详细的系统职责是什么。
●前置条件和后置条件
前置条件规定了在用例中的一个场景开始之前必须为真的条件。
前置条件在用例中不会被检验,假定这些条件为真。
后置条件:
规定了用例成功之后必须为真的条件,这一保证应该满足所有项目相关人员的需求。
●主要成功场景和步骤(基本流程)
它描述了能够满足项目相关人员兴趣的典型成功路径。
通常不包含任何条件和分支。
分支放扩展部分。
场景记录以下三种步骤:
1、参与者之间的交互;
2、一个验证动作;
3、由系统完成的状态改变。
●扩展(替代流程)
说明了所有的其他的场景或分支。
无论是成功的场景还是失败的场景。
扩展场景是从主要成功场景分离出来的,遵循主要成功场景的标记方式。
一个扩展由两部分组成:
条件和处理。
指导原则:
以系统或参与者能够检测到的某事物作为条件。
例如:
5a.系统检测到与外部的税金计算系统的通信故障(检测到的)。
5b.外部税金计算系统工作不正常。
(推测)
●特殊需求
非功能性需求,质量属性和设计约束。
●技术和数据的变化列表
例如输入输出技术带来的技术上的约束。
条码扫描,键盘输入。
6.8用例的目标和范围
应该怎样发现用例?
用例应该在什么级别上表述?
基本业务过程(EBP)的用例
下面哪些是有效的用例?
1、谈判一个供货合同。
2、处理返回值
3、登录
指导原则:
EBP用例对计算机应用进行需求分析的时候,应专注于“基本业务过程”级别的用例。
EBP:
由一个人(教条)在某个时间某个地点执行的一项任务。
这项任务是对某一业务事件的反应,而且能够增加可以度量的业务价值,并且能够保持数据状态的一致。
用例不是类似“删除一个表项”或“打印文档”这样的小步骤。
一个主要成功场景会包含5~10个这样的步骤。
常见错误:
定义许多级别过低的用例,这些用例只相当于EBP中的一个简单步骤。
用例和目标:
参与者都有自己的目标,并使用系统来帮助自己实现目标。
一个EBP级别的用例称为一个用户目标级别上的用例,以强调用例应该帮助系统的用户实现自己的目标。
推荐的过程:
1、找出用户的目标
2、为每一个目标定义一个用例。
需求研讨会上,我们可以问:
“你想做什么?
”
“你的目标是什么?
”
第一个问题的回答会反映出我们现有的解决方案和过程,以及与之相关的复杂因素。
第二个问题的回答则不一样,特别是当我们结合更高级别上的问题(这个目标的目标是什么?
)时,通常会激发出新的改进方案的想象。
会专注于增加业务价值,并且能够更深入地了解项目相关人员究竟希望该系统能够为他们做什么。
示例:
应用EBP指导原则找POS需求
系统分析师:
在使用POST系统时你的目标是什么?
收银员:
一是快速的登录,还有,收款。
系统分析师:
你认为登录的更高级别上的目标是什么?
收银员:
我要向系统证明身份,这样我才能被允许使用系统。
系统分析师:
防止盗窃、数据崩溃和显示不宜公开的公司信息。
分析师的策略是向上搜索目标层次,找出满足EBP规则的更高级别的用户目标,从而能够得到某个动作背后的真实意图,并理解这些目标的语境。
防止盗窃是企业目标,不是EBP。
登录:
不增加业务价值。
子功能目标和用例
辅助用户目标的子目标。
使用时机:
在多个用户目标级别的用例中重复出现,或是其它用例的前置条件。
6.9找出主要参与者、目标和用例
1、选择系统边界
2、识别主要参与者
3、为每个主要参与者确定各自的用户目标
4、定义满足用户目标的用例。
找出主要参与者靠提出一些问题,略
主要参与者通过使用系统服务来达到自己的用户目标。
次要参与者为带设计系统提供服务。
参与者目标
收银员处理销售
处理租赁
处理返回值
入款
出款
经理启动
关机
系统管理员添加用户
修改用户
删除用户
安全管理
系统表管理
销售活动分析系统分析销售数据和销售表现(数据挖掘)
定义用例:
为每个用户目标定义一个EBP级别的用例。
用例的命名应该与用户的目标相似。
用例名称以动词开头。
6.12参与者
是具有行为能力的事物。
主要参与者和次要参与者出现在用例文本的动作步骤中。
1.主要参与者:
使用被讨论的系统服务来满足自己的用户目标。
目的是为了找出用户目标,它驱动了用例。
2.次要参与者:
为被讨论系统提供服务。
自动支付授权服务。
通常是计算机系统。
目的是为了说明外部接口和协议。
3.后台参与者:
对用例的行为感兴趣,但不是主要参与者和次要参与者。
如:
税务机关。
目的是为了保证能找到并满足所有必要的兴趣。
6.13用例图
用例图和用例的关系是用例图是用例工作中的次要部分。
用例本身是文本格式的文档,用例工作意味着书写文本。
建议画简单的用例图。
一个用例图应该是系统语境的完美勾画,它创造了一个很好的语境图,即显示了系统的边界,那些东西在系统边界之外,以及如何使用系统。
用例图充当一种交流的工具,它概括了系统及其参与者的行为。
6.14语境中的需求和低级别特性列表
在使用系统的目标和场景语境中考虑和组织需求是用例思想的主要动机。
非功能性需求、领域规则和语境,以及其他难以定位的元素,在补充规范中列出。
低级别功能列表与用例的比较:
●冗长:
详细的功能列表与需求之间不会紧密相关,不同的功能和特性被不断地加入,就象一个杂乱的商品细目列表。
用例能够将需求放入使用系统的情节和目标的语境中。
●同时使用二者会产生重复,工作量大,不一致,不同步。
高级别的系统特性列表是可以接受的
什么时候使用详细的特性列表
特性驱动的需求:
应用服务器;数据库产品以及中间件系统和后台系统。
6.15用例不是面向对象的
用例是OOA/D的关键输入。
6.16统一过程中的用例
用例是统一过程的关键和核心。
●需求主要记录在用例中
●用例是迭代计划中的很重要的部分。
一次迭代要完成工作是按照选择用例中的哪些场景或整个用例进行定义的。
●用例实现驱动设计。
为了完成或实现用例而设计相互协作的对象和子系统。
●用例会影响用户手册得到组织形式。
迭代过程中的用例和需求规范
不同迭代的需求规范的工作量程度和时间分配不同。
需求在只细化了10%的情况下开始构建系统的核心部分。
迭代开发与瀑布过程的主要区别:
系统核心的开发很早就开始进行,远远早于知晓所有需求之前。
流程工件初始(1周)细化14周细化24周细化33周细化43周
重复,目标是写出80%~90%的用例。
只有一小部分的细节在细化阶段被实现,其余在构造阶段完成。
重复,详细写出70%的用例。
接近本次迭代结束时,再举行一次为期2天的需求研讨会,从完成的实现工作中获得反馈和深入的了解,并详细写出50%的用例。
接近本次迭代结束时,再举行一次为期2天的需求研讨会,从完成的实现工作中获得反馈和深入的了解,并详细写出30%的用例。
为期两天的需求研讨会.按名称找出大多数用例,并将这些用例概括在一小段中。
只有10%的用例被详细写出。
需求用例模型
重复,到现在为止,高风险并对构架有重要影响的问题都已经稳定下来。
为一小组高风险的对构价至关重要的需求进行设计。
设计设计模型无重复重复
重复,构建最终系统的15%。
重复,构建最终系统的10%。
重复,构建最终系统的5%。
实现实现模型无实现这部分
设计
现在,可以合理地提交全部的项目持续时间、重要的里程碑、工作量以及成本的估计。
“估计”开始有一些雏形了。
粗略地估计整个工作量。
项目软件开发改进改进
管理计划
统一过程工件创建的时间安排
流程工件初始(I1)细化(E1..En)构造(C1..Cn)移交(T1..T2)
业务建模领域模型s
需求用例模型sr
构想sr
补充规范sr
术语表sr
设计设计模型sr
软件架构文档s
数据模型sr
实现实现模型srr
项目管理软件开发计划srrr
测试测试模型sr
环境开发案例sr
初始阶段中的用例
不是所有的用例在初始阶段写成详述格式。
早期列出大多数的有趣的、复杂的有风险的用例的简洁格式。
10%~20%的用例写成详述格式。
这些用例要么是表示描述系统核心复杂的功能,要么具有某些方面很大的风险。
细化阶段中的用例
这一阶段由多个时间区间迭代组成(如4次),每次迭代逐渐创建高风险的高价值的或对构架至关重要的系统部分,大部分需求已经被识别和阐明。
具体编程中的反馈又会影响团队对需求的理解。
这些理解将不断地深入和精化。
80%~90%的用例被详细写出。
构造阶段中的用例
构造阶段将专注于完成系统。
构造阶段由许多时间区间迭代组成(如20次,每次2周)。
还会出现次要用例,可能举办需求研讨会,但比细化阶段少得多,进入这阶段前,大部分核心的功能性需求和非功能性需求都已稳定,需求的变化程度已经低很多了。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 用例