DOC PREVIEW
U of I CS 427 - Use Cases

This preview shows page 1-2-3-24-25-26 out of 26 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 26 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 26 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 26 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 26 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 26 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 26 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 26 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

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 descriptionTypical description has two partsdataoperations on that dataThree possible descriptionsrequirementsspecificationdesignCS427 6-3Many notations UMLUse casesClass diagramState diagramHamlet and MaybeeFinite state machine, Data flow diagramPrologPseudocodeCS427 6-4Many purposesCommunicate toUserDevelopersBossComplete - lots of detailEasy to read - less detailCS427 6-5Writing Effective Use CasesAlistair CockburnKnow the inside cover, front and backwww.usecases.orgpapersdiscussion boardsProviderFax to claimElectronic claimAutomatic Claim ProcessingKnowledgeWorkerPaper claimClaims Processing System<<include>>MainframePost officeAdjudicationAdjudicatorCS427 6-7Use case diagramShows actors and use casesShows system scope and boundariesNot a description of use casesLike a context diagramCS427 6-8SCD for Claims ProcessingClaims ProcessingSystemElectronic claimPostal SystemMainframeClaim adjudicatorFaxData repairPostal SystemData entryCS427 6-9Use CasesText - a form of writing.Describes the system’s behavior as it responds to a request from an actor.Many kinds of use casesBrief / detailedRequirement / specification / designCS427 6-10Use casesDescribe the sequence of events that happen when the system responds to a requestCan describe alternativesCan describe errorsCS427 6-11Use cases are textUse cases should be easy to readkeep them shorttell a storywrite full sentences with active verb phrasesmake the actors visible in each sentenceCS427 6-12Many ways of writing use casesUser storiesActor-goal listUse case briefsCasual 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 RequirementsAn important part of requirementsHelp requirement traceabilityHelp manage requirementsCS427 6-19RequirementsUse casesStakeholders - people who careBusiness case - cost of project, time to complete projectInterfaces with outside systemsTechnology requirementsEase of use, ease of maintenance, throughput and response timeCS427 6-20TraceabilityTraceability - the ability to trace the effect of a requirement and determine who caused itWhy do we have this requirement? Who wrote it?How is this requirement met?What requirement caused this design?CS427 6-21Manage requirementsMust agree to change in requirementsUsually increases priceMust be reviewedMake sure each part of design is due to a requirementAnalyze problems: what was the root cause of this bug?CS427 6-22Scenarios and Use CasesScenario is concrete and detailednames of people$ values, particular dates, particular amountsScenario is a test caseUse Case is a contract, and collects all the scenariosCS427 6-23Goals and Use CasesActor has a goal for the use caseSystem forms subgoals to carry out its responsibilityGoals can failUse case describes a set of ways for carrying out the goal, and several ways of failingCS427 6-24When use cases don’t workCompilersone use case - compile a programDespecklerone use case - remove specklesNo interactionComplexity is caused byinput formattransformationCS427 6-25SummaryUse cases are useful, but not perfectMany ways to write use casesBig projects need big use cases Use the simplest way you can!CS427 6-26ReadingChapter 8 of Hamlet and MaybeeChapters 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

U of I CS 427 - Use Cases

Download Use Cases
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Use Cases and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Use Cases 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?