系统分析与设计ch02需求用例

1需求&用例

－－分析者必备浙江大学软件学院程学林开发流程3图6-1UP制品影响力示例面向对象与面向过程区别如果你的分析习惯是在调研需求时先弄清楚有多少业务流程，先画出业务数据流程图，然后顺藤摸瓜，找业务流程中每一步骤的参与部门或岗位，弄清楚这一步参与者所做的事情和填写表单的结果，并关心用户是否如何把这份表单传给到下一环节的。那么很不幸，你还在做面向过程的事情。如果你的分析习惯是在调研需求时最先弄清楚有多少个部门，多少岗位，然后找到每个岗位的业务代表，问他们类似的问题：你平时都做什么？这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？…那么恭喜你，你已经ＯＯ拉！获取用例的准备工作议程需求定义用例及用例图用例描述UP中如何使用用例分析者必学元素识别参与者识别用例编写用例描述案例实践与分析RequirementsFactorsonchallengedsoftwareprojects37%offactorsrelatedtoproblemswithrequirementsWaterfallModelActualuseofrequestedfeatures

Whatisrequirement?Requirementsarecapabilitiesandconditionstowhichthesystem(andmorebroadly,theproject)mustconform.[JBR99].TypesofRequirements

–FURPS+:Functional，features,capabilities,security.Usability，humanfactors,help,documentation.Reliability，frequencyoffailure,recoverability,predictability.Performance，responsetimes,throughput,accuracy,availability,resourceusage.Supportabilityadaptability,maintainability,internationalization,configurability.TypesofRequirements

