第四讲-初始化阶段Chapter-4-7课件

第四讲.初始化阶段

Chapter4-72023/7/232内容案例简介初始化阶段需求概念基于用例的功能性需求获取非功能性需求1.案例2023/7/234NEXTGENPOS系统NextGen销售终端(point-of-sale,POS)系统POS系统是用来记录销售信息和处理支付的计算机系统，它一般用于零售店2023/7/235体系结构InterfaceSalePaymentLogPersistenceFacadeapplicationlogicanddomainobjectlayertechnicalserviceslayerminorfocusexplorehowtoconnecttootherlayersprimaryfocusofcasestudyexplorehowtodesignobjectssecondaryfocusexplorehowtodesignobjects2023/7/236讲授方法Iteration1Iteration2Iteration3介绍与第一次迭代相关的分析和设计技术介绍其他的分析和设计技术Likewise.2.初始化阶段2023/7/2382.1在我们开始一个项目前…在项目启动前，我们需要回答下列问题:该项目的vision（设想，前景）

和businesscase（业务案例）?可行吗?购买and/or构造?成本的大致估计;是$10K-100K或者几百万?我们需要继续还是停止?2023/7/2392.2目的该阶段的目的不是定义所有的需求，而是做适当的调研（todojustenoughinvestigation）何谓“适当的”：对新系统的整体目的和可行性形成一个合理的意见确定是否值得深入研究2023/7/2310初始化阶段的主要目标为:建立项目的软件范围和边界条件，包括一个操作“前景”，“接受准则”和产品中包含什么，不包含什么确定核心的用例，这是系统运行的主要场景，它将决定系统设计的方案针对主要的场景，确定或者演示至少一个备选的系统结构对整个项目估计总成本和计划(更详细的估计将安排在细化阶段中)估计可能的风险(不可预计性的来源）为项目准备支持环境2023/7/23112.3制品前景和业务用例（VisionandBusinessCase）用例模型（Use-CaseModel）补充规格说明（SupplementarySpecification）词汇表（Glossary）风险列表和风险管理计划（RiskList&RiskManagementPlan）原型和概念验证（PrototypesandProof-of-concepts）迭代计划（IterationPlan）阶段计划和软件开发计划（PhasePlan&SoftwareDevelopmentPlan）开发案例（DevelopmentCase）3.理解需求

（Chapter5）2023/7/23133.1概述需求每一个人都有需求在不同的时间我们有不同的需求需求驱动了软件过程正式的定义“需求就是系统（更广义的说法是项目）必须提供的能力和必须遵从的条件".2023/7/23143.2涉及到谁?客户（Client）

–为开发付钱的人，将来是产品的拥有者顾客（Customer）–买商品化软件的人，或者将来有发言权确定是否产品可以接受（开发产品）。可能与客户是同样的人涉众–任何对系统的需求有直接或者间接影响的人

参考:MasteringtheRequirementsProcess,RobertsonandRobertson2023/7/23153.3需求管理需求管理是一种系统化的方法：

获取，记载、组织和跟踪系统的需求为客户和项目团队之间针对不断变化的需求建立和维护协议2023/7/23163.4功能需求功能需求系统必须提供的服务的描述，系统应该如何响应特定的输入，系统在特定的情景下的行为2023/7/2317例子用户能够搜索所有的数据集合或者从中选择一部分进行搜索系统需要为用户提供合适的浏览器从文档库中读取文档每一个订单需要分配一个唯一标识符，用户可以永久保存起来.2023/7/23183.5非功能需求对系统提供服务或者功能的约束，如时间约束，开发过程的约束，标准等等；许多需求是非功能性的，只能够描述系统的属性或者系统环境的属性2023/7/2319例子产品需求“ItshallbepossibleforallnecessarycommunicationbetweentheAPSEandtheusertobeexpressedinthestandardAdacharacterset.”组织需求“ThesystemdevelopmentprocessanddeliverabledocumentsshallconformtotheprocessanddeliverablesdefinedinXYZCo-SP-STAN-95”外部需求“Thesystemshallnotdiscloseanypersonalinformationaboutcustomersapartfromtheirnameandreferencenumbertotheoperatorsofthesystem”2023/7/23203.6需求类型另一种分类的方法是采用FURPS+模型[GRA92],缩写FURPS描述了需求的主要类别：

FunctionalityUsabilityReliabilityPerformanceSupportability2023/7/2321功能性

特性集（featuresets)功能（capabilities）安全性（security）可用性人性化因素(RelatedConcepts:User-CenteredDesign)美学特性(aesthetics)用户接口的一致性（consistencyintheuserinterface）在线和上下文相关的帮助（onlineandcontext-sensitivehelp）智能助手（wizardsandagents）用户文档（userdocumentation）训练材料（trainingmaterials）2023/7/2322可靠性失效频率和严重性（frequencyandseverityoffailure）可恢复性（recoverability）可预测性（predictability）精度（accuracy）平均失效时间（meantimebetweenfailure(MTBF)）性能速度（speed）效率（efficiency）可用性（availability）精度（accuracy）吞吐量（throughput）响应时间（responsetime）恢复时间（recoverytime）资源利用率（resourceusage）2023/7/2323可支持性可测试性（testability）可扩展性（extensibility）适应性（adaptability）可维护性（maintainability）匹配性（compatibility）可配置性（configurability）可服务性（serviceability）可安装性（installability）本地化，国际化localizability(internationalization)2023/7/2324FURPS+中的“+”

