需求之系统用例规约

《需求之系统用例规约》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、需求之系统用例规约（SystemuseSpecification）七月21计科系段恩泽email:duanenze@126.com2需求步骤2-3：书写系统用例规约用例图只是表达了用例的目标，需要通过书写用例规约把不同级别的相关需求表达出来。3前置条件和后置条件前置条件：用例开始前，系统需要满足的约束。后置条件：用例接受后，系统需要满足的约束。后置条件分为最小后置和成功后置。最小后置指即使在用例失败的情况下系统也需要满足的约束；成功后置指用例成功时系统需要满足的约束。4前置条件和后置条件前置条件和后置条件必须是系统能检测的。在“录入保单”用

2、例中，系统无法检测业务代表是否已经将保单交给内勤。在“收银”用例中，系统无法检测顾客是否已带货物离开。5前置条件和后置条件前置条件必须是用例开始前系统能检测到的。储户开始取款的交互前，系统不知道储户是谁，要取多少钱，所以“储户账户里有足够的金额”这个条件是无法检测的。6前置条件和后置条件前置后置条件必须是约束，不是动作。“系统记录鉴定结果”是一个动作，不是条件。条件应该是“系统已记录鉴定结果”。7前置条件和后置条件前置后置条件要有系统的味道。“系统正常进行”、“网络连接正常”等放之四海皆准的约束，和所研究的系统没有特定关系，不能作为前置后置

3、条件，否则又将是一大堆正确而无用的废话。8涉众利益储户在取款时，涉及的涉众利益如下：储户—希望操作24小时服务；担心权益受损。银行负责人—希望安全；希望节约运营成本。9取款的用例描述片段基本路径1.储户提交账户信息2.系统验证账户信息合法3.系统提示输入密码4.储户输入密码5.系统验证密码合法、正确6.系统提示输入取款金额7.储户验证金额合法8.系统记录取款信息，更新账户信息……业务规则5.密码为6位数字8.取款金额应为100元的倍数；取款金额应少于账户余额；单次取款余额不超过3000元；单日取款金额不超过20000元设计约束1.通过磁条卡

4、或芯片卡提交账户信息。10涉众利益的交锋步骤1有设计约束“通过磁条卡或芯片卡提交账户信息”，这是为了照顾储户“方便”的涉众利益。验证密码是为了照顾银行“安全”的利益。“密码长度为6位”是“方便”和“安全”交锋后的妥协。“系统记录取款信息，更新账户信息”是为了银行的利益。“取款金额应为100元的倍数；取款金额应少于账户余额；单次取款余额不超过3000元；单日取款金额不超过20000元”是为了银行的利益，因为在涉众排行榜上，银行坐前排，储户坐后排。11如何寻找涉众如果系统的这个用例做得不好，谁会遭殃？12执行者执行者如果是人，当然是用例的涉众。

5、“ERP系统管理员”是“ERP系统”这个非人执行者背后的涉众。13上游执行者使用系统做某个用例，需要一些资源，这些资源的提供者很可能是涉众。保单是“业务代表”提供的，如果内勤喝醉了酒乱录，信息错得一塌糊涂，业务代表的利益就被损害了。14下游执行者使用系统做某个用例，会产生出后果，这个后果会影响到别人，这些人也是涉众。如果系统做得不好，不检测内勤录保单时必填项有没有填就放了过去，后面负责审核的“经理”就比较费劲了。15信息的主人用例会用到一些信息，这些信息可能会涉及到某些人，这些人也许不知道这个系统的存在，但系统的好坏涉及到他们的利益。“录入

6、保单”的用例中。涉及到被保人、投保人、受益人。16如何寻找涉众17书写路径步骤的注意事项按照交互四部曲书写执行者和系统一个个回合交互，直到达成目的。每个回合的步骤分为四类：请求、验证、改变、回应。例子：1.顾客请求注册2.系统反馈注册界面3.顾客提交注册信息4.系统验证注册信息充分5.系统生成顾客账户6.系统反馈所创建的顾客账户18书写路径步骤的注意事项使用主动语句清理责任。例子：系统从会员处获取用户名和密码（错）会员提交用户名和密码（对）用户名和密码被验证（错）系统验证用户名和密码（对）“会员保存订单”不对，应该是“会员提交订单信息，系统

7、保存订单”“会员查询商品”不对，应该是“会员提交查询条件，系统系统查询商品，系统反馈查询结果”19书写路径步骤的注意事项主语只能是主执行者或者是系统。写需求，就是把系统看作一个黑箱，描述它对外提供的功能和约束。例子：执行者请求前端系统做某事，前端系统请求后端系统做某事（错误）执行者请求客户端做某事，客户端请求服务器做某事（错误）20书写路径步骤的注意事项使用核心域概念。路径步骤是功能需求，应该使用核心域的概念来描述。例子：系统建立连接，打开连接，执行SQL，从“零件”表查询（错误，因为涉及技术）系统根据查询条件搜索零件（正确）21书写路径步

8、骤的注意事项不要涉及交互设计的细节。错误例子：会员从下拉框中选择类别会员在文本框中输入查询条件会员单击“确定”按钮这些界面细节很可能不是需求，只是开发人员选择的解决方案—设计，应