–FURPS+The“+”inFURPS+indicatesancillary（辅助的）andsub-factors,suchas:Implementationresourcelimitations,languagesandtools,hardware,...Interfaceconstraintsimposedbyinterfacingwithexternalsystems.Operationssystemmanagementinitsoperationalsetting.PackagingLegallicensingandsoforth.HowareRequirementsOrganizedinUPArtifacts?Vision Ashortexecutiveoverviewdocumentforquicklylearningtheproject'sbigideas.Use-CaseModelfunctional(behavioral)requirements.SupplementarySpecificationallnon-functionalrequirements,suchasperformanceorlicensing.GlossaryBusinessRulesWhatareActors,Scenarios,andUseCases?Anactorissomethingwithbehavior,suchasaperson(identifiedbyrole),computersystem,ororganization;forexample,acashier.Ascenarioisaspecificsequenceofactionsandinteractionsbetweenactorsandthesystem;itisalsocalledausecaseinstance.Ausecaseisacollectionofrelatedsuccessandfailurescenariosthatdescribeanactorusingasystemtosupportagoal.ThreekindsofexternalactorsPrimary(主要)actorhasusergoalsfulfilledthroughusingservicesoftheSuD.Tofindusergoals,whichdrivetheusecases.Supporting（协助、支持）actorprovidesaservice(forexample,information)totheSuD.Toclarifyexternalinterfacesandprotocols.Offstage（幕后）actorhasaninterestinthebehavioroftheusecase,butisnotprimaryorsupporting;forexample,agovernmenttaxagency.场景（Scenario）特点是系统的一个特定情节或用例的一条执行路径是从用例中实例化出来的一组活动，一个用例可实例化出多个用例实例一个用例定义了一组用例实例，是对一组用例实例的抽象用例（UseCase）的定义站在用户角度定义软件系统的外部特征可表示系统所提供的服务或可执行的某种行为用例是一种把现实世界的需求捕获下来的方法。用例的概念在1986年由IvarJacobson正式提出之后被广泛接受，迅速发展，已成为OO、UML、RUP的标准规范和方法。一组用例实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对某个参与者而言可观察的结果。【RUP】一组用例实例一个用例由一组可产生某些特定结果的行为构成，这些行为是不可再分解的(接收用户输入、执行、产生结果)可观测到的、有价值的结果(observableresultofvalue)用例必须对用户产生价值；系统执行(systemperforms)系统为外部参与者提供服务；特定的参与者(particularactor)：某人、某台设备、某外部系统、等等，能够触发某些行为。用例描述（文本）是最要的，而不是图形用例建模主要是编写文本的活动，而非制图用例（UseCase）特征（系统）用例与业务用例区别业务用例不研究“软件系统”需求，它更关心一个“业务组织”对外提供哪些服务。两者的领域域不同业务用例模型仅关注于企业部门的业务，而系统用例模型则关注于系统本身实现后的互动。UML图素含有不同用例和功能区别(1)用例和功能区别（2）功能功能是脱离使用者愿望存在的功能是孤立的－－只要按下开关就亮灯如果非用从功能的角度解释用例，那么用例可以解释为一系列完成一个特定目标的“功能”的组合，针对不同的应用场景，这些“功能”体现不同的组合方式用例和功能区别--功能分解主要缺陷（3）系统分析师必须高度仰赖以前开发过相似系统的经验，才能够得知该将系统细分成哪几个子系统、功能及子功能问题域无法直接对应成功能，因此需要靠系统分析师以人工的方式来将问题领域对应成功能与子功能。分解没有定式，自由度较高，不同的分析师有不同的分析决定，所有结果难以理解，也难达成共识，同时日后也不易于重用与维护。整个系统有数个子系统所组成，每个子系统又由数个功能组成，每个功能再由数个子功能组成…，一层一层往下功能分解，再一层一层往上组成整个系统。由于功能变动性太大，也因此造成系统的结构不稳定HowtoWorkWithUseCasesinIterativeMethods?UsecasesarecentraltotheUPandmanyotheriterativemethods.TheUPencouragesuse-casedrivendevelopmentFunctionalrequirementsareprimarilyrecordedinusecasesUsecasesareanimportantpartofiterativeplanning.Use-caserealizationsdrivethedesignFunctionalorsystemtestingcorrespondstothescenariosofusecases.UI"wizards"orshortcutsmaybecreatedforthemostcommonscenariosofimportantusecasestoeasecommontasks.Usecasesofteninfluencetheorganizationofusermanuals.统一过程（UP）和用例（UseCase）Samplerequirementseffortacrosstheearlyiterations%WhenShouldVariousUPArtifactbeCreated?UseCase对开发的意义实现测试需求分析和设计UseCases把所有这些过程绑到一起OMT（ObjectModelingTechnique）方法的面向对象开发过程---Rumbaugh捕获系统的需求便于和最终用户、领域专家交流测试系统需求与用例关系用例就是需求用例是真正的需求为功能性需求编写用例，FURPS+强调F需求不是用例需求与用例关系什么是用例图(usecasediagram)在UML中，一个用例模型由若干个用例图(usecasediagram)描述。用例图是显示一组用例、参与者以及它们之间关系的图。用例图的组成一组用例（UseCases）一组参与者（Actors）一组关系(Relationships)Partialusecasecontextdiagram用例图的应用用例图是从用户的角度来描述对软件产品的需求，分析产品的功能和行为，因此，对整个软件开发过程而言，用例图是至关重要的。用例图定义和描述了系统的外部可见行为，是分析、设计直至组装测试的重要依据。让用户参与前期的系统分析与设计。分析师必学元素识别参与者识别用例绘制用例图编写用例描述识别参与者参与者在系统之外，通过系统边界与系统进行直接有意义交互的任何事物系统外,而不是系统内的责任的边界，不是物理的边界直接与系统交互执行者与重要程度无关场景一：机票购买者是系统参与者场景二：人工座席是系统参与者，机票购买者是呼叫中心参与者场景三：呼叫中心（非人）是参与者，机票购买者是呼叫中心参与者场景四：机票购买者是参与者，人工座席是业务工人直接与系统交互有意义的交互任何事物，“非人”执行者时间代理人时间代理人启动时间酒店订房系统确定参与者参与者一定是直接并主动向系统发出动作的参与者一定是能从系统获得反馈的参与者与用户用户是系统的使用者用户是系统的操作员用户是参与者的实例或代表并非所有的参与者都是用户如何区分参与者还是业务工人？最直接的方法是根据系统边界，系统内还是系统外如果边界不确定，可以通过下面三个问题他是主动向系统发出动作吗？他有完整的业务目标吗？系统是为他服务的吗？如果以三个答案是否定的