号意味着还有一些其他的约束，如:设计约束（designconstraints）实现需求implementationrequirements接口需求interfacerequirements物理需求physicalrequirements包装Packaging授权等等Legal-licensingandsoforth4.基于用例的需求获取

Chapter62023/7/23264.1目标如何识别和编写用例使用摘要、非正式和详述等用例形式的基本式样将测试应用于确定适当的用例上将用例分析与迭代开发联系起来2023/7/23274.2目标和故事人类的行动主要是由目标驱动的.

对于一个图书馆信息系统，某些目标为:每一本书的请求都必须最终实现新系统必须高度可靠通过做某些事情或者避免（不做）某些事情来实现系统构造时，我们必须记住我们的目标

2023/7/2328获取目标并不容易真正的需要是什么不同的细节层次无法控制的复杂性存在许多方法越简单的往往应用越广通过讲述如何利用系统满足不同涉众的目标的故事来记录功能需求-casesofuse2023/7/23294.3什么是用例?“一组用例的实例，其中每个实例都是系统执行的一系列活动，这些活动产生了对每个参与者而言可观察的返回值”（RUP）描述了从参与者（Actor）角度看系统（黑盒子）做了什么

WHAT用例模型本身不是面向对象建模技术2023/7/2330用例的好处从用户的角度获取操作性需求对系统的功能进行清晰而一致的描述系统测试的基础提供了从功能需求跟踪到系统中真正的类和操作的能力2023/7/2331理解UseCases参与者Actor:是某些具有行为的事物，可以是人（由角色标识），计算机系统或组织，例如收银员场景Scenario:参与者和系统之间的一系列特定的活动和交互，也称为用例实例。场景是使用系统的一个特定情节或用例的一条执行路径。用例UseCase:一组相关的成功和失败场景集合，用来描述参与者如何使用系统实现其目标2023/7/2332处理退货-非正式格式主成功场景Acustomerarrivesatacheckoutwithitemstoreturn.ThecashierusesthePOSsystemtorecordeachreturneditem…其它场景:Iftheypaidbycredit,andthereimbursementtransactiontotheircreditaccountisrejected,informthecustomerandpaythemwithcashIftheitemidentifierisnotfoundinthesystem,notifytheCashierandsuggestmanualentryoftheidentifiercodeIfthesystemdetectsfailuretocommunicatewithexternalaccountingsystem…2023/7/2333usecase的例子

(fromFowlerandScott,UMLDistilled)

UseCase:购买产品CustomerbrowsersthroughcatalogandselectsitemstobuyCustomergoestocheckoutCustomerfillsinshippinginformation(address;next-dayor3-daydelivery)Systempresentsfullpricinginformation,includingshippingCustomerfillsincreditcardinformationSystemauthorizespurchaseSystemconfirmssaleimmediatelySystemsendsconfirmingemailtocustomerAlternative:授权失败6a. Atstep6,systemfailstoauthorizecreditpurchase Allowcustomertore-entercreditcardinformationandre-tryAlternative:

