需求之system用例图”.pptVIP

玩弄层次 “高层”实际上是头脑里不知不觉偷换了研究对象，把“医院系统”的契约换成了“医院”的契约。还有下面这个 * 玩弄层次 * 玩弄“子系统” 用例很多时，可以将用例分包，但用例包是从外部对系统功能所做的分包。 子系统是根据内部部件的耦合和内聚切割得到。 * 玩弄“子系统” 用例很多时，可以将用例分包，但用例包是从外部对系统功能所做的分包。 子系统是根据内部部件的耦合和内聚切割得到。 * 模糊的价值 研究对象是一个人事系统，员工通过系统交请假单，主管使用系统批假，然后人事部专员使用系统备案。 * 模糊的价值 有时候开发人员会觉得，哎呀，没请到假，怎么能算价值呢，用例图应该是这样才对： * 模糊的价值 人事系统只能向员工承诺“你把请假单交给我，我要是没保存好，你可以骂我”，员工不能指望仅仅和人事系统打交道就能请到假，这个价值是由【人事系统＋主管＋人事部专员】一起提供的。 * 模糊的价值 如果业务序列图像下图这样，结果就不一样了，前面图的用例图变成正确的，因为人事系统确实可以为员工提供请假的价值。 * 模糊的价值 或者换一个研究对象，研究虚构的组织─“请假部”，结果也不一样： * 提示：大用例无妨小用例 针对不同执行者、不同业务流程，系统提供的价值可大可小，大的是用例，不妨碍小的也是用例。 * 提示：用例的命名 用例的命名是动宾结构，例如“取款”。动词前面可以加状语，宾语前面可以加定语。 用例之前的需求技术，有的可能是以“名字+动词”的形式命名系统的功能，例如“发票作废”，后来要改成用例的动宾结构了，开发人员就在前面加一个弱动词“进行”，就变成了“进行发票作废”，这个也是不合适的。 * * * * * * * * * * * * * * * * * * * * * * * 系统用例要点 系统用例的定义：系统能够为执行者提供的，涉众可以接受的价值。 用例可以看作执行者和系统之间买卖的平衡点，期望和承诺的平衡点。还是以被说滥了的取款机为例。储户来到取款机面前，插卡输密码，拿到两百元后，到隔壁投注站买了10 张福彩刮刮乐即开彩票，哇噻，中奖五万元。那么，取款机的用例到底是什么，“登录”、“取款”还是“中奖”？或者说“都对，从辩证的角度看嘛”？ * 系统用例要点 “登录”不是取款机的用例，因为取款机不能这么叫卖自己：“来啊来啊！我这里能登录啊”，然后储户就说，“哇，真棒，这正是我想要取款机提供的服务，好，我去用一用”。储户对取款机的期望可不止这么多。“中奖”也不是取款机的用例，储户倒是很想从取款机那里得到这个服务，可惜，取款机没法承诺。“取款”才是取款机能承诺，而且储户乐意因此而使用取款机的服务。 * 系统用例要点 用例之前的许多需求方法学，把需求定义为思考系统“做”什么，用例把需求提升到思考系统“卖什么”的高度。这种思考是非常艰难的，因为它没有标准答案，只有最佳答案。对于仍然习惯用学生思维思考、喜欢背标准答案的开发人员，思考“什么是系统的价值”有时甚至会让他痛苦到想要逃避，或者干脆用模糊不清的功能、特性等词语代替。 * 系统用例要点 人们求职、求偶、求**...不就是要搞清楚“我”这个人肉系统到底应该卖给谁，卖什么服务的最佳答案吗？我想卖给你的你不要，你想买的我又没有，就是人生的痛苦所在。许多时候，我们象没头苍蝇一样投简历、相亲，却不舍得抽出时间静下来思考“价值”的问题。 * 系统用例要点 “程序员”这个人肉系统为老板提供的用例是什么？安装开发工具？编码？为公司赚钱？ 编码，这是老板对程序员的期望以及程序员可以提供的承诺的平衡点，或者说，这是程序员能卖，老板愿意买的价值。程序员不能因为装了个VisualStudio 就理直气壮向老板要报酬，老板不给就生气；程序员按要求编出了代码，老板就不能因为销售部门不给力导致软件卖不出去赚不到钱而责怪程序员。 * 系统用例要点 程序员如果摆错了自己的位置，没有好好完成本职工作，反倒是向老板上“万言书”，对公司的发展方向大放厥词，指手画脚，老板是不会喜欢的，因为他不期望从程序员身上“购买”这个服务（用某知名企业领导人的话说就是：有精神病就送医院，没精神病就辞退）。可见，搞清楚自己的“用例”，认清自己的定位，对人生多么重要。当然，随着时间的发展，人肉系统可以不断升级，淘汰旧的用例，开发新的用例。 * 系统用例要点 思考用例的过程就是发现价值的过程。如果您不断通过用例思维来思考系统的需求，就能训练出越来越强大的发现价值的能力。无论打工还是创业，这种发现价值的能力是非常有帮助的。用例思维可以让您终身受益。 * 练习(exercises) 1. 以_____这样的系统为研究对象时，“登录”作为用例是合适的 　A)ERP 　B) 电子商务网站如淘宝 　C)