，就一定是业务工人表1-11参与者的特征表参与者位于系统外部，他不属于系统的某一部分，所以我们不需要去构建参与者。只有会使用系统、会跟系统互动、会跟系统交换信息的才会是系统的参与者。参与者会启动、参与用例，所以找到参与者，就可以引导我们找到用例。我们虽然不需要构建参与者，但是却需要考虑接口。系统需要提供接口让参与者使用，或者系统需要用到参与者提供的接口---摘自：《系统分析师UML用例实践》TheNextGenPOSSystem

anextgenerationfault-tolerantpoint-of-sale(POS)application,NextGenPOS,withtheflexibilitytosupportvaryingcustomerbusinessrules,multipleterminalanduserinterfacemechanisms,andintegrationwithmultiplethird-partysupportingsystems.表1-12寻找参与者的问题表谁会来使用这个系统？谁会来安装这个系统？谁会来启动这个系统？谁会来维护这个系统？谁会来关闭这个系统？那些系统会来使用这个系统？谁会从这个系统获取信息？谁会给这个系统提供信息？在预选设定的时间到达时，有什么事情会自动发生吗？哪些系统会与这个系统联网？哪些数据库会与这个系统联网？是否有硬件设备会与这个系统联网？公司内部会有哪些人员会来使用这个系统？公司外部有哪些人会来使用这个系统？当特定的时间或事件发生时，这个系统需要自动通知什么人，或者是自动通知其他系统吗？---摘自：《系统分析师UML用例实践》---Cashier/StoreManagerSystemAdministrator---SalesActivitySystem……---AccountingSystem/PaymentAuthorizationService表1-13参与者种类表种类细项参与者人公司外部的人公司内部的人系统其他系统（内部）其他系统（外部）数据库事件硬件设备---摘自：《系统分析师UML用例实践》CustomerCashier/StoreManager/SystemAdministratorSalesActivity/Accounting/HRSystemPaymentAuth/TaxCalculator

SystemUnknownTimmingUnknown思考题：识别参与者SP手机短信天气预报系统：用户如果预定了SP的手机短信天气预报业务，系统每天会定时给他发天气预报消息；如果当天气温高于35度，还要提醒用户注意防暑。在这个叙述里，SP天气预报系统的Actor包括哪些？49如何识别用例（1）选择系统边界（2）确定主要参与者（3）确定每个主要参与者的目标（4）定义满足用户目标的用例，根据其目标对用例命名。50（1）选择系统边界 例如：POS系统，该系统之外的事物都在边界之外。 如果对系统边界的定义不清晰，可以通过对系统外部事物的定义加以明确。一旦定义了外部参与者，系统边界将变得清晰51(2)(3)寻找主要参与者和目标集体讨论主要参与者特定参与者希望系统提供什么功能系统是否存储和检索信息，如果是，由哪个参与者触发当系统改变状态时，是否通知参与者是否存在影响系统的外部事件，哪个参与者通知系统这些事件52如何组织参与者和目标有两种方法1.当你发现结果，将其绘制为用例图，以目标作为用例名称2.首先写出“参与者-目标”列表，复审并精化，然后绘制用例图。“参与者-目标”列表，可以作为愿景制品的一部分。53为什么提问总是围绕着参与者的目标而不是用例参与者有其目标，并使用系统以达成这些目标用例建模的观点是寻找这些参与者及其目标，创建产生有价值结果的解决方案。建模时首先询问“谁来使用系统，他们的目标是什么？”提问时问“你的目标是什么”比问“你在做什么？”更适宜。前者的提问结果具有可量化的价值，后者只是概略性的面向任务的问题。54主要参与者是收银员还是顾客图6-2不同系统边界下的主要参与者和目标55有其它方法来寻找参与者和目标吗？-事件分析通过确定外部事件，可以有助于寻找参与者和目标确定外部事件，源于何处，为什么？56（4）定义用例一般来说，为每个用户目标分别定义一个用例。用例名称应该和用户目标类似。用例名称应以“动词+名词”的形式命名，如：处理销售，增加用户等对于每个目标一个用例来说，常见例外的是，将分散的CRUD目标合成一个用例，并习惯称为管理<X>.用例的要点表简单记录用例的结果、重要流程和议题，日后撰写用例描述时，这些可以作为参考资料用例要点说明<系统>结果重要步骤议题表1-16用例要点表---摘自：《系统分析师UML用例实践》识别用例的注意事项注意事项：可观测→用例止于系统边界结果值→用例是目标导向的系统执行→结果值由系统生成由参与者观测→业务语言、用户观点执行者视角－动词＋名词识别用例填写取款单不是取款人的目的，不是用例后台监控和输入密码对参与者是没有意义的，不是用例ATM是没有吐钞的愿望的，因此不能驱动用例“喝”不能构成一个完整的事件，因此不能用来命名用例可观测→用例止于系统边界结果值→用例是目标导向的系统的存在是因为：参与者有一些需要使用它来满足的目标不是某某做什么，而是某某【用系统】做什么结果值→有意义的目标填写取款单不是取款人的目的，不是用例系统执行→结果值由系统生成系统需要处理的，由系统生成业务语言而非技术语言用户观点系统观点用户观点而非系统观点用户观点而非系统观点用例

