阐述需求规格说明书中的用例规约

1、用例的概念用例的关系参与者的定义与关系用例规约黑盒用例与白盒用例用例规约组成用例规约类型与书写风格o简单型o非正式型o正式型（详细型）用例规约：更进一步的精度o用例文档的核心，而用例图作为用例文档的总图o进一步的精度：有层次的文档o文档中每一句话都有其价值黑盒用例o建模人员常用，不描述系统的内部工作流程，也不描述其组成成分或设计。白盒用例o借助责任描述系统，指出系统应该具有什么职责，具有各种职责的软件元素之间是如何合作的黑盒用例白盒用例该系统记录销售情况该系统将销售情况写到一个数据库中或者该系统为销售情况生成一个SQL语句1.1.用例名称：处理销售2.2.用例标识3.3.涉及的参与者4.4.涉

2、及的用例5.5.描述6.6.用例的规格说明1.1.前置条件 与 后置条件 2.2.正常事件流3.3.备选事件流7.7.其它o非功能需求、设计约束、尚存在的问题前置条件约束在用例开始前系统的状态o把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件o说明在用例触发之前什么必须为真后置条件约束用例执行后系统的状态o用例执行后什么必须为真o对于有多个事件流的用例，则应该有多个后置条件某些用例依赖于其他用例o一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”）有助于识别漏掉的用例o如果一个用例的前置条件不执行，就不能执行其他用例，可能意味着丢失了用例（例如：“管理订单

3、”却没有“登录”用例）1. 动 作4. 回 应2.改变3.验证系 统一个正常的业务事件流描述1.只书写“可观测”的2.使用主动语句3.句子必须以参与者或系统作为主语4.不要涉及界面细节5.分支和循环系统通过ADOADO建立数据库连接，传送SQLSQL查询语句，从“商品表”查询商品的详细信息系统按照查询条件搜索商品的详细信息欧文从贝克汉姆处得到传球，守门员贝克汉姆传球给欧文，欧文射门，守门员扑救参与者o出纳员接收顾客的付款顾客的付款数可能高于商品总额o出纳员录入顾客所付的现金总额系统o系统显示出应找还给顾客的余额，打印付款收据会员从下拉框中选择类别会员在相应文本框中输入查询条件会员点击“确定”按

4、钮分支：放到扩展路径o参与者的选择o另一条成功线路o系统进行验证o循环：直接描述用简洁的一段话来描述用例，通常只给出主要成功场景处理销售o一个顾客带着商品在收款处准备交费购买。o出纳员使用POS终端记录所购买的每一件商品oPOS系统给出所应收的总款数以及每件商品的价格细节。o顾客键入支付信息，系统进行确认并记录。o然后，系统更新商品的存货清单o顾客拿着系统打印的收条并带着商品离开。用若干非正式段落来描述用例，通常给出多个不同场景处理退货o主要成功场景：顾客带着商品到收款处退货，出纳员使用POS终端记录每一件被退回的商品。o可选场景：如果系统中找不到商品标识，那么就通知出纳员并建议他手工输入商品

5、标识码（或许商品的标识已经破损）；如果系统检测到和外部税金计算系统之间的通信失败，那么就。4721/ 1正式型（详细型）-1描述更多细节并以结构化方法组织这些细节，对理解系统非常有意。1.1.用例 UC1UC1：处理销售2.2.主要参与者：出纳员21/554722/ 1正式型（详细型）-23.受益人及其利益：1.出纳员：需要精确、快速的输入，并且不出现支付错误2.销售人员：需要销售款得到更新3.顾客：需要购买并花费最小的精力得到快速的服务，并需要支持退货功能22/554723/ 1正式型（详细型）-33.受益人及其利益：4.公司：需要精确地记录交易并满足客户的利益。需要支付授权服务记录可接受的

6、支付。需要一些容错功能。需要账目和存货清单得到自动的快速更新23/554724/ 1正式型（详细型）-43.受益人及其利益：5.政府税务机构：需要从每一次销售中收税。6.支付授权服务：需要用正确的格式和协议传来的数字授权请求。需要精确计算它们可支付给商店的款额24/554725/ 1正式型（详细型）-54.4.前置条件：出纳员需要身份识别并授权5.5.后置条件：存储了销售情况，正确地计算了税金，更新了账目和存货清单，记录了销售额，打印了收据25/554726/ 1正式型（详细型）-66.6.主要成功场景：1.1.顾客带着商品到POSPOS终端处准备购买2.2.出纳员开始一次新的销售3.3.出纳

