1 CS427: Software Engineering I Darko Marinov (slides from Ralph Johnson)

CS Previous lectures zProject initiation yDecide whether to proceed, cost-benefit yConvince others to proceed, use documents xVision, use cases, risks, project plan [Homework 1] zRisks yTechnical, project, business zRequirements yFunctional vs. non-functional

CS Requirements zFunctional requirements ySoftware inputs, outputs, and their relationship zNon-functional requirements ySecurity, reliability, usability, scalability, maintanability, efficiency… zToday: Uses cases yHigh-level system description

CS System description zTypical description has two parts yData yOperations on that data zThree kinds of descriptions yRequirements ySpecification yDesign

CS Many notations zUML yUse cases yClass diagram yState diagram zHamlet and Maybee yFinite state machine, data flow diagram yProlog yPseudocode

CS Many purposes zCommunicate to yUser yDevelopers yBoss zComplete - lots of detail zEasy to read - less detail

CS Writing Effective Use Cases zAuthor: Alistair Cockburn zKnow the inside cover, front and back zMore info on Web (Wikis) yhttp:// (some broken links) yhttp://c2.com/cgi/wiki?UseCases (a bit old) yPapers yDiscussion boards

Where are the use cases?

CS Use-case diagram zShows actors and use cases zShows system scope and boundaries zNot a description of use cases themselves

CS Use cases zText - a form of writing zDescribes the system’s behavior as it responds to a request from an actor zMany kinds of use cases yBrief / detailed yRequirement / specification / design

CS Sequence of events zUse cases describe the sequence of events that happen when the system responds to a request yCan describe alternatives yCan describe errors

CS Use cases are text zUse cases should be easy to read yKeep them short yTell a story yWrite full sentences with active verb phrases yMake the actors visible in each sentence xVariation: Actor explicitly first, followed by a colon

CS Many variations of writing zUser stories zActor-goal list zUse case briefs zCasual use cases z“Fully dressed” use cases

CS Actor-goal list ActorTask-level goalPriority ProviderSubmit paper claim1 Provider Submit fax claim2 ProviderSubmit electronic claim3 Adjud.Adjudicate problem2

CS Use case briefs Actor Provider Adjucator Goal Submit paper claim Submit fax claim Adjudicate failed claim Brief Submit 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.

CS Brief (casual) version of Submit Fax Claim The 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.

CS Detailed (fully dressed) version of Submit Fax Claim Primary actor: Provider Goal 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: Summary Stakeholders and interests: Provider: Wants to be paid for services rendered Company: Wants to cut costs and avoid fraud Preconditions: none Minimal guarantees: Pay only certified providers, pay only for services that are covered by plan, do not pay if there are obvious mistakes

CS Main success scenario: Trigger: Claim submitted by fax 1. Provider: submit claim by fax 2. Claim system: drop forms, deskew, despeckle, use OCR to convert to electronic form 3. Claim system: check claim to make sure it is legal 4. Mainframe payment system: pay claim Extensions: 2a. Some fields have low confidence: Knowledge worker corrects 3a. Claim is not valid: Send to adjudication

CS Your example (1) Use case: Scope: Level: Primary actor: Goal: Stakeholders and interests: Preconditions: Trigger: Minimal guarantees: Success guarantees:

CS Your example (2) Main success scenario: Extensions:

CS Use cases and requirements zAn important part of requirements zHelp requirement traceability zHelp manage requirements

CS Requirements zUse cases zStakeholders - people who care zBusiness case - cost of project, time to complete project zInterfaces with outside systems zTechnology requirements zEase of use, ease of maintenance, throughput and response time

CS Traceability zTraceability - the ability to trace the effect of a requirement and determine who caused it yWhy do we have this requirement? Who wrote it? yHow is this requirement met? yWhat requirement caused this design?

CS Manage requirements zMust agree to change in requirements yUsually increases price yMust be reviewed zMake sure each part of design is due to a requirement zAnalyze problems: what was the root cause of this bug?

CS Scenarios and use cases zScenario is concrete and detailed yNames of people y$ values, particular dates, particular amounts zScenario is a test case zUse case is a contract and collects several scenarios

CS Goals and use cases zActor has a goal for the use case zSystem forms subgoals to carry out its responsibility zGoals can fail zUse case describes a few ways for carrying out the goal, and a few ways of failing

CS When use cases don’t work zCompilers yOne use case - compile a program zDespeckler yOne use case - remove speckles zNo interaction zComplexity is caused by yInput format yTransformation

CS Summary zUse cases are useful, but not perfect zMany ways to write use cases zBig projects need big use cases zUse the simplest way you can!

CS Next: Planning zChapter 8 of Hamlet and Maybee zRUP: Chapters 12 and 14 of Kroll & Kruchten zXP: Chapter 12 of Beck & Andres or Planning Game (note XP evolution) from say