•呼叫某人

•接听电话

•发送短消息

•记住电话号码

•......

用户观点功能•传输/接收•电源/基站•输入输出（显示，键盘）•电话簿管理•......系统观点用例的问题表--便于帮助寻找用例参与者想要从这个系统获得什么用的功能？这个系统存储信息？哪些参与者将建立、读取、更新或删除这些信息？当系统内部状态有变化时，这个系统需要通知哪些参与者吗？是否有什么外部事件是这个系统需要知道的？当这些外部事件发生时，那些参与者会通知这个系统？这个系统需要定期执行什么操作吗？当发生了某些重要的外部事件时，这个系统需要自动执行什么操作吗？这个用例的名称够明确吗？是否能够从这个用例的名称，直接判断他的结果？这个用例会有多样的结果吗？还是这些结果，其实是在不同的时间点产生的？表1-15用例问题表---摘自：《系统分析师UML用例实践》……68发现有用用例的测试老板测试老板提问”你整天都做了些什么？“，回答是什么？“登录系统”？用例要产生可量化有价值的结果EBP（ElementaryBusinessProcess，基本业务过程）测试一个人于某个时刻在一个地点所执行的任务，用以响应业务事件。该任务能增加可量化的业务价值，并且以持久姿态留下数据。如：批准信用额度，确定订购价格等与老板测试类以，强调”可量化有价值的结果规模测试用例通常包含多个步骤详述形式的用例通常需要3-10页文本。69示范：应用上述测试就供应商合同进行协商比EBP更广泛，用时更长。更适合作为业务用例，而非系统用例处理退货能够通过老板测试。看上去与EBP类似。规模合适。登录如果你一整天都在登录，老板不会满意在游戏板上移动棋子单一步骤，不能通过规模测试70测试的合理违例子功能级别的用例，如：信用卡支付等子任务，在多个基本用例中出现。虽然通不过EBP测试和规模测试，也需要考虑作为单独用例认证用户这一用例可能无法通过老板测试，但其步骤及为复杂，需要引起重视进行细致的分析，也可作为单独用例要点：用例的粒度(1)用例要有路径，路径要有步骤；而这一切都是可观测的最常犯错误：粒度过细，陷入功能分解，过细的粒度一般都会导致技术语言的描述，而不再是业务语言把执行者动作当作用例把系统活动当作用例要点：用例粒度(2)把步骤当用例把系统活动当用例要点：用例的粒度(3)“四轮马车”C(Create)

R(Read)

U(Update)