会员3a.Systemdisplayscurrentshippinginformation,pricinginformation, andlastfourdigitsofcreditcardinformation3b.Customermayacceptoroverridethesedefaults Returntoprimaryscenarioatstep62023/7/2334思考…用例是相关的成功或者失败的场景的集合“在ATM机中输入用户ID"不能建模为单独的UseCase，因为无人使用系统仅仅为了输入ID2023/7/2335用例是什么，不是什么用例是需求，而且主要是功能需求，反映了系统将做什么用例是需求，而不是功能或者特征列表用例是文档，而不是图，用例建模主要是写文字，而不是画图2023/7/23364.4编写用例不同形式化程度摘要非正式详述详述格式的例子，见pp50-54（中译本），pp68-72（英文版）2023/7/2337章节内容绪言范围：系统用例，业务用例级别：用户目标级别，子功能级别（可被许多用例重复使用的）主要角色涉众前置条件和后置条件主成功场景和步骤（或基本流程）扩展（或替代流程）特殊需求：非功能性需求，质量属性或约束技术和数据变元表：比如用户对如何实现系统的要求2023/7/2338指南以无界面约束的本质风格编写用例发现目标的目标，可以拓宽我们的视野WhatversusHowWhat:标识我自己并获得授权How通过对话框输入用户ID和口令生物识别iSmartCard指南：“以本质风格编写用例，摒弃用户界面并关注参与者的意图”“具体风格”需要在早期需求工作中避免2023/7/2339另外一个例子RecycleItems:Theuserusesthismachinetoautomaticallyhaveallthereturnitems(bottles,cans,andcrates)counted,andreceivesareceipt.Thereceiptistobecashedatacashregister(machine).AddNewBottleType:Newkindsofbottlescanbeaddedtothemachinebystartingitin‘learningmode’andinserting5samplesjustlikewhenreturningitems.Inthisway,themachinecanmeasurethebottlesandlearntoidentifythem.Themanagerspecifiestherefundvalueforthenewbottletype.2023/7/2340编写简洁的用例编写黑盒用例软件元素具有责任（responsibility)采用参与者和参与者目标的观点“对特定参与者而言具有价值的可观察的结果”4.5如何发现用例2023/7/23424.5.1主要过程选择系统边界寻找主要参与者为每个参与者确定他们的目标定义用例2023/7/2343系统边界描述了系统被包含在内的“信封”在许多情形下，系统边界是显而易见的。例如对一个单个用户的运行在MicrosoftWindows上的个人联系信息管理本，它的边界是很容易定的，因为只有一个用户，一个平台。.2023/7/23444.5.2参与者与目标选择系统边界寻找主要参与者为每个参与者确定他们的目标定义用例2023/7/2345参与者是与系统交换数据的实体。参与者可以使用户，外部的硬件或者另外一个系统2023/7/2346某些技巧我们可以问一些代表性的问题来找到参与者和目标参与者的类型主要的参与者PrimaryActors支持参与者SupportingActors幕后参与者Offstageactors参与者-活动列表这似乎一个交互和叠代的过程Thefocusofthisstage2023/7/2347主要的参与者和用户目标依赖于系统的边界2023/7/23484.5.3定义用例选择系统边界寻找主要参与者为每个参与者确定他们的目标定义用例2023/7/2349一般而言，为每一个用户目标定义用例用例名称以动词开头将CRUD(create,retrieve,update,delete)这些分散的目标合并成一个CRUD用例:Manage<X>定义用例需要交流和参与领域专家的参与非常重要迭代开发2023/7/2350发现有效用例用例的粒度问题大用例我们的企业需要拓宽销售渠道整个系统就只有一个用例!!!小的用例输入口令系统中可能有成百上千个用例!!!我们必须权衡2023/7/2351经验方法老板测试EBP测试规模测试2023/7/2352老板测试老板是付钱的人老板必须看到可量化的价值2023/7/2353EBP测试EBP用例对计算机应用的需求分析，关注于基本业务过程（

elementarybusinessprocesses，EBPs）层面上的用例依据持续时间，步骤，涉及到的人来定增加可见的或者可度量的业务价值没有人仅仅想输入一个口令客户愿意为此付费吗?2023/7/2354规模测试用例通常应该包括多个步骤在详细描述的情形下，应该需要3-10页文本2023/7/2355分析供应者合同进行协商处理退货登陆在游戏板上移动棋子2023/7/2356任何东西都有例外EBP原则也不是圣经有些时候我们会把多个用例中的公共部分单独成为用例目标与用例的关系目标可以分解成不同层次用户目标EBP层次的用例=用户目标EBP层次的用例

