需求之系统用例规约.ppt

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