《需求之系统用例规约.ppt》由会员分享，可在线阅读，更多相关《需求之系统用例规约.ppt（40页珍藏版）》请在三一办公上搜索。
1、需求之系统用例规约（System use Specification）,2023年10月,2,需求步骤2-3：书写系统用例规约,用例图只是表达了用例的目标，需要通过书写用例规约把不同级别的相关需求表达出来。,3,前置条件和后置条件,前置条件：用例开始前，系统需要满足的约束。后置条件：用例接受后，系统需要满足的约束。后置条件分为最小后置和成功后置。最小后置指即使在用例失败的情况下系统也需要满足的约束；成功后置指用例成功时系统需要满足的约束。,4,前置条件和后置条件,前置条件和后置条件必须是系统能检测的。在“录入保单”用例中，系统无法检测业务代表是否已经将保单交给内勤。在“收银”用例中，系统无法检
2、测顾客是否已带货物离开。,5,前置条件和后置条件,前置条件必须是用例开始前系统能检测到的。储户开始取款的交互前，系统不知道储户是谁，要取多少钱，所以“储户账户里有足够的金额”这个条件是无法检测的。,6,前置条件和后置条件,前置后置条件必须是约束，不是动作。“系统记录鉴定结果”是一个动作，不是条件。条件应该是“系统已记录鉴定结果”。,7,前置条件和后置条件,前置后置条件要有系统的味道。“系统正常进行”、“网络连接正常”等放之四海皆准的约束，和所研究的系统没有特定关系，不能作为前置后置条件，否则又将是一大堆正确而无用的废话。,8,涉众利益,储户在取款时，涉及的涉众利益如下：储户希望操作24小时服务
3、；担心权益受损。银行负责人希望安全；希望节约运营成本。,9,取款的用例描述片段,基本路径1.储户提交账户信息2.系统验证账户信息合法3.系统提示输入密码4.储户输入密码5.系统验证密码合法、正确6.系统提示输入取款金额7.储户验证金额合法8.系统记录取款信息，更新账户信息业务规则5.密码为6位数字8.取款金额应为100元的倍数；取款金额应少于账户余额；单次取款余额不超过3000元；单日取款金额不超过20000元设计约束1.通过磁条卡或芯片卡提交账户信息。,10,涉众利益的交锋,步骤1有设计约束“通过磁条卡或芯片卡提交账户信息”，这是为了照顾储户“方便”的涉众利益。验证密码是为了照顾银行“安全”
4、的利益。“密码长度为6位”是“方便”和“安全”交锋后的妥协。“系统记录取款信息，更新账户信息”是为了银行的利益。“取款金额应为100元的倍数；取款金额应少于账户余额；单次取款余额不超过3000元；单日取款金额不超过20000元”是为了银行的利益，因为在涉众排行榜上，银行坐前排，储户坐后排。,11,如何寻找涉众,如果系统的这个用例做得不好，谁会遭殃？,12,执行者,执行者如果是人，当然是用例的涉众。“ERP系统管理员”是“ERP系统”这个非人执行者背后的涉众。,13,上游,执行者使用系统做某个用例，需要一些资源，这些资源的提供者很可能是涉众。保单是“业务代表”提供的，如果内勤喝醉了酒乱录，信息错
5、得一塌糊涂，业务代表的利益就被损害了。,14,下游,执行者使用系统做某个用例，会产生出后果，这个后果会影响到别人，这些人也是涉众。如果系统做得不好，不检测内勤录保单时必填项有没有填就放了过去，后面负责审核的“经理”就比较费劲了。,15,信息的主人,用例会用到一些信息，这些信息可能会涉及到某些人，这些人也许不知道这个系统的存在，但系统的好坏涉及到他们的利益。“录入保单”的用例中。涉及到被保人、投保人、受益人。,16,如何寻找涉众,17,书写路径步骤的注意事项,按照交互四部曲书写执行者和系统一个个回合交互，直到达成目的。每个回合的步骤分为四类：请求、验证、改变、回应。例子：1.顾客请求注册2.系统
6、反馈注册界面3.顾客提交注册信息4.系统验证注册信息充分5.系统生成顾客账户6.系统反馈所创建的顾客账户,18,书写路径步骤的注意事项,使用主动语句清理责任。例子：系统从会员处获取用户名和密码（错）会员提交用户名和密码（对）用户名和密码被验证（错）系统验证用户名和密码（对）“会员保存订单”不对，应该是“会员提交订单信息，系统保存订单”“会员查询商品”不对，应该是“会员提交查询条件，系统系统查询商品，系统反馈查询结果”,19,书写路径步骤的注意事项,主语只能是主执行者或者是系统。写需求，就是把系统看作一个黑箱，描述它对外提供的功能和约束。例子：执行者请求前端系统做某事，前端系统请求后端系统做某事
7、（错误）执行者请求客户端做某事，客户端请求服务器做某事（错误）,20,书写路径步骤的注意事项,使用核心域概念。路径步骤是功能需求，应该使用核心域的概念来描述。例子：系统建立连接，打开连接，执行SQL，从“零件”表查询（错误，因为涉及技术）系统根据查询条件搜索零件（正确）,21,书写路径步骤的注意事项,不要涉及交互设计的细节。错误例子：会员从下拉框中选择类别会员在文本框中输入查询条件会员单击“确定”按钮这些界面细节很可能不是需求，只是开发人员选择的解决方案设计，应该把它们删掉，然后问“为什么”，背后隐藏的才是涉众在意的、真正的需求，也许是非功能需求中的可用性需求“操作次数不超过5次”，也许是非功
8、能需求中的可用性需求“反馈速度应该在3秒以内”。,22,书写路径步骤的注意事项,不要涉及交互设计的细节。需求是问“不这样行吗”，而不是问“这样行吗”。,23,书写路径步骤的注意事项,不要写系统不能负责的事情。错误例子：顾客付款收银员找零以上两个是系统无法感知和承诺的。,24,扩展路径,执行者的选择。执行者需做出选择，选择结果不同，带来的交互也不同。例子：1.会员请求查看订单2.系统反馈会员的订单列表3.会员可以取消订单4.会员选择查看订单，请求查看明细5.系统反馈订单明细3a.会员取消订单：3a1.会员请求取消订单3a2.系统取消订单,25,扩展路径,系统验证。验证必然有成功有失败，失败的情况
9、下，系统肯定要处理，否则验证就是多余的了。,26,扩展路径,关键步骤失败。如果不处理关键步骤的失败，执行者无法了解用例的进展。,27,补充约束,字段列表。字段列表用来描述某个领域概念的细节。讲座信息=时间+地点+专家+主题+简介也可以引进一些符号注册信息=公司+联系人+电话+联系人地址*客房状态=空闲|已预订|占用|维修中,28,补充约束,业务规则。业务规则描述步骤中系统运算的一些规则。软工货物送达日期超过计划中的交付日期，扣减15%的金额合同的总金额不超过买方的信用额度,29,非功能需求,可用性。如果系统按照程序员的意图工作，并且完成能完成任务，但用户不喜欢用。人事专员第一次使用时30分钟内
10、能学会添加新员工,30,非功能需求,性能。性能表示做得多好，性能指标包括速度、容量、能力等。系统能在0.5秒之内拍摄超速车的照片（速度）应允许1000个执行者同时使用本用例（容量）在标准工作负荷下，系统的CPU占用率应少于50%（能力）,31,非功能需求,可靠性。可靠性表示系统的安全性和完整性。可靠性通常用平均无故障时间和平均修复时间表示。,32,非功能需求,可支持性。可支持性表示系统升级和修复的能力。95%的紧急错误应能在30工作时内修复在修复故障时，未修复的相关缺陷平均数应小于0.5升级新版本时，应保存所有系统设置和个人设置,33,非功能需求,设计约束。设计约束是在实现系统时必须要遵守的一
11、些约束，包括界面样式、表格格式、平台、语言等。用oracle数据库保存数据，因为客户已经采购了许多oracle数据库，如果不用，成本就会增加。,34,案例,用例编号：UC1用例名：执行通知任务执行者：时间（主）前置条件：存在待执行的通知任务后置条件：系统已发出通知涉众利益：UMLChina：担心发送太慢；担心邮箱被封杀技术专家：担心通知内容不准确，夸大其词，损害自己的声誉学员：担心骚扰信息太多,35,案例,基本路径：1.当到达时间周期是，系统定位下一个发件邮箱以及下一个待执行的通知任务项。2.系统使用发件邮箱向通知任务项的邮件发送地址发送电子邮件3.系统记录邮件发送情况扩展路径：1a。没有待执
12、行的通知任务项：1a1：用例结束1b。没有发件邮箱：1b1：系统提示没有发件邮箱,36,案例,字段列表：2.发件邮箱=发件人称呼+发件人地址+用户名+密码+SMTP服务器+POP3服务器2.通知任务项=邮件地址+称呼3.邮件发送情况=通知任务项+发送时间+发送邮件+成功与否业务规则：1.定位规则：从通知任务中找到正在生效的通知任务，然后从该通知任务中未出现过发送错误的通知任务项中随机抽取一个任务项。发送邮箱定位规则：按字母排序，顺序选择。非功能需求：*从1到3在30秒以内设计约束：无,37,案例,用例编号：UC2用例名：为公开课创建通知任务执行者：公司助理（主）前置条件：无后置条件：系统已为公
13、开课生成通知任务涉众利益：UMLChina：担心尺度把握不好引起反感，担心通知不能到达想通知的联系人技术专家：担心通知内容搞错损害声誉被通知联系人：担心收到太多垃圾信息公司助理：担心操作太复杂,38,案例,基本路径：1.公司助理选择公开课，请求创建通知任务。2.系统验证所选公开课适合创建通知任务3.系统反馈设置通知任务界面4.公司助理提交通知任务设置5.系统反馈公开课通知任务的范围6.公司助理确认7.系统为所选公开课生成通知任务8.系统反馈已经创建的通知任务,39,案例,扩展路径：2a。所选公开课不适合创建通知任务：2a1.系统反馈所选公开课不适合创建通知任务2a2.用例结束字段列表：4.通知任务设置=公开课+发送邮件*+不通知的组织+不通知的联系人7.通知任务=任务名称+邮件地址+称呼*+任务创建时间+发件邮箱*+邮件内容+邮件主题,40,案例,业务规则：2.适合创建通知任务的公开课规则：该公开课没有正在执行的通知任务，而且公开课的举办日期应该是当前日期或更长时间之后。7.符合某次公开课待通知联系人的规则:联系人当前所在城市所属分区与公开课举办城市所属分区相同，而且联系人当前所在组织不属于该公开课“不通知的组织”，而且联系人不属于该公开课“不通知联系人”非功能需求：无设计约束：无,
