Use CasesSystem descriptionMany notationsMany purposesWriting Effective Use CasesPowerPoint PresentationUse case diagramSCD for Claims ProcessingSlide 9Use casesUse cases are textMany ways of writing use casesActor-Goal ListUse case briefsBrief (casual) version of Submit Fax ClaimDetailed (fully dressed) version of Submit Fax ClaimMain Success Scenario:Use Cases and RequirementsRequirementsTraceabilityManage requirementsScenarios and Use CasesGoals and Use CasesWhen use cases don’t workSummaryReading1Use CasesHigh-level system descriptionCS427 6-2System descriptionTypical description has two partsdataoperations on that dataThree possible descriptionsrequirementsspecificationdesignCS427 6-3Many notations UMLUse casesClass diagramState diagramHamlet and MaybeeFinite state machine, Data flow diagramPrologPseudocodeCS427 6-4Many purposesCommunicate toUserDevelopersBossComplete - lots of detailEasy to read - less detailCS427 6-5Writing Effective Use CasesAlistair CockburnKnow the inside cover, front and backwww.usecases.orgpapersdiscussion boardsProviderFax to claimElectronic claimAutomatic Claim ProcessingKnowledgeWorkerPaper claimClaims Processing System<<include>>MainframePost officeAdjudicationAdjudicatorCS427 6-7Use case diagramShows actors and use casesShows system scope and boundariesNot a description of use casesLike a context diagramCS427 6-8SCD for Claims ProcessingClaims ProcessingSystemElectronic claimPostal SystemMainframeClaim adjudicatorFaxData repairPostal SystemData entryCS427 6-9Use CasesText - a form of writing.Describes the system’s behavior as it responds to a request from an actor.Many kinds of use casesBrief / detailedRequirement / specification / designCS427 6-10Use casesDescribe the sequence of events that happen when the system responds to a requestCan describe alternativesCan describe errorsCS427 6-11Use cases are textUse cases should be easy to readkeep them shorttell a storywrite full sentences with active verb phrasesmake the actors visible in each sentenceCS427 6-12Many ways of writing use casesUser storiesActor-goal listUse case briefsCasual use cases“Fully dressed” use casesCS427 6-13Actor-Goal ListActor Task-level goalPriorityProvider Submit paper claim 1Provider Submit fax claim 2Provider Submit electronic claim 3Adjud. Adjudicate problem 2CS427 6-14Use case briefsActorProviderProviderAdjucatorGoalSubmit paper claim Submit fax claimAdjudicate failed claimBriefSubmit claim on paper, which is converted into electronic form, and either paid or sent for adjudicationSubmit claim by fax, which is processed by OCR and either paid or sent for adjudication. Decide whether a questionable claim should be paid by the mainframe payment system or rejectedCS427 6-15Brief (casual) version of Submit Fax ClaimThe Provider submits a claim by fax. The claim processing system will log the image to optical disk, apply form dropout, deskewing, despeckling, and then process it using OCR. Knowledge workers will repair any fields that seem to be in error. The claim will then either be paid (using existing mainframe processing system) or sent to adjudication.CS427 6-16Detailed (fully dressed) version of Submit Fax ClaimPrimary Actor: ProviderGoal in context: Pay legitimate claims while rejecting bad ones.Scope: Business - the overall purchasing mechanism, electronic and nonelectronic, as seen by the people in the company.Level: SummaryStakeholders and interests:Provider: Wants to be paid for services rendered.Company: Wants to cut costs and avoid fraudPrecondition: noneMinimal guarantees: Pay only certified providers, pay only for services that are covered by plan, do not pay if there are obvious mistakesCS427 6-17Main Success Scenario:Trigger: Claim submitted by fax1. Provider: submit claim by fax2. Claim system: drop forms, deskew, despeckle, use OCR to convert to electronic form3. Claim system: check claim to make sure it is legal4. Mainframe payment system: pay claimExtensions:2a. Some fields have low confidence: Knowledge worker corrects3a. Claim is not valid: send to adjudicationCS427 6-18Use Cases and RequirementsAn important part of requirementsHelp requirement traceabilityHelp manage requirementsCS427 6-19RequirementsUse casesStakeholders - people who careBusiness case - cost of project, time to complete projectInterfaces with outside systemsTechnology requirementsEase of use, ease of maintenance, throughput and response timeCS427 6-20TraceabilityTraceability - the ability to trace the effect of a requirement and determine who caused itWhy do we have this requirement? Who wrote it?How is this requirement met?What requirement caused this design?CS427 6-21Manage requirementsMust agree to change in requirementsUsually increases priceMust be reviewedMake sure each part of design is due to a requirementAnalyze problems: what was the root cause of this bug?CS427 6-22Scenarios and Use CasesScenario is concrete and detailednames of people$ values, particular dates, particular amountsScenario is a test caseUse Case is a contract, and collects all the scenariosCS427 6-23Goals and Use CasesActor has a goal for the use caseSystem forms subgoals to carry out its responsibilityGoals can failUse case describes a set of ways for carrying out the goal, and several ways of failingCS427 6-24When use cases don’t workCompilersone use case - compile a programDespecklerone use case - remove specklesNo interactionComplexity is caused byinput formattransformationCS427 6-25SummaryUse cases are useful, but not perfectMany ways to write use casesBig projects need big use cases Use the simplest way you can!CS427 6-26ReadingChapter 8 of Hamlet and MaybeeChapters 7, 9, and 16 of Kruchten, or chapter 12 and 14 of Kroll & Kruchten or read about the planning game (the first part of 10, the first part of 11, and 15 of Beck, chapter 12 of Beck & Andres or maybe
View Full Document