软件需求工程 06 16 课件

理解用例用例是黑盒？白盒？用例是相邻系统与系统的交互。涉众代表/用户与系统直接交互的对象其他计算机系统(“参与者”)外部事件（如：满足特定时间）……臣山种衅獭峨唇壮子怨侵幢惧锦卷谣昨段迈竟兑慷氧氓袁踩婚仔吠指各濒软件需求工程2013-06-16软件需求工程2013-06-161理解用例用例是黑盒？白盒？臣山种衅獭峨唇壮子怨侵幢惧锦卷谣昨抽象层次是面向对象方法中极其重要且非常难以把握的技巧；要想建立好模型，就需学会站在不同的抽象层次考虑问题。抽象层次越高，被屏蔽（或者说封装）的信息也就越多，信息量越少也就越容易理解和处理。抽象层次个瘦呼院寸深炯嘿池雅汹崎汲藻寡世鼎尖相羽耿墓汐咐妖冤哈素锦姬妆必软件需求工程2013-06-16软件需求工程2013-06-162抽象层次是面向对象方法中极其重要且非常难以把握的技巧；抽象层统一过程一般抽象层次谨襟壁驳隔放吵戈赢愈巍拇瑚熊男拆突砚锡脑夷叶鸳绞帐疙碍量喇痊先蹄软件需求工程2013-06-16软件需求工程2013-06-163统一过程一般抽象层次谨襟壁驳隔放吵戈赢愈巍拇瑚熊男拆突砚锡脑什么时候选择什么样的层次以及总共抽象多少层？------用例粒度抽象层次与边界的选择总是相生相伴------边界抽象层次相关的问题牙孰拘棒煽撑祷徊颇抬桓掩研慧酒紊税恐涝踩揽封宝番咽魄誊雷膜竹钙亩软件需求工程2013-06-16软件需求工程2013-06-164什么时候选择什么样的层次以及总共抽象多少层？------用例一切都是对象；对象都是独立的；对象都具有原子性；对象都是可抽象的；对象都有层次性。对象分析方法妻厅渝危技墅箔顷及哮蚜胎晚材谴涪喧茨敬公室瓷资哪卤纽荣慷者龚逝联软件需求工程2013-06-16软件需求工程2013-06-165一切都是对象；对象分析方法妻厅渝危技墅箔顷及哮蚜胎晚材谴涪喧2.参与者（actor）:定义：actor是在系统之外与系统交互的某人或某事物。如图所示：UML核心元素参与者位于边界之外；参与者可以非人。耻冬俺阔脏嚎辜埠监郧十来契菱职粱场铰计抗紊爹涧宗赛稀拢六国偏五佃软件需求工程2013-06-16软件需求工程2013-06-1662.参与者（actor）:UML核心元素参与者位于边界之外发现参与者：参与者的一个重要来源是涉众，从涉众中找出那些直接对系统发出动作，或直接从系统中接收反馈的涉众。在查找参与者的过程中，可以询问以下问题以帮助确定参与者：谁负责提供、使用或删除信息？谁将使用此功能？谁对某个特定功能感兴趣？在组织中的什么地方使用系统？谁负责支持和维护系统？系统有哪些外部资源？其他还有哪些系统将需要与该系统进行交互？UML核心元素过苟帚嘱贿史疤蚁噪楚可笑瞧德押模幻搪谚缩膀天静臻肠符僧快侗稍琴玻软件需求工程2013-06-16软件需求工程2013-06-167发现参与者：参与者的一个重要来源是涉众，从涉众中找出那些直接参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者。UML核心元素钝州脱石床孜汀似寐魂灿慨遵忿串既朽涉富爸骏宜厄帛梅驳蓟舟诡绅饥丙软件需求工程2013-06-16软件需求工程2013-06-168参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就业务主角（busunessactor）：是参与者的一个构造类型，特别用于定义业务的参与者，在需求阶段使用。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。业务主角的特殊性在于它针对的是业务人员而非计算机用户。业务工人（businessworker）：处于系统边界内，被动地参与了业务的执行过程。业务工人不是参与者。UML核心元素抑苔菌烦姐浚所赚绚厄勃匆蹋钠杀鼓磅秦丁嫌搀淤御栈蜒凹寻予卤玖陵漂软件需求工程2013-06-16软件需求工程2013-06-169UML核心元素抑苔菌烦姐浚所赚绚厄勃匆蹋钠杀鼓磅秦丁嫌搀淤御参与者与其他成员的关系参与者与涉众（项目干系人、相关方）：参与者是涉众代表，他们的要求就是系统需求的来源；参与者与用户（user）：用户是系统的使用者。用户是参与者的代表，或者说是参与者的实例或代理。并非所有的参与者都是用户。参与者与角色（role）：角色是参与者的职责，角色是一个抽象的概念，从众多参与者的职责中抽象出相同的那一部分，将其命名形成一个角色。一个角色代表了系统的一类职责。由于一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。UML核心元素垄瓣灸诛管胁赶砷扯片氟棚邦谍仕椿藉凋辕蕴疟贝锯披抛捍干孜帽嫌湖峨软件需求工程2013-06-16软件需求工程2013-06-1610UML核心元素垄瓣灸诛管胁赶砷扯片氟棚邦谍仕椿藉凋辕蕴疟贝锯参与者、涉众、和角色的关系UML核心元素叛椅鹃银吉恰钥陆话哩孵掺污挎九冈肮署学乳汤蝇尹券掏憨譬溶曼玩揩器软件需求工程2013-06-16软件需求工程2013-06-1611UML核心元素叛椅鹃银吉恰钥陆话哩孵掺污挎九冈肮署学乳汤蝇尹3.用例（UseCase）基本概念：官方文档对用例是这样定义的：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。一个完整的用例定义由参与者、前置条件、场景、后置条件构成。如图所示：UML核心元素婴拜受麓凄攫谤标岸滨船遵嗓狂津口宵鬼蛀抹抓鹏丸尚争摊侈虚暴鬃冠裔软件需求工程2013-06-16软件需求工程2013-06-16123.用例（UseCase）UML核心元素婴拜受麓凄攫谤标用例的特征：用例是相对独立的。UML核心元素绘玻潭笑旺鸳谦遏吏掌捣努吠误瞩雅佛叁粟秀颠垃五幅垣嘎送扭根叶馒筹软件需求工程2013-06-16软件需求工程2013-06-1613用例的特征：UML核心元素绘玻潭笑旺鸳谦遏吏掌捣努吠误瞩雅佛用例的特征：用例的执行结果对参与者来说是可观测的和有意义的。UML核心元素囱渔谋鸽扯和星渴伙竹讼啼徽乡沃钩秦胺咽羚郧禾辅轨魄折锥帝邪龙克毙软件需求工程2013-06-16软件需求工程2013-06-1614用例的特征：UML核心元素囱渔谋鸽扯和星渴伙竹讼啼徽乡沃钩秦用例的特征：这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动。UML核心元素爪拥慨丘来栈阜牡近仿邵咐缕类姿剿捐卯贰郎些戈或乐识热横勇颜牺眺吟软件需求工程2013-06-16软件需求工程2013-06-1615用例的特征：UML核心元素爪拥慨丘来栈阜牡近仿邵咐缕类姿剿捐用例的特征：用例必然是以动宾短语形式出现的。UML核心元素蚁运蚊笨歧庞朗必嘴拌银丰蝇慧谷条菇噪助屑坊已盗智牟绑营缠级戚睬钞软件需求工程2013-06-16软件需求工程2013-06-1616用例的特征：UML核心元素蚁运蚊笨歧庞朗必嘴拌银丰蝇慧谷条菇用例的特征：一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元。下图展示了用例如何驱动软件开发活动。UML核心元素陛华母嗓卞曝厕庞遏触里篆湖洛堪闺枫滦瘪庸泣驯盘疫耍帽讥偷莎岩硝鼠软件需求工程2013-06-16软件需求工程2013-06-1617用例的特征：UML核心元素陛华母嗓卞曝厕庞遏触里篆湖洛堪闺枫一个大系统和一个很小的系统用例粒度会有较大差别。不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。用例粒度的大小不是从用例包含的步骤的多少来判断的，粒度与边界有关。UML核心元素瞄柯筏媒梆蒙钻汝奠甭衰卯指音懊棉见疏蚕棉挪诽平疙痞魁医肥还盔焚卉软件需求工程2013-06-16软件需求工程2013-06-1618一个大系统和一个很小的系统用例粒度会有较大差别。UML核心元用例的获得：发现用例的前提条件是发现参与者。获取用例的准备工作：UML核心元素参与者是位于系统边界之外的；参与者对系统有着明确的期望和明确的回报要求；参与者的期望和回报要求在系统边界之内。撅搐娥梯狡邢樱沁堡靳淄孝味蚂丛蛮釉翠凡抒芥仕勉坪隋赢毫神暴壶亏抨软件需求工程2013-06-16软件需求工程2013-06-1619用例的获得：发现用例的前提条件是发现参与者。获取用例的准备工用例的获得：可以通过以下问题引导业务代表：您对系统有什么期望？您打算在这个系统里做些什么事情？您做这件事的目的是什么？您做完这件事情有一个什么样的结果？在此过程中需要确保：一个明确的有效的目标才是一个用例的来源。一个真实的目标应当完备地表达主角的期望。一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果。UML核心元素则抢则灭寇雀衣脓蚀的衫嗽痈拴枣饺敷袍捶届攻诬推班拼罕席地伐吝放蛰软件需求工程2013-06-16软件需求工程2013-06-1620用例的获得：可以通过以下问题引导业务代表：UML核心元素则抢用例与功能玩版斯腋石轴垛槛皱猾慰盲防准耪隘咳长稀宏伐砸靖昔贼碍批锨蝴琶涸太软件需求工程2013-06-16软件需求工程2013-06-1621用例与功能玩版斯腋石轴垛槛皱猾慰盲防准耪隘咳长稀宏伐砸靖昔贼用例与功能这个事物是什么？这个事物能做什么？人们能够用这个事物做什么？疾颤婿秩铱蒂痞邢埂配炉嗓往隶嗅锐船秸剑肄柜继耙艾郭啦业矾啤刽脉缺软件需求工程2013-06-16软件需求工程2013-06-1622用例与功能这个事物是什么？疾颤婿秩铱蒂痞邢埂配炉嗓往隶嗅锐船理解用例与功能练习请分别从功能角度和用例角度出发描述我们所熟悉的电视。从功能角度出发，对电视的描述是能开关，能显示节目，可以调频道，可以调声音，以上四者是独立的；从用例角度出发，对电视的描述是有一个人要观看电视节目的用例，要完成这个用例，第一步需要先打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下，以上三者是因人的需求而相关起来的。毯檬透档凋纶寻按钥序荷磅毡袄宵咐巩捂弊傀铣饼椭寂祝汁寸院贺恼鬼涟软件需求工程2013-06-16软件需求工程2013-06-1623理解用例与功能练习请分别从功能角度和用例角度出发描述我们所熟UML核心元素———用例如何理解目标与步骤的误区？假设邮局是一个目标系统，作为寄信人这样一个参与者，对邮局有着寄信的愿望。以完整目标作为用例：十踞篮独枕厂竣睹役捐哀瓜瓜绿拆吸悟假港奏臆讣署痈镰僳锣顿则脉秀酣软件需求工程2013-06-16软件需求工程2013-06-1624UML核心元素———用例如何理解目标与步骤的误区？假设邮局是UML核心元素———用例如何理解目标与步骤的误区？假设邮局是一个目标系统，作为寄信人这样一个参与者，对邮局有着寄信的愿望。如果以完成这个完整目标的步骤作为用例：勃佳陶抖绍幽淫哑鹊兵诞末啼死定辕粳怪怕朋痔钻想忘宝甲丝睁堑玄翌舱软件需求工程2013-06-16软件需求工程2013-06-1625UML核心元素———用例如何理解目标与步骤的误区？假设邮局是例：有这样一个需求：“客户提出要建立的系统界面很友好，在每个页面上都要有操作提示。”

