CS427: Software Engineering IPrevious lecturesRequirementsSystem descriptionMany notationsMany purposesWriting Effective Use CasesSlide 8Use-case diagramUse casesSequence of eventsUse cases are textMany variations of writingActor-goal listUse case briefsBrief (casual) version of Submit Fax ClaimDetailed (fully dressed) version of Submit Fax ClaimMain success scenario:Your example (1)Your example (2)Use cases and requirementsSlide 22TraceabilityManage requirementsScenarios and use casesGoals and use casesWhen use cases don’t workSummaryNext: Planning1CS427:Software Engineering IDarko Marinov(slides from Ralph Johnson)CS427 6-2Previous lecturesProject initiationDecide whether to proceed, cost-benefitConvince others to proceed, use documentsVision, use cases, risks, project plan [Homework 1]RisksTechnical, project, businessRequirementsFunctional vs. non-functionalCS427 6-3RequirementsFunctional requirementsSoftware inputs, outputs, and their relationshipNon-functional requirementsSecurity, reliability, usability, scalability, maintanability, efficiency…Today: Uses casesHigh-level system descriptionCS427 6-4System descriptionTypical description has two partsDataOperations on that dataThree kinds of descriptionsRequirementsSpecificationDesignCS427 6-5Many notations UMLUse casesClass diagramState diagramHamlet and MaybeeFinite state machine, data flow diagramPrologPseudocodeCS427 6-6Many purposesCommunicate toUserDevelopersBossComplete - lots of detailEasy to read - less detailCS427 6-7Writing Effective Use CasesAuthor: Alistair CockburnKnow the inside cover, front and backMore info on Web (Wikis)http://www.usecases.org (some broken links)http://c2.com/cgi/wiki?UseCases (a bit old)PapersDiscussion boardsP r o v i d e rF a x t o c l a i mE l e c t r o n i c c l a i mA u t o m a t i c C l a i m P r o c e s s i n gK n o w l e d g eW o r k e rP a p e r c l a i mC l a i m s P r o c e s s i n g S y s t e m< < i n c l u d e > >M a i n f r a m eP o s t o f f i c eA d j u d i c a t i o nA d j u d i c a t o rWhere are the use cases?CS427 6-9Use-case diagramShows actors and use casesShows system scope and boundariesNot a description of use cases themselvesCS427 6-10Use 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-11Sequence of eventsUse cases describe the sequence of events that happen when the system responds to a requestCan describe alternativesCan describe errorsCS427 6-12Use 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 sentenceVariation: Actor explicitly first, followed by a colonCS427 6-13Many variations of writingUser storiesActor-goal listUse case briefsCasual use cases“Fully dressed” use casesCS427 6-14Actor-goal listActor Task-level goalPriorityProvider Submit paper claim 1Provider Submit fax claim 2Provider Submit electronic claim 3Adjud. Adjudicate problem 2CS427 6-15Use case briefsActorProviderProviderAdjucatorGoalSubmit paper claim Submit fax claimAdjudicate failed claimBriefSubmit claim on paper, which is converted into electronic form, and either paid or sent for adjudication.Submit 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 rejected.CS427 6-16Brief (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-17Detailed (fully dressed) version of Submit Fax ClaimPrimary actor: ProviderGoal in context: Pay legitimate claims while rejecting bad onesScope: Business - the overall purchasing mechanism, electronic and nonelectronic, as seen by the people in the companyLevel: SummaryStakeholders and interests:Provider: Wants to be paid for services renderedCompany: Wants to cut costs and avoid fraudPreconditions: noneMinimal guarantees: Pay only certified providers, pay only for services that are covered by plan, do not pay if there are obvious mistakesCS427 6-18Main 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-19Your example (1)Use case:Scope:Level:Primary actor:Goal:Stakeholders and interests:Preconditions:Trigger:Minimal guarantees:Success guarantees:CS427 6-20Your example (2)Main success scenario:Extensions:CS427 6-21Use cases and requirementsAn important part of requirementsHelp requirement traceabilityHelp manage requirementsCS427 6-22Requirements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-23Traceability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-24Manage 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-25Scenarios 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 several scenariosCS427 6-26Goals 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 few ways for carrying out the goal,