7、员输入商品标识码4.4.系统记录销售的商品并给出商品的描述、单价和折扣，并根据某些价格规则计算所应付的款额。出纳员重复步骤3 3和步骤4 4，一直到处理完所有商品为止。26/554727/ 1正式型（详细型）-76.6.主要成功场景：5.5.系统给出所应支付的总款额并计算税金6.6.出纳员告诉顾客总价并请求付款7.7.顾客付款，系统处理支付8.8.系统记录下已完成的销售，并将销售和支付信息发送给外部的账目系统以及存货清单系统27/554728/ 1正式型（详细型）-86.6.主要成功场景：9.9.系统打印收据10.10.顾客带着收据和商品离开28/554729/ 1正式型（详细型）-扩展1 1

8、1.1.在系统失败时，要恢复和校正账目，确保所有的交易敏感状态以及事件能够从场景的任何步骤中恢复1.1.出纳员重启系统和登录，并请求恢复先前的状态29/554730/ 1正式型（详细型）-扩展2 22.2.系统重建先前的状态2a 2a 系统检测阻止恢复的异常状态1.1.系统给出纳员发出一个出错信号，记录该错误并进入一个干净的状态2.2.出纳员开始一次新的销售30/554731/ 1正式型（详细型）-扩展3 33a 3a 无效标识码：1.1.系统发出一个出错信号并拒绝输入2.2.出纳员可以手工输入商品标识码2a2a 输入无效标识码，系统拒绝输入4a 4a 顾客可能购买多件相同类别的商品，因此记不

9、记录每件商品的标识码并不重要1.1.出纳员可以输入商品类别号以及数量31/554732/ 1正式型（详细型）-扩展4 43-6a 3-6a 顾客请求出纳员从购买的货物中去掉一件商品3-6b 3-6b 顾客告诉出纳员取消销售3-6c 3-6c 出纳员中止销售4a 4a 系统所输出的商品单价不是顾客所想要的32/554733/ 1正式型（详细型）-扩展5 55a 5a 系统检测到和外部税金计算系统之间的通信失败5b5b顾客说他们符合打折条件5c 5c 顾客说他们帐上的存款为此次销售付款6a 6a 顾客说他们想付钱但没有带足够的现金33/554734/ 1正式型（详细型）-扩展67a 7a 用现金付

10、账1.1.出纳员输入顾客所付总款数2.2.系统计算出应找的余款，并弹出现金抽屉3.3.出纳员存放现金并找零给顾客4.4.系统记录此次现金支付情况34/554735/ 1正式型（详细型）-扩展77b 7b 用信用卡付账1.1.顾客输入他们的信用卡帐户信息2.2.系统向外部支付授权服务系统发出支付请求授权，并请求支付批准2a2a系统检测到和外部系统之间协作上的失败：1.1.系统给出纳员发出一个出错信号2.2.出纳员请顾客用其他方式付款35/554736/ 1正式型（详细型）-扩展87b 7b 用信用卡付账3.3.系统收到批准支付回应并向出纳员发出一个批准支付信号3a 3a 系统受到拒绝该支付信号1

11、.1.系统发拒绝支付信号给出纳员2.2.出纳员请顾客用其他方式付款4.4.系统记录信用卡支付情况，其中包括批准支付情况36/554737/ 1正式型（详细型）-扩展97b 7b 用信用卡付账5.5.系统给出信用卡支付签名输入机制6.6.出纳员请客户进行信用卡支付签名，客户输入签名37/554738/ 1正式型（详细型）-其他扩展7c 7c 用帐单付款7d 7d 赊账7e 7e 顾客拿出优惠券9a 9a 商品打折9b 9b 顾客请求赠品收据38/554739/ 1正式型（详细型）-特殊需求应具有一个大的扁平面板监视器上的触摸屏界面，并可在1m1m之外看清屏幕上的字信用卡授权90%90%的情况下能

12、在30s30s内作出响应当访问诸如库存清单等这类远程服务时，应具有健壮的恢复功能39/554740/ 1正式型（详细型）-特殊需求文本显示应语言国际化可在步骤3 3和步骤7 7插入业务规则。40/554741/ 1正式型（详细型）-其它1技术和数据约束列表3a 3a 商品标识码由条形码激光扫描器或键盘输入3b 3b 商品标识符可以使UPCUPC、EANEAN、JANJAN、SKUSKU编码格式7a 7a 信用卡账目信息由信用卡阅读器或键盘输入7b 7b 信用卡支付签名可以在纸上进行。但未来两年内，顾客可能更愿使用数字签名41/554742/ 1正式型（详细型）-其它2发生频率：几乎可以连续发生尚未解决的问题o税法变化怎么办o远程服务恢复问题o不同的业务需要什么样的自定义功能o出纳员退出系统时必须带走现金抽屉吗o顾客使用信用卡阅读器还是出纳员使用42/55描述更多细节并以结构化方法组织这些细节，对理解系统非常有益