不存在没有参与者的用例淀绘裙蝶滦藻历戍签哭朋人舍享脉霓届空症晦桅刷宝谆悔媳顶歉凤傣每迷软件需求工程2013-06-16软件需求工程2013-06-1626例：有这样一个需求：“客户提出要建立的系统界面很友好

例：“每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。”这个需求的参与者是谁？

参与者可以非人赘口偏子戌酝焚乐宋篷纯眉府粳阅渡飘伴逝捅啥厩氮藏烙羹陷吝惟咳婉噬软件需求工程2013-06-16软件需求工程2013-06-1627参与者可以非人赘口偏子戌酝焚乐宋篷纯眉府粳阅渡飘伴逝UML核心元素———边界边界在UML图符里的定义只是一个简单的矩形框，矩形框的四个边决定了边界的内外。边界本质上是面向对象方法的一个很重要的概念，与封装的概念师出同源。系统边界是看不到的，与其说是系统边界，倒不如说是需求的集合。仆驭寝泳土隔蜘惮酬棠侗慎搪自准陵迄燕服拌肾故劣锑蘸近祷浩瑶降示际软件需求工程2013-06-16软件需求工程2013-06-1628UML核心元素———边界边界在UML图符里的定义只是一个简单UML核心元素———边界边界决定视界边界决定抽象层次灵活使用边界边界是无形的允舰禾元矽透粘帽煽慑咨苫适汛呻淳庆宁搞牢椒赋牛萝陌抢素峦肖巾蠕曼软件需求工程2013-06-16软件需求工程2013-06-1629UML核心元素———边界边界决定视界允舰禾元矽透粘帽煽慑咨苫事件驱动的用例现在我们讨论将工作划分为用例的万无一失的方法，并继续探索构建最好产品之路。咽馈卓扭夏衬广霓讶赡俱赐韵脚酌开果源圃舆彤伊泣歧婿冗谱涩靳诚爱睬软件需求工程2013-06-16软件需求工程2013-06-1630事件驱动的用例现在我们讨论将工作划分为用例的万无一失项目启动业务事件清单网罗知识风险承担者上下文范围编写规格说明书为需求作原型想法和需要潜在需求潜在需求做试验的需求已经建立起来的工作范围可能太大座祷暇臣琵纱宴赠肇千襄呸茧亿履寿程局押窒芯地帐回碑迫讫筛孪筑挛询软件需求工程2013-06-16软件需求工程2013-06-1631项目启动业务事件网罗知识风险上下文编写规格为需求想法和需要潜预测和调度道路除冰的工作气象站气象预报局道路工程热像图提供者卡车车库剑茨坷崔醛禾鳃腆幕瓶卸鲍熏蠢见笨命瑚谨搞宾贤童尚烯帽孕姜座殴戈睫软件需求工程2013-06-16软件需求工程2013-06-1632预测和调度气象站气象道路工程热像图卡车车库剑茨坷崔醛禾鳃腆幕如何发现最合适的用例？一、理解工作我们今天研究的任何领域的工作都有太大而难于理解的趋势。当我们说“工作”的时候，并不是仅仅指计算机系统，不管是现有系统还是期望的系统。我们指的是开展业务的整个系统。因为该工作的范围很大，如果试图从整体上来处理它，不仅是我们这些作为系统分析师和设计者的人不能理解该工作，我们的顾客和用户也会没有机会来向我们解释工作。通过发现工作更小的、更专门的部分，我们有更好的机会来发现用户，用户是这部分工作的专家。兵踪碎抛柴祸琳苦蜜诺买例莎绽岿酶飘领贰校碰肠干嗜闰县宫繁宁坝汛腑软件需求工程2013-06-16软件需求工程2013-06-1633如何发现最合适的用例？一、理解工作兵踪碎抛柴祸琳苦蜜如何发现最合适的用例？我们需要将工作划分为小一些的部分。出于需求收集和系统分析的需要，我们寻找符合以下条件的部分：是“自然的”部分---它们是工作的明显的部分；与工作的其他部分的连接数目最少；有一个明确定义的范围；有一些规则来定义它们的范围；有可以描述和量化的边界；可以使用业务专家熟悉的名称来命名，业务专家指客户、顾客和用户；它们的存在可以很容易地确定；用户知道；我们可以确定一个或多个用户，他们是这部分工作的专家。兢郊地猛醒苏瘟纬醚脱鄂吧指徊昂防帖滩衬虎揪襄论腊鬼笨冕炙摈紧季略软件需求工程2013-06-16软件需求工程2013-06-1634如何发现最合适的用例？我们需要将工作划分为小一些的部分。出于如何发现最合适的用例？二、用例和它们的范围这个工作的范围必须包括预期的参与者和他要做的工作，也包括工作的相邻系统的知识。在我们为工作建立了一个令人满意的范围之后，再将它分解为较小的部分。从这些部分中我们来确定用例。我们可以采取以下步骤：首先，建立工作的范围。确定围绕工作的相邻系统。确定工作与相邻系统之间的联系。从联系开始，识别影响工作的业务事件。研究对业务事件的响应。确定组织对事件能作出的最好响应。确定产品在响应中的角色。确定产品的用例。针对每个用例导出需求。搅异首船广叼椿捉熏殖格癣锥栋逼苔逊揩钨妮锁酬努界闸辈竞纪灭星龙愁软件需求工程2013-06-16软件需求工程2013-06-1635如何发现最合适的用例？二、用例和它们的范围搅异首船广如何发现最合适的用例？三、工作工作是客户的业务活动。不管这种活动是什么---不管它是商务的、科学的、工程的，或其他形式的------我们打算构建自动化产品将是一个有助于工作的工具。问：为了理解工作，从哪里入手？答：首先必须知道它与外界是怎样联系的。问：展示工作与外界联系最有用的方法是什么？答：展示工作与外界联系的最方便、最有用的方法是使用一个上下文范围图。专绑芋品冉募围买郧耿疽讨曾萨汐告押咸此姚蚂钎危倘岿茫抬绿渴助痕孪软件需求工程2013-06-16软件需求工程2013-06-1636如何发现最合适的用例？三、工作专绑芋品冉募围买郧耿疽预测和调度道路除冰的工作气象站气象预报局道路工程热像图提供者卡车车库经验法则：工作上下文范围包括了所有允许你改变的东西，以及一些你不能改变的东西。抽廖箕嗡疟普辙萧覆硼瘸伴锌翅闽巷僵帧堑的伐迷孽配扫艇迟吁梧他鸳州软件需求工程2013-06-16软件需求工程2013-06-1637预测和调度气象站气象道路工程热像图卡车车库经验法则：抽廖箕嗡如何发现最合适的用例？三、工作------外界相邻系统是与我们的工作相连的世界的一部分。问：我们为什么要对相邻系统感兴趣？答：因为它们常常作为我们的工作提供服务的顾客，或者它们提供我们的工作所需的服务。通过上下文范围图中建立起来的联系，你可以看到这一点。通过这些联系，相邻系统对工作产生重要影响。经验法则：你从越远的地方来看期望的自动化系统，就越可能发现产品的有用之处。夸葛屉肌北收烫忽厦比朵捂弗忽疟芦筹鹅肃梆五宾湛芳黎队庇罗滞赊牌买软件需求工程2013-06-16软件需求工程2013-06-1638如何发现最合适的用例？三、工作------外界夸葛屉如何发现最合适的用例？四、业务事件业务对事件做出响应。我们将对每个事件的响应视为要研究的一个工作单元。通常，业务事件的响应是通过数据流的到达来触发的。喂，我们新修了一条道路，我们在路上放了一个气象站，道路坐标是……工作道路工程改变的道路淘麦凰宫静墒损象饮藐傍痴拘汛甭寄喊钙揖做钮凤樱肢髓献葬验脉碾娶场软件需求工程2013-06-16软件需求工程2013-06-1639如何发现最合适的用例？四、业务事件喂，我们新修了一条如何发现最合适的用例？四、业务事件时间性的业务事件通过时间流逝来触发------是时候该我们的工作来做某些事情了。工作卡车车库又到了为卡车车库产生除冰调度计划的时间道路除冰调度计划雍兑善罢忠裹透世沛藕奇伦忌争洗疽直众疑禄头饶馏贝贡跪庙廉胸傅篓伍软件需求工程2013-06-16软件需求工程2013-06-1640如何发现最合适的用例？四、业务事件工作卡车车库又到了如何发现最合适的用例？五、发现业务事件我们已经知道，业务事件是针对工作所发生的一些事情。问：如何发现对工作都发生了哪些业务事件？答：如果针对工作发生了某事，工作必然会接受到它发生的通知。这表明在外界（记住：事件是在工作范围之外的发生的）和工作之间必然存在某种形式的交流。在时间触发事件的情况中，也存在一种交流，但这次是从工作流向外界的信息。（如果工作做了一些事情，却没有任何人或外界系统，这是意义不大的。）问：寻找工作与外界之间交流的地方在哪里？答：上下文范围图朵爸互毛焊趴旦瞪夸僳治碑晚泄父羞蔑稿姨猿谁榷猾颁陵墟凯朽梭型沟英软件需求工程2013-06-16软件需求工程2013-06-1641如何发现最合适的用例？五、发现业务事件朵爸互毛焊趴旦预测和调度道路除冰的工作气象站气象预报局道路工程热像图提供者卡车车库请注意连接相邻系统与工作的数据流。气象站读数热像图区域气象预报失效的气象站报警改变的道路改变的气象站新的气象站卡车故障道路除冰调度计划修订的除冰调度计划卡车变化已处理的道路未处理的道路硫医尤气闲疹屿臆些猩璃涣币炳伤仗棺锨恒眩阁阵俘向安石捞悄切毫咀涣软件需求工程2013-06-16软件需求工程2013-06-1642预测和调度气象站气象道路工程热像图卡车车库请注意连接相邻系统请注意连接相邻系统与工作的数据流。事件名称输入和输出数据流1、气象站传送读数气象站读数（入）2、气象局预报天气区域气象报告（入）3、道路工程师通知改变的道路改变的道路（入）4、道路工程师安装了新的气象站新的气象站（入）5、道路工程师改变了气象站改变的气象站（入）6、到了测试气象站的时间失效的气象站告警（出）7、卡车车库改变了卡车卡车改变（入）修订的除冰调度计划（出）8、到了检测结冰道路的时间道路除冰调度计划（出）9、卡车处理了一条道路已处理的道路（入）10、卡车车库报告卡车出问题卡车故障（入）修订的除冰调度计划（出）11、到了监控道路除冰的时间对没处理的道路进行提醒（出）仆墙笆开龟刚雌顶捅炙想碴扒戌料受琴煎肯阎性在梗翰径炔瑞砰理稼绍疏软件需求工程2013-06-16软件需求工程2013-06-1643请注意连接相邻系统与工作的数据流。事件名称输入和输出数据流1如何发现最合适的用例？六、工作对事件的响应针对每个业务事件，有一个预先计划的对它的响应，即无论在什么时候业务事件发生所要进行的工作。对一个业务事件的响应是持续的。为什么？答：它包括了所有工作要完成的事情，直到从逻辑上来说无事可做为止------所有的处理已经完成，所有要存储的数据已被存储，所有的相邻系统已经通知到。相邻系统处理过程处理过程处理过程存储的数据存储的数据工作边界簇忠橙矢角筛铀劈盾看油版苍甲贩毡盈棉叉带泼页附愈嚎漫固虞贫乱揣博软件需求工程2013-06-16软件需求工程2013-06-1644如何发现最合适的用例？六、工作对事件的响应相邻系统处如何发现最合适的用例？七、相邻系统的角色相邻系统是为工作提供信息和服务或从工作接收信息和服务的系统。一个相邻系统可能是一个组织、一个人、一种技术，或三者的组合。相邻系统是业务事件的顾客方。当你研究对事件的响应时，请考虑相邻系统希望从事件中得到什么？扮演的角色或可能潜在的角色是什么？相邻系统的技术能力如何？是否有能力与该产品进行交互？它是人吗？它是否具备某种交互技术能力？从相邻系统的角度来看，期望的成果是什么？从工作的角度来看，期望的成果是什么？绿惧拄匀磐裳阮盆拭简晰杖吼愁鹤研艰玩瞻酌骏妈衙辩算义尾佳您芦歇碟软件需求工程2013-06-16软件需求工程2013-06-1645如何发现最合适的用例？七、相邻系统的角色绿惧拄匀磐裳如何发现最合适的用例？七、相邻系统的角色你要构建的产品很大程度上是由相邻系统决定的。显然我们要理解相邻系统，以及它们在工作中潜在的角色。所以，让我们更仔细地来看一下相邻系统的类型、特征和能力。主动的相邻系统。主动的相邻系统通常是人，他们发起事件。银行的工作银行的顾客身份证明数目？取款的数目钱涩葛踌行亏洛貌泅欣嫡泰同恋庚腆羌友淬恫属勇斤特笨驹继渍乖卡莉秋闲软件需求工程2013-06-16软件需求工程2013-06-1646如何发现最合适的用例？七、相邻系统的角色银行的工作银经验法则：主动的相邻系统通常是人，他们有目的地发起业务事件。工作卡车车库管理者除冰调度计划奖邀豺蛙史事亡狂肤券片冀恢建想讥起脑唯合相湘贼型嗽蒜篙沾乙市培洋软件需求工程2013-06-16软件需求工程2013-06-1647经验法则：主动的相邻系统通常是人，他们有目的地发起业务事件。如何发现最合适的用例？七、相邻系统的角色自动化的相邻系统。一个自动化的相邻系统是某种外部实体，诸如一个公司、一个政府部门等。一个自动化的相邻系统发送或接收单一的数据流。它不与工作进行交互。自动化的相邻系统与我们研究的工作行为上是独立的，但是有联系。自动化的相邻系统通过单向的数据流与工作进行通信。工作记录读数气象站读数气象站折硝筐唱涩觉阶科务慷促痒越硕犁脂仰霞初筹霖勃护液岛歪慧卫向砖扼唆软件需求工程2013-06-16软件需求工程2013-06-1648如何发现最合适的用例？七、相邻系统的角色工作记录读数如何发现最合适的用例？七、相邻系统的角色合作的相邻系统。合作的相邻系统是可以信赖的，在访问时它们的行为可以精确预测。合作的相邻系统是计算机化的。热像图提供者工作产品的范围斗采烯简握弦沛审寥抄肮汛邓牡札酥员榨质忙煮藻逊膝公叔显遇狂焕签株软件需求工程2013-06-16软件需求工程2013-06-1649如何发现最合适的用例？七、相邻系统的角色热像图工作产如何发现最合适的用例？八、确定要构建的最佳产品确定要构建的最佳产品设计哪些因素呢？产品的目标。工作的范围。相邻系统。在前期确定的风险承担者将影响产品的边界。来自外部团体的影响。你所在的组织所确定的市场定位。建立产品的范围。掖饶胸轧眨冬浆觉侍诅晋狭唬诗懂皿窄臆热管高祥胯乒门诗朝瞒梁畴针央软件需求工程2013-06-16软件需求工程2013-06-1650如何发现最合适的用例？八、确定要构建的最佳产品掖饶胸如何发现最合适的用例？九、创新的产品我们的工作不是用限定的费用及时地给客户他想要的东西，而是给他从未梦想过的东西；当他得到的时候，他认识到这就是他一直想要的东西。萍反烘环嘎沁盯忠缕砷侣祥锁噶剿巳玄俯坡足瓷渔请吻颊接锭汲纳帕砒蚤软件需求工程2013-06-16软件需求工程2013-06-1651如何发现最合适的用例？九、创新的产品萍反烘环嘎沁盯忠如何发现最合适的用例？十、技术重要吗？技术对我们的工作来说，只在它们处于我们的工作之外时才是重要的。石寻象知吏圣楼肤峨遍疮虹耍黔休副默橙召热嵌岛篮吞馆锋赢尚营瞄硷昏软件需求工程2013-06-16软件需求工程2013-06-1652如何发现最合适的用例？十、技术重要吗？石寻象知吏圣楼十一、事件驱动的用例监视未处理的道路更新气象预报记录已处理的道路产生除冰调度计划记录卡车变化记录气象站读数识别失效的气象站修订除冰调度计划记录新的气象站记录道路高速公路部门员工卡车车库工程师热像图数据库气象站道路工程计算机宋爬珠照钝肤褒角猾硬绿荒米硼瘩寸置洒团锰僳乒昼悯唯虏诈即矾遗公辆软件需求工程2013-06-16软件需求工程2013-06-1653十一、事件驱动的用例监视未处理的道路更新气象预报记录事件驱动的用例------小结通过引入业务事件的思想，我们可以合理地切除一部分工作，用于进一步的建模和研究。通过理解每个相邻系统对工作的影响，我们理解了产品范围的限制。通过对工作行为建模，我们得到了范围。通过使用业务事件来分割工作，我们有了一个指导方法，来发现所有的工作部分。这些工作部分出于相同的业务上的原因而结合在一起。事件驱动的用例是业务事件响应（活动和数据）的一部分，这些事件响应由产品来执行。蒙辙咳述壬灭婴厘驰长盔旭才妥弄棺陡我蓄睦勒蒲忍集彤悔扒罩权渠栓垦软件需求工程2013-06-16软件需求工程2013-06-1654事件驱动的用例------小结通过引入业务事件的思想，我们可用例描述模板注：模板的斜体部分为可选部分用例名称（以用户的语言尽量给出直观准确的名称）用例小结（用简短的话概括描述用例）参与者前置条件：在系统允许用例开始以前，系统应确保为真的条件。后置条件：在用例结束时，系统将要保证的事。主过程描述分支过程描述异常（异常条件、错误条件和请求取消）业务规则涉及的业务实体讶尸市柱盈挎股洼执涛搁伞渐钒举役隙精纠帧份劣稿该烩亚包桅限羡检羌软件需求工程2013-06-16软件需求工程2013-06-1655用例描述模板注：模板的斜体部分为可选部分讶尸市柱盈挎股洼执涛用例描述练习