用户目标UseCasereflectscurrentsolutionsUnderstandingGoalopensupthevisionfornewandimprovedsolutions企业层次增加利润子功能目标4.6用例图2023/7/2358用例的组织和用例图

在UML里,用例图是表达用例和活动者及其之间关系的载体用例图是模型图，用例图可包含用例，活动者以及它们之间的关系，这些关系可以是：关联关系依赖关系实现关系用例图的用途是为软件系统、软件子系统、类的动态行为建模。它从两个方面对其建模对象的内容进行描述，即：描述它们的边界对它们进行需求分析2023/7/2359下图是一个描绘系统边界的用例图的例子，它通过区分系统用例和活动者，明确区分了系统内部的事物和系统外部的事物，通过描绘它们之间的关联关系，系统的边界得到了清晰的表达

2023/7/2360用例图和用例关系在编写用例工作中是次要的。用例是文本文档。编写用例意味着编写文本。绘制简单的用例图，并与参与者-目标列表关联。用例不是面向对象的2023/7/2361画图建议4.7在迭代方法中如何使用用例2023/7/2363用例驱动开发功能需求首先记录在用例（用例模型）中；用例是迭代计划的重要部分，是预算的关键输入用例实现驱动设计用例影响了用户手册和测试2023/7/2364需求规格说明的工作任务跨越了各个迭代，见书表6-1，

中文，pp72，英文，pp962023/7/2365初始阶段编写用例确定目标和涉众，推测项目范围参与者-目标-用例

表绝大部分需要关注的，复杂的，具有风险的用例采用简单的形式编写其中的10%-20%的用例代表了复杂的核心功能，需要构建核心架构或者在某些方面具有风险，采用详细的格式进行描述确定是否要继续到细化阶段2023/7/2366细化阶段编写用例多次时间定量的迭代绝大部分的需求被识别和描述清楚在每一次迭代中，会有一次需求会议早期的会议关注于最重要用例的子集用户目标和用例列表被精化在细化阶段结束时，80-90%的用例被详细描述2023/7/2367构造阶段编写用例由时间定量的迭代关注于完成系统在这个阶段可能涉及编写一些次要的用例，也可能举办需求讨论会2023/7/2368JanuaryFebruaryUseCase:CaptureaSale...MainSuccessScenario:1....2....3....Extensions:UseCase:HandleReturns...MainSuccessScenario:1....2....3....Extensions:WhenOnceduringinception.Short;donottrytodefineorpolishallrequirements.Severaltimesduringelaborationiterations.WhereAtarequirementsworkshop.WhoMany,including,endusersanddevelopers,willplaytheroleofrequirementsspecifier,helpingtowriteusecases.Ledbysystemanalyst,whoisresponsibleforrequirementsdefinition.How:ToolsSoftware:Forusecasetext,useaweb-enabledrequirementstoolthatintegrateswithapopularwordprocessor.Forusecasediagrams,aUMLCASEtool.Hyperlinktheusecases;presentthemontheprojectwebsite.Hardware:Usetwoprojectorsattachedtodualvideocardsandsetthedisplaywidthdouble,toimprovethespaciousnessofthedrawingareaordisplay2adjacenctwordprocessorwindows.DeveloperCustomerSystemAnalystEndUserTwoadjacentprojections.SoftwareArchitect5.识别其他需求2023/7/2370UP中的制品2023/7/2371需求制品集合2023/7/2372初始化阶段的制品用例模型词汇表补充性规格说明前景业务规则2023/7/2373词汇表领域术语设计/实现中的术语对所有人并不相同从用例中观察：是不是有任何术语需要重用或者容易误解2023/7/2374补充说明文档包含那些用例中没有的需求:非功能需求(URPS+)领域(或者业务)规则法律问题

–

责任，知识产权，等等约束封装,等等.2023/7/2375远景业务机会竞争目标关键的涉众产品概览远景中表达的需求2023/7/2376初始化中的其他制品风险列表:Whatissuescouldbeaproblemforprojectachievinggoals?原型:ProofoftechnicalfeasibilityUIprototypestoclarifyfunctionalityinvision高层的系统备选架构2023/7/2377编写前景的第一个草稿确定用户目标和支持性用例编写某些用例并开始编写补充性规格说明依据上述信息，修改前景2023/7/2378构造依据反馈修改前景其他需求将更清楚，并可以记录在补充规格说明中主要的术语将被发现和精化主要的需求——功能或者其他方面的需求稳定下来