D(Delete)所有业务最终都会成为CRUD？CRUD能为Actor提供价值？CRUD掩盖业务，锐变成关系数据库的建模：“系统就是数据的增删改查”关心数据的存储和维护，反而忽略了用户的目的要点：用例的粒度(4)如果确实是CRUD？如果CRUD不涉及复杂的交互，一个用例“管理××”即可不管是C、R、U、D，都是为了完成“管理”目标甚至很多种的基本数据管理都可以用一个用例表示要点：用例的粒度(5)阶段粒度例子业务建模（描述功能性需求）用例名称能够说明一个完整业务流程取钱、报装电话、借书等概念建模用例描述一项完整业务的一个步骤提供申请资料、受理业务等系统建模用例能够描述操作者与计算机的一次完整交互为宜填写申请单、审核任务单、验证密码等粒度尚无标准规则建议在不同阶段，使用不同粒度76应用UML：用例图用例图用于描述用例名称和参与者及其之间的关系。准则：绘制简单的用例图，并与“参与者-目标”列表关联。77图6-3部分用例语境图78图6-4表示法建议思考题：绘制用例图SP手机短信天气预报系统：用户如果预定了SP的手机短信天气预报业务，系统每天会定时给他发天气预报消息；如果当天气温高于35度，还要提醒用户注意防暑。系统管理员、业务人员、用户、时间代理、运营商系统、媒体、数据分析系统用例描述除了用例图之外，分析师还得使用文字描述用例的流程细节，这样的文字说明，又称为“用例描述”(usecasedescription)。UML是一套标准的图形语言，其中只提出了十四款图，没有将用例描述考虑在内，也当然没有任何标准的用例描述格式了。谁来写用例描述最完美：业务人员接受训练，写出优美的用例文档最现实：业务人员提供素材，开发人员写用例文档最糟糕：业务人员不管，完全由开发人员杜撰82图6-7编写用例的过程和语境设置“编写用例”在时间和地点方面的建议用例描述的四种形式命名(Giveitaname)仅仅给出用例和主要参与者的名称摘要简洁的一段式概要，通常用于主成功场景。例：P45处理销售非正式用几个段落覆盖不同的场景。例如：P47处理退货详述详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。何时使用，在编写了摘要形式的用例之后，在各个迭代阶段之前精化需求时。例：P50处理销售83用例叙述最简版再怎么复杂的用例叙述，抽丝剥茧后，至少都会留下用例名称，起点和终点表2-18用例叙述简版用例：<名称>事件流程：<起点>…<终点>---摘自：《系统分析师UML用例实践》85以本质(essential)风格编写用例；

摒除用户界面并且关注参与者的意图。本质风格……1.管理员标识自己的身份2.系统对此身份进行认证3……具体风格……1.管理员在对话框中输入ID和口令（见图3）2.系统对管理员进行认证3.系统显示“编辑用户”窗口（见图4）4…….对根源目标的发现过程能够拓展视野，以促成新的、改进的解决方案。用例描述组成（教材P50）用例的不同部分注解用例名称UseCaseName动词+名词范围Scope要设计的系统级别Level“用户目标”或者是“子功能”主要参与者PrimaryActor与系统交互完成服务涉众及观众点StakeholdersandInterests关注该用例的人及其需求前置条件Preconditions值得告诉读者，开始前必须为真的条件成功保证SuccessGuarantee值得告诉读者，成功完成必须满足的条件主成功场景MainSuccessScenario典型的、无条件的、理想方式的成果场景扩展Extensions成功或失败的替代场景特殊需求SpecialRequirements相关的非功能需求技术和数据变元表TechnologyandDataVariationsList不同的I/O方法和数据格式发生频率FrequencyofOccurrence影响对实现的调查、测试和时间安排杂项Miscellaneous例如未决问题AlistairCockburn书写用例描述总原则如果涉众不能理解和验证，它就不是需求（如果删除他，会不会有涉纵的利益受到伤害）总原则什么是涉众涉众是与要建设的业务系统相关的一切人和事。业主业务提出者业务管理者业务执行者第三方承建方相关的法律法规用户

涉众利益涉纵利益需要整理？用例描述：前置条件指在用例场景开始前，必须永远为真的条件；

1）形式：系统在用例开始前能检测到；

2）内容：不满足会伤害涉众的利益前置条件开始用例前所必需的系统及其环境的状用例描述：前置条件库存大于下单数----错误前置条件必须是系统在用例开始前能检测到的用例描述：后置条件用例成功结束后，必须为真的事物，包括主成功场景及其替代路径

1）系统能检测到；

2）应为“可观测”的：只包含可检测的条件，合并对系统最终影响相同的条件后置条件用例成功结束后系统应该具备的状态用例描述：后置条件前置条件和成功保证（后置条件）描述原则不要被其所困扰，除非对某些不明显却值得重视的事物进行陈述、以帮助增强理解。用例描述：事件流用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how），怎么做是设计模型的事用例描述：主成功场景也称“基本事件流”或“理想路径”，是对用例中常规、预期路径的描述（有时被称为Happyday场景），这是大多数用户在大部分时间中所采取的路径。把主要流程单独分离，凸现用例的核心价值所有条件和分支延迟到扩展部分进行说明主成功场景核心的核心：客户最想看到、最关心的路径用例描述：扩展事件流（替代流程）系统还需要进行意外处理扩展是重要的，通常占据了文本的大部分篇幅扩展可针对一步，也可针对多步扩展事件流替代流程的问题表在这个流程步骤中，是否还有其他替代的操作？在这个流程步骤中，是否会发生什么样的错误？在整个用例执行过程中，是否随时可能发生其他未记录在叙述中的的操作？参与者输入数据时，是否会提供不完整的数据，需要重新补上的数据？是否会出现错误的数据，需要特别处理的数据？参与者是否会在用例执行期间，临时中断流程？参与者是否会想要挑选其他执行方法？参与者在流程执行过程中，会不会有需要协助的地方？系统发生宕机时，是否需要特殊的处置？系统响应时间过程时，是否需要特殊的响应方法？表2-19替代流程的问题表针对主要流程中的每一个步骤，都可以问问这些问题，对编写替代流程很有帮助---摘自：《系统分析师UML用例实践》替代流程分类表编写替代流程的时候，可以直接按照这几个类的替代流程来编写替代流程替代１：不完整的数据替代２：错误的数据替代３：取消或中端操作替代４：其他执行方法替代５：需要协助替代６：系统宕机或无响应表2-20替代流程分类表---摘自：《系统分析师UML用例实践》用例事件流（交互）四步曲事件流描述要点只书写“可理解、可验证、可观测”的（说人话）每个步骤一个句子使用主动语句，理清责任句子必须以参与者或系统作为主语不要涉及界面细节分支和循环AlistairCockburn要点1：只写“可观测”的对特定参与者具有价值的可观察的结果黑盒原则：规定系统做什么，而不是如何去做正确：系统记录销售错误：系统通过ADO建立数据库连接，传送SQLInsert语句，将销售记录插入到商品表中…准则：从系统外部的角度来编写用例要点2：主动语句错误：欧文从贝克汉姆处得到传球，守门员…正确：贝克汉姆传球给欧文，欧文射门，守门员扑救…错误：系统从收银员处获得商品ID正确：收银员输入商品ID错误：出售的商品被系统记录正确：系统记录出售的商品要点3：以参与者或系统作主语参与者……系统……1、顾客携带所购商品或服务到收银台通过POS机付款2、收银员开启一次新的销售交易3、收银员输入商品条码4、系统逐条记录出售的商品，….…..要点4：不涉及界面细节错误：收银员从下拉框中选择商品ID错误：收银员在对话框中商品ID错误：收银员在相应文本框中输入查询条件错误：收银员点击“确定”按钮要点5：分支和循环分支：可以放到扩展路径参与者的选择另一条成功线路系统进行验证……循环：直接描述…3、收银员输入商品条码4、系统逐条记录出售的商品，….

客户重复步骤3、4，直到客户指明他/她完成了选购…特殊需求SpecialRequirements非功能性需求、质量属性或约束性能可靠性可用性IO设备…技术和数据变元表TechnologyandDataVariationsList不同的I/O方法数据格式Example:MonopolyGame分析瘫痪警告警告4：别直到你知道用户将要做什么为此才开始尝试写用例(Don'ttrytowriteusecaseuntilyouknowwhattheuserswillactuallybedoing)警告5：别花费数周的时间，只是为了构建出精致完善的用例模型Don'tspendweeksbuildingelaborate,elegantusecasemodelsthatyoucan'tdesignfrom)警告6：别浪费时间去担心、到底采用包含关系、扩展关系等Don‘tspinyourwheelsworryingaboutwhethertouseincludes,extends,and/oruses警告7：别把时间浪费在冗长且复杂的用例模板上Don'twastetimewit