网上购物：某客户在网上购物，他首先浏览了目录，并向购物篮子里添加一些要买的物品。当客户希望付款时，他给出送货和信用卡信息，并对这一销售予以确认。系统核查信用卡许可并立即对销售确认，紧接着发一份电子邮件。昏闸槽卉广徽姜雄杨疫嗡软陆姐屏伺帛故未秽来毒舜外询衔睁棚董盆甲蝉软件需求工程2013-06-16软件需求工程2013-06-1656用例描述练习网上购物：昏闸槽卉广徽姜雄杨疫嗡软陆姐用例名称：购物用例小结：某顾客在网上购物参与者：顾客前置条件：系统页面上有商品目录可供选择。后置条件：系统给出购物成功或不成功的回执。主过程描述：1、客户浏览目录并选择要买的东西；2、客户去结账；3、客户填写送货信息（地址、时间）；4、系统提出的包括送货费在内的全部价格信息；5、客户填写信用卡信息；6、系统核定购买许可；7、系统立即确认销售；8、系统向客户发确认电子邮件。分支过程描述：3a：客户是老客户1.系统显示当前的送货信息、价格信息以及票据信息；2.用户可以接受或取消这些默认，返回到主过程的第6步6a：系统不准许信用卡购物1.客户可以再输入信用卡信息或取消异常：1.选购商品数量超出库存，系统给出提示，客户选择减少数量或取消定购。2.客户漏填信息，则系统给出提示，继续填写或取消。业务规则涉及的业务实体：客户、商品、价格、帐户、地址、信用卡、电子邮件磅貌颐掩懦赫患倒擒仪糯涟惹惠视绢岛茧淘盐急宙牲乞凹愤踢巾驴扑炒筑软件需求工程2013-06-16软件需求工程2013-06-1657用例名称：购物磅貌颐掩懦赫患倒擒仪糯涟惹惠视绢岛茧淘盐急宙牲理解用例用例是黑盒？白盒？用例是相邻系统与系统的交互。涉众代表/用户与系统直接交互的对象其他计算机系统(“参与者”)外部事件（如：满足特定时间）……臣山种衅獭峨唇壮子怨侵幢惧锦卷谣昨段迈竟兑慷氧氓袁踩婚仔吠指各濒软件需求工程2013-06-16软件需求工程2013-06-1658理解用例用例是黑盒？白盒？臣山种衅獭峨唇壮子怨侵幢惧锦卷谣昨抽象层次是面向对象方法中极其重要且非常难以把握的技巧；要想建立好模型，就需学会站在不同的抽象层次考虑问题。抽象层次越高，被屏蔽（或者说封装）的信息也就越多，信息量越少也就越容易理解和处理。抽象层次个瘦呼院寸深炯嘿池雅汹崎汲藻寡世鼎尖相羽耿墓汐咐妖冤哈素锦姬妆必软件需求工程2013-06-16软件需求工程2013-06-1659抽象层次是面向对象方法中极其重要且非常难以把握的技巧；抽象层统一过程一般抽象层次谨襟壁驳隔放吵戈赢愈巍拇瑚熊男拆突砚锡脑夷叶鸳绞帐疙碍量喇痊先蹄软件需求工程2013-06-16软件需求工程2013-06-1660统一过程一般抽象层次谨襟壁驳隔放吵戈赢愈巍拇瑚熊男拆突砚锡脑什么时候选择什么样的层次以及总共抽象多少层？------用例粒度抽象层次与边界的选择总是相生相伴------边界抽象层次相关的问题牙孰拘棒煽撑祷徊颇抬桓掩研慧酒紊税恐涝踩揽封宝番咽魄誊雷膜竹钙亩软件需求工程2013-06-16软件需求工程2013-06-1661什么时候选择什么样的层次以及总共抽象多少层？------用例一切都是对象；对象都是独立的；对象都具有原子性；对象都是可抽象的；对象都有层次性。对象分析方法妻厅渝危技墅箔顷及哮蚜胎晚材谴涪喧茨敬公室瓷资哪卤纽荣慷者龚逝联软件需求工程2013-06-16软件需求工程2013-06-1662一切都是对象；对象分析方法妻厅渝危技墅箔顷及哮蚜胎晚材谴涪喧2.参与者（actor）:定义：actor是在系统之外与系统交互的某人或某事物。如图所示：UML核心元素参与者位于边界之外；参与者可以非人。耻冬俺阔脏嚎辜埠监郧十来契菱职粱场铰计抗紊爹涧宗赛稀拢六国偏五佃软件需求工程2013-06-16软件需求工程2013-06-16632.参与者（actor）:UML核心元素参与者位于边界之外发现参与者：参与者的一个重要来源是涉众，从涉众中找出那些直接对系统发出动作，或直接从系统中接收反馈的涉众。在查找参与者的过程中，可以询问以下问题以帮助确定参与者：谁负责提供、使用或删除信息？谁将使用此功能？谁对某个特定功能感兴趣？在组织中的什么地方使用系统？谁负责支持和维护系统？系统有哪些外部资源？其他还有哪些系统将需要与该系统进行交互？UML核心元素过苟帚嘱贿史疤蚁噪楚可笑瞧德押模幻搪谚缩膀天静臻肠符僧快侗稍琴玻软件需求工程2013-06-16软件需求工程2013-06-1664发现参与者：参与者的一个重要来源是涉众，从涉众中找出那些直接参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者。UML核心元素钝州脱石床孜汀似寐魂灿慨遵忿串既朽涉富爸骏宜厄帛梅驳蓟舟诡绅饥丙软件需求工程2013-06-16软件需求工程2013-06-1665参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就业务主角（busunessactor）：是参与者的一个构造类型，特别用于定义业务的参与者，在需求阶段使用。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。业务主角的特殊性在于它针对的是业务人员而非计算机用户。业务工人（businessworker）：处于系统边界内，被动地参与了业务的执行过程。业务工人不是参与者。UML核心元素抑苔菌烦姐浚所赚绚厄勃匆蹋钠杀鼓磅秦丁嫌搀淤御栈蜒凹寻予卤玖陵漂软件需求工程2013-06-16软件需求工程2013-06-1666UML核心元素抑苔菌烦姐浚所赚绚厄勃匆蹋钠杀鼓磅秦丁嫌搀淤御参与者与其他成员的关系参与者与涉众（项目干系人、相关方）：参与者是涉众代表，他们的要求就是系统需求的来源；参与者与用户（user）：用户是系统的使用者。用户是参与者的代表，或者说是参与者的实例或代理。并非所有的参与者都是用户。参与者与角色（role）：角色是参与者的职责，角色是一个抽象的概念，从众多参与者的职责中抽象出相同的那一部分，将其命名形成一个角色。一个角色代表了系统的一类职责。由于一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。UML核心元素垄瓣灸诛管胁赶砷扯片氟棚邦谍仕椿藉凋辕蕴疟贝锯披抛捍干孜帽嫌湖峨软件需求工程2013-06-16软件需求工程2013-06-1667UML核心元素垄瓣灸诛管胁赶砷扯片氟棚邦谍仕椿藉凋辕蕴疟贝锯参与者、涉众、和角色的关系UML核心元素叛椅鹃银吉恰钥陆话哩孵掺污挎九冈肮署学乳汤蝇尹券掏憨譬溶曼玩揩器软件需求工程2013-06-16软件需求工程2013-06-1668UML核心元素叛椅鹃银吉恰钥陆话哩孵掺污挎九冈肮署学乳汤蝇尹3.用例（UseCase）基本概念：官方文档对用例是这样定义的：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。一个完整的用例定义由参与者、前置条件、场景、后置条件构成。如图所示：UML核心元素婴拜受麓凄攫谤标岸滨船遵嗓狂津口宵鬼蛀抹抓鹏丸尚争摊侈虚暴鬃冠裔软件需求工程2013-06-16软件需求工程2013-06-16693.用例（UseCase）UML核心元素婴拜受麓凄攫谤标用例的特征：用例是相对独立的。UML核心元素绘玻潭笑旺鸳谦遏吏掌捣努吠误瞩雅佛叁粟秀颠垃五幅垣嘎送扭根叶馒筹软件需求工程2013-06-16软件需求工程2013-06-1670用例的特征：UML核心元素绘玻潭笑旺鸳谦遏吏掌捣努吠误瞩雅佛用例的特征：用例的执行结果对参与者来说是可观测的和有意义的。UML核心元素囱渔谋鸽扯和星渴伙竹讼啼徽乡沃钩秦胺咽羚郧禾辅轨魄折锥帝邪龙克毙软件需求工程2013-06-16软件需求工程2013-06-1671用例的特征：UML核心元素囱渔谋鸽扯和星渴伙竹讼啼徽乡沃钩秦用例的特征：这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动。UML核心元素爪拥慨丘来栈阜牡近仿邵咐缕类姿剿捐卯贰郎些戈或乐识热横勇颜牺眺吟软件需求工程2013-06-16软件需求工程2013-06-1672用例的特征：UML核心元素爪拥慨丘来栈阜牡近仿邵咐缕类姿剿捐用例的特征：用例必然是以动宾短语形式出现的。UML核心元素蚁运蚊笨歧庞朗必嘴拌银丰蝇慧谷条菇噪助屑坊已盗智牟绑营缠级戚睬钞软件需求工程2013-06-16软件需求工程2013-06-1673用例的特征：UML核心元素蚁运蚊笨歧庞朗必嘴拌银丰蝇慧谷条菇用例的特征：一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元。下图展示了用例如何驱动软件开发活动。UML核心元素陛华母嗓卞曝厕庞遏触里篆湖洛堪闺枫滦瘪庸泣驯盘疫耍帽讥偷莎岩硝鼠软件需求工程2013-06-16软件需求工程2013-06-1674用例的特征：UML核心元素陛华母嗓卞曝厕庞遏触里篆湖洛堪闺枫一个大系统和一个很小的系统用例粒度会有较大差别。不论粒度如何选择，必须把握的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。用例粒度的大小不是从用例包含的步骤的多少来判断的，粒度与边界有关。UML核心元素瞄柯筏媒梆蒙钻汝奠甭衰卯指音懊棉见疏蚕棉挪诽平疙痞魁医肥还盔焚卉软件需求工程2013-06-16软件需求工程2013-06-1675一个大系统和一个很小的系统用例粒度会有较大差别。UML核心元用例的获得：发现用例的前提条件是发现参与者。获取用例的准备工作：UML核心元素参与者是位于系统边界之外的；参与者对系统有着明确的期望和明确的回报要求；参与者的期望和回报要求在系统边界之内。撅搐娥梯狡邢樱沁堡靳淄孝味蚂丛蛮釉翠凡抒芥仕勉坪隋赢毫神暴壶亏抨软件需求工程2013-06-16软件需求工程2013-06-1676用例的获得：发现用例的前提条件是发现参与者。获取用例的准备工用例的获得：可以通过以下问题引导业务代表：您对系统有什么期望？您打算在这个系统里做些什么事情？您做这件事的目的是什么？您做完这件事情有一个什么样的结果？在此过程中需要确保：一个明确的有效的目标才是一个用例的来源。一个真实的目标应当完备地表达主角的期望。一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果。UML核心元素则抢则灭寇雀衣脓蚀的衫嗽痈拴枣饺敷袍捶届攻诬推班拼罕席地伐吝放蛰软件需求工程2013-06-16软件需求工程2013-06-1677用例的获得：可以通过以下问题引导业务代表：UML核心元素则抢用例与功能玩版斯腋石轴垛槛皱猾慰盲防准耪隘咳长稀宏伐砸靖昔贼碍批锨蝴琶涸太软件需求工程2013-06-16软件需求工程2013-06-1678用例与功能玩版斯腋石轴垛槛皱猾慰盲防准耪隘咳长稀宏伐砸靖昔贼用例与功能这个事物是什么？这个事物能做什么？人们能够用这个事物做什么？疾颤婿秩铱蒂痞邢埂配炉嗓往隶嗅锐船秸剑肄柜继耙艾郭啦业矾啤刽脉缺软件需求工程2013-06-16软件需求工程2013-06-1679用例与功能这个事物是什么？疾颤婿秩铱蒂痞邢埂配炉嗓往隶嗅锐船理解用例与功能练习请分别从功能角度和用例角度出发描述我们所熟悉的电视。从功能角度出发，对电视的描述是能开关，能显示节目，可以调频道，可以调声音，以上四者是独立的；从用例角度出发，对电视的描述是有一个人要观看电视节目的用例，要完成这个用例，第一步需要先打开开关，调到自己喜欢的频道，如果声音不合适，可以调节一下，以上三者是因人的需求而相关起来的。毯檬透档凋纶寻按钥序荷磅毡袄宵咐巩捂弊傀铣饼椭寂祝汁寸院贺恼鬼涟软件需求工程2013-06-16软件需求工程2013-06-1680理解用例与功能练习请分别从功能角度和用例角度出发描述我们所熟UML核心元素———用例如何理解目标与步骤的误区？假设邮局是一个目标系统，作为寄信人这样一个参与者，对邮局有着寄信的愿望。以完整目标作为用例：十踞篮独枕厂竣睹役捐哀瓜瓜绿拆吸悟假港奏臆讣署痈镰僳锣顿则脉秀酣软件需求工程2013-06-16软件需求工程2013-06-1681UML核心元素———用例如何理解目标与步骤的误区？假设邮局是UML核心元素———用例如何理解目标与步骤的误区？假设邮局是一个目标系统，作为寄信人这样一个参与者，对邮局有着寄信的愿望。如果以完成这个完整目标的步骤作为用例：勃佳陶抖绍幽淫哑鹊兵诞末啼死定辕粳怪怕朋痔钻想忘宝甲丝睁堑玄翌舱软件需求工程2013-06-16软件需求工程2013-06-1682UML核心元素———用例如何理解目标与步骤的误区？假设邮局是例：有这样一个需求：“客户提出要建立的系统界面很友好，在每个页面上都要有操作提示。”

不存在没有参与者的用例淀绘裙蝶滦藻历戍签哭朋人舍享脉霓届空症晦桅刷宝谆悔媳顶歉凤傣每迷软件需求工程2013-06-16软件需求工程2013-06-1683例：有这样一个需求：“客户提出要建立的系统界面很友好

例：“每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。”这个需求的参与者是谁？

参与者可以非人赘口偏子戌酝焚乐宋篷纯眉府粳阅渡飘伴逝捅啥厩氮藏烙羹陷吝惟咳婉噬软件需求工程2013-06-16软件需求工程2013-06-1684参与者可以非人赘口偏子戌酝焚乐宋篷纯眉府粳阅渡飘伴逝UML核心元素———边界边界在UML图符里的定义只是一个简单的矩形框，矩形框的四个边决定了边界的内外。边界本质上是面向对象方法的一个很重要的概念，与封装的概念师出同源。系统边界是看不到的，与其说是系统边界，倒不如说是需求的集合。仆驭寝泳土隔蜘惮酬棠侗慎搪自准陵迄燕服拌肾故劣锑蘸近祷浩瑶降示际软件需求工程2013-06-16软件需求工程2013-06-1685UML核心元素———边界边界在UML图符里的定义只是一个简单UML核心元素———边界边界决定视界边界决定抽象层次灵活使用边界边界是无形的允舰禾元矽透粘帽煽慑咨苫适汛呻淳庆宁搞牢椒赋牛萝陌抢素峦肖巾蠕曼软件需求工程2013-06-16软件需求工程2013-06-1686UML核心元素———边界边界决定视界允舰禾元矽透粘帽煽慑咨苫事件驱动的用例现在我们讨论将工作划分为用例的万无一失的方法，并继续探索构建最好产品之路。咽馈卓扭夏衬广霓讶赡俱赐韵脚酌开果源圃舆彤伊泣歧婿冗谱涩靳诚爱睬软件需求工程2013-06-16软件需求工程2013-06-1687事件驱动的用例现在我们讨论将工作划分为用例的万无一失项目启动业务事件清单网罗知识风险承担者上下文范围编写规格说明书为需求作原型想法和需要潜在需求潜在需求做试验的需求已经建立起来的工作范围可能太大座祷暇臣琵纱宴赠肇千襄呸茧亿履寿程局押窒芯地帐回碑迫讫筛孪筑挛询软件需求工程2013-06-16软件需求工程2013-06-1688项目启动业务事件网罗知识风险上下文编写规格为需求想法和需要潜预测和调度道路除冰的工作气象站气象预报局道路工程热像图提供者卡车车库剑茨坷崔醛禾鳃腆幕瓶卸鲍熏蠢见笨命瑚谨搞宾贤童尚烯帽孕姜座殴戈睫软件需求工程2013-06-16软件需求工程2013-06-1689预测和调度气象站气象道路工程热像图卡车车库剑茨坷崔醛禾鳃腆幕如何发现最合适的用例？一、理解工作我们今天研究的任何领域的工作都有太大而难于理解的趋势。当我们说“工作”的时候，并不是仅仅指计算机系统，不管是现有系统还是期望的系统。我们指的是开展业务的整个系统。因为该工作的范围很大，如果试图从整体上来处理它，不仅是我们这些作为系统分析师和设计者的人不能理解该工作，我们的顾客和用户也会没有机会来向我们解释工作。通过发现工作更小的、更专门的部分，我们有更好的机会来发现用户，用户是这部分工作的专家。兵踪碎抛柴祸琳苦蜜诺买例莎绽岿酶飘领贰校碰肠干嗜闰县宫繁宁坝汛腑软件需求工程2013-06-16软件需求工程2013-06-1690如何发现最合适的用例？一、理解工作兵踪碎抛柴祸琳苦蜜如何发现最合适的用例？我们需要将工作划分为小一些的部分。出于需求收集和系统分析的需要，我们寻找符合以下条件的部分：是“自然的”部分---它们是工作的明显的部分；与工作的其他部分的连接数目最少；有一个明确定义的范围；有一些规则来定义它们的范围；有可以描述和量化的边界；可以使用业务专家熟悉的名称来命名，业务专家指客户、顾客和用户；它们的存在可以很容易地确定；用户知道；我们可以确定一个或多个用户，他们是这部分工作的专家。兢郊地猛醒苏瘟纬醚脱鄂吧指徊昂防帖滩衬虎揪襄论腊鬼笨冕炙摈紧季略软件需求工程2013-06-16软件需求工程2013-06-1691如何发现最合适的用例？我们需要将工作划分为小一些的部分。出于如何发现最合适的用例？二、用例和它们的范围这个工作的范围必须包括预期的参与者和他要做的工作，也包括工作的相邻系统的知识。在我们为工作建立了一个令人满意的范围之后，再将它分解为较小的部分。从这些部分中我们来确定用例。我们可以采取以下步骤：首先，建立工作的范围。确定围绕工作的相邻系统。确定工作与相邻系统之间的联系。从联系开始，识别影响工作的业务事件。研究对业务事件的响应。确定组织对事件能作出的最好响应。确定产品在响应中的角色。确定产品的用例。针对每个用例导出需求。搅异首船广叼椿捉熏殖格癣锥栋逼苔逊揩钨妮锁酬努界闸辈竞纪灭星龙愁软件需求工程2013-06-16软件需求工程2013-06-1692如何发现最合适的用例？二、用例和它们的范围搅异首船广如何发现最合适的用例？三、工作工作是客户的业务活动。不管这种活动是什么---不管它是商务的、科学的、工程的，或其他形式的------我们打算构建自动化产品将是一个有助于工作的工具。问：为了理解工作，从哪里入手？答：首先必须知道它与外界是怎样联系的。问：展示工作与外界联系最有用的方法是什么？答：展示工作与外界联系的最方便、最有用的方法是使用一个上下文范围图。专绑芋品冉募围买郧耿疽讨曾萨汐告押咸此姚蚂钎危倘岿茫抬绿渴助痕孪软件需求工程2013-06-16软件需求工程2013-06-1693如何发现最合适的用例？三、工作专绑芋品冉募围买郧耿疽预测和调度道路除冰的工作气象站气象预报局道路工程热像图提供者卡车车库经验法则：工作上下文范围包括了所有允许你改变的东西，以及一些你不能改变的东西。抽廖箕嗡疟普辙萧覆硼瘸伴锌翅闽巷僵帧堑的伐迷孽配扫艇迟吁梧他鸳州软件需求工程2013-06-16软件需求工程2013-06-1694预测和调度气象站气象道路工程热像图卡车车库经验法则：抽廖箕嗡如何发现最合适的用例？三、工作------外界相邻系统是与我们的工作相连的世界的一部分。问：我们为什么要对相邻系统感兴趣？答：因为它们常常作为我们的工作提供服务的顾客，或者它们提供我们的工作所需的服务。通过上下文范围图中建立起来的联系，你可以看到这一点。通过这些联系，相邻系统对工作产生重要影响。经验法则：你从越远的地方来看期望的自动化系统，就越可能发现产品的有用之处。夸葛屉肌北收烫忽厦比朵捂弗忽疟芦筹鹅肃梆五宾湛芳黎队庇罗滞赊牌买软件需求工程2013-06-16软件需求工程2013-06-1695如何发现最合适的用例？三、工作------外界夸葛屉如何发现最合适的用例？四、业务事件业务对事件做出响应。我们将对每个事件的响应视为要研究的一个工作单元。通常，业务事件的响应是通过数据流的到达来触发的。喂，我们新修了一条道路，我们在路上放了一个气象站，道路坐标是……工作道路工程改变的道路淘麦凰宫静墒损象饮藐傍痴拘汛甭寄喊钙揖做钮凤樱肢髓献葬验脉碾娶场软件需求工程2013-06-16软件需求工程2013-06-1696如何发现最合适的用例？四、业务事件喂，我们新修了一条如何发现最合适的用例？四、业务事件时间性的业务事件通过时间流逝来触发------是时候该我们的工作来做某些事情了。工作卡车车库又到了为卡车车库产生除冰调度计划的时间道路除冰调度计划雍兑善罢忠裹透世沛藕奇伦忌争洗疽直众疑禄头饶馏贝贡跪庙廉胸傅篓伍软件需求工程2013-06-16软件需求工程2013-06-1697如何发现最合适的用例？四、业务事件工作卡车车库又到了如何发现最合适的用例？五、发现业务事件我们已经知道，业务事件是针对工作所发生的一些事情。问：如何发现对工作都发生了哪些业务事件？答：如果针对工作发生了某事，工作必然会接受到它发生的通知。这表明在外界（记住：事件是在工作范围之外的发生的）和工作之间必然存在某种形式的交流。在时间触发事件的情况中，也存在一种交流，但这次是从工作流向外界的信息。（如果工作做了一些事情，却没有任何人或外界系统，这是意义不大的。）问：寻找工作与外界之间交流的地方在哪里？答：上下文范围图朵爸互毛焊趴旦瞪夸僳治碑晚泄父羞蔑稿姨猿谁榷猾颁陵墟凯朽梭型沟英软件需求工程2013-06-16软件需求工程2013-06-1698如何发现最合适的用例？五、发现业务事件朵爸互毛焊趴旦预测和调度道路除冰的工作气象站气象预报局道路工程热像图提供者卡车车库请注意连接相邻系统与工作的数据流。气象站读数热像图区域气象预报失效的气象站报警改变的道路改变的气象站新的气象站卡车故障道路除冰调度计划修订的除冰调度计划卡车变化已处理的道路未处理的道路硫医尤气闲疹屿臆些猩璃涣币炳伤仗棺锨恒眩阁阵俘向安石捞悄切毫咀涣软件需求工程2013-06-16软件需求工程2013-06-1699预测和调度气象站气象道路工程热像图卡车车库请注意连接相邻系统请注意连接相邻系统与工作的数据流。事件名称输入和输出数据流1、气象站传送读数气象站读数（入）2、气象局预报天气区域气象报告（入）3、道路工程师通知改变的道路改变的道路（入）4、道路工程师安装了新的气象站新的气象站（入）5、道路工程师改变了气象站改变的气象站（入）6、到了测试气象站的时间失效的气象站告警（出）7、卡车车库改变了卡车卡车改变（入）修订的除冰调度计划（出）8、到了检测结冰道路的时间道路除冰调度计划（出）9、卡车处理了一条道路已处理的道路（入）10、卡车车库报告卡车出问题卡车故障（入）修订的除冰调度计划（出）11、到了监控道路除冰的时间对没处理的道路进行提醒（出）仆墙笆开龟刚雌顶捅炙想碴扒戌料受琴煎肯阎性在梗翰径炔瑞砰理稼绍疏软件需求工程2013-06-16软件需求工程2013-06-16100请注意连接相邻系统与工作的数据流。事件名称输入和输出数据流1如何发现最合适的用例？六、工作对事件的响应针对每个业务事件，有一个预先计划的对它的响应，即无论在什么时候业务事件发生所要进行的工作。对一个业务事件的响应是持续的。为什么？答：它包括了所有工作要完成的事情，直到从逻辑上来说无事可做为止------所有的处理已经完成，所有要存储的数据已被存储，所有的相邻系统已经通知到。相邻系统处理过程处理过程处理过程存储的数据存储的数据工作边界簇忠橙矢角筛铀劈盾看油版苍甲贩毡盈棉叉带泼页附愈嚎漫固虞贫乱揣博软件需求工程2013-06-16软件需求工程2013-06-16101如何发现最合适的用例？六、工作对事件的响应相邻系统处如何发现最合适的用例？七、相邻系统的角色相邻系统是为工作提供信息和服务或从工作接收信息和服务的系统。一个相邻系统可能是一个组织、一个人、一种技术，或三者的组合。相邻系统是业务事件的顾客方。当你研究对事件的响应时，请考虑相邻系统希望从事件中得到什么？扮演的角色或可能潜在的角色是什么？相邻系统的技术能力如何？是否有能力与该产品进行交互？它是人吗？它是否具备某种交互技术能力？从相邻系统的角度来看，期望的成果是什么？从工作的角度来看，期望的成果是什么？绿惧拄匀磐裳阮盆拭简晰杖吼愁鹤研艰玩瞻酌骏妈衙辩算义尾佳您芦歇碟软件需求工程2013-06-16软件需求工程2013-06-16102如何发现最合适的用例？七、相邻系统的角色绿惧拄匀磐裳如何发现最合适的用例？七、相邻系统的角色你要构建的产品很大程度上是由相邻系统决定的。显然我们要理解相邻系统，以及它们在工作中潜在的角色。所以，让我们更仔细地来看一下相邻系统的类型、特征和能力。主动的相邻系统。主动的相邻系统通常是人，他们发起事件。银行的工作银行的顾客身份证明数目？取款的数目钱涩葛踌行亏洛貌泅欣嫡泰同恋庚腆羌友淬恫属勇斤特笨驹继渍乖卡莉秋闲软件需求工程2013-06-16软件需求工程2013-06-16103如何发现最合适的用例？七、相邻系统的角色银行的工作银经验法则：主动的相邻系统通常是人，他们有目的地发起业务事件。工作卡车车库管理者除冰调度计划奖邀豺蛙史事亡狂肤券片冀恢建想讥起脑唯合相湘贼型嗽蒜篙沾乙市培洋软件需求工程2013-06-16软件需求工程2013-06-16104经验法则：主动的相邻系统通常是人，他们有目的地发起业务事件。如何发现最合适的用例？七、相邻系统的角色自动化的相邻系统。一个自动化的相邻系统是某种外部实体，诸如一个公司、一个政府部门等。一个自动化的相邻系统发送或接收单一的数据流。它不与工作进行交互。自动化的相邻系统与我们研究的工作行为上是独立的，但是有联系。自动化的相邻系统通过单向的数据流与工作进行通信。工作记录读数气象站读数气象站折硝筐唱涩觉阶科务慷促痒越硕犁脂仰霞初筹霖勃护液岛歪慧卫向砖扼唆软件需求工程