1 Actor-Goal List Including lower-level goals Goals should be on - PDF document

Announcements How to Write Use Cases ❚ Read Wiki/ Piazza ❚ Projects started in earnest (regular, 2- weeks milestones) ❚ HW2 due this Fri, Jan 23 rd ❚ - submission system will go live soon ❚ Today interview with Alistair Cockburn ❚ Missing class due to traveling to interviews/illness/emergency (FAQ on Wiki) CS361 4-2 1 Four kinds of use cases Claims Processing System Paper claim ❚ Actor/goal list <<include>> Knowledge Provider Worker ❚ Use case brief Fax to claim Automatic Claim Processing ❚ Casual Electronic claim ❚ Fully dressed Mainframe ❚ (Names taken from “ Writing Effective Use Cases ” by Alistair Cockburn) Adjudication Adjudicator Post office CS361 5-4 Goals Actor-Goal List ❚ Primary actor always has a goal Actor Task-level goal Priority ❚ Must pick right level for goal Provider Submit paper claim 1 ❙ Use case for Amazon - buy a book Provider Submit fax claim 2 ❙ Higher-level goal - learn something, make Provider Submit electronic claim 3 someone happy Adjud. Adjudicate problem 2 ❙ Lower-level goal - provide credit card info CS361 5-5 CS361 5-6 1

Actor-Goal List Including lower-level goals ❚ Goals should be on the same level ❚ Lower-level goals can improve readability ❙ Usually to reduce duplication ❚ Goal should be from point of view of primary actor ❙ Sometimes to shorten very long use cases ❚ Sort goals by primary actor ❚ To design components ❚ Priority to designer of system, not to actors ❚ When user has only one goal CS361 5-7 CS361 5-8 Actor-goal list for games Tower game ❚ Games have one use case - play game Actor Task-level goal Priority ❚ For use cases to be good requirements User Create towers 1 document, more detail is needed. Tower Shoot monsters 2 ❙ Use lower-level goals Monster Move toward user 2 Hoarde Create monsters 3 CS361 5-9 CS361 5-10 Use case brief Use case briefs Brief ❚ 1-6 sentence description of behavior Actor Goal Provider Submit paper Submit claim on paper, which is ❚ Mention only most significant behavior claim converted into electronic form, and and failures either paid or sent for adjudication ❚ Short enough to put many on a page Submit fax claim Provider Submit claim by fax, which is Used to processed by OCR and either paid or sent for adjudication. ❙ Estimate complexity Adjudicate failed Adjucator Decide whether a questionable claim ❙ Find components to reuse claim should be paid by the mainframe payment system or rejected CS361 5-11 CS361 5-12 2

Casual & Fully Dressed Design scope ❚ Used to tell developers what to build ❚ Actor/Goal list and use case briefs help decide design scope ❚ “ Casual ” consists of normal paragraphs ❙ What is in, what is out ❚ “ Fully Dressed ” has labeled sections ❙ What is a use case, is not a use case ❚ Both should emphasize “ main success ❚ Casual/fully dressed use case is given to scenario ” developers so they know what to build ❚ Both should include ways of failing ❚ Casual: one per page ❚ Fully dressed: 3-4 pages CS361 5-13 CS361 5-14 Brief (casual) version of Submit Fax Claim Fully dressed The Provider submits a claim by fax. The claim ❚ Primary actor processing system will log the image to optical ❚ Goal in context - what is the primary disk, apply form dropout, deskewing, actor ’ s bigger goal? despeckling, and then process it using OCR. Knowledge workers will repair any fields that ❚ Scope - system we are designing seem to be in error. The claim will then either ❚ Level - user goal, higher-level (summary), be paid (using existing mainframe processing lower-level (subfunction) system) or sent to adjudication. ❚ Stakeholders CS361 5-15 CS361 5-16 Fully dressed Main success scenario ❚ Preconditions: things that must be true ❚ Describe trigger before this use case can happen ❚ Give numbered list of actions leading to ❚ Guarantees: things that the use case will success ensure are always true ❚ Alternatives left to “ extensions ” ❚ Triggers: things that cause the use case to start CS361 5-17 CS361 5-18 3

Detailed (fully dressed) Extensions version of Submit Fax Claim Primary Actor: Provider ❚ Alternatives to main success scenario Goal in context: Pay legitimate claims while rejecting bad ❚ Special cases, failures ones. Scope: Claim system. ❚ Steps have same numbers as in main Level: Summary success scenario, but modified to show Stakeholders and interests: they are alternatives Provider: Wants to be paid for services rendered. ❙ 3a instead of 3. Company: Wants to cut costs and avoid fraud Precondition: none Minimal guarantees: Pay only certified providers, pay only for services that are covered by plan, do not pay if there are obvious mistakes CS361 5-19 CS361 5-20 Main Success Scenario: Writing Trigger: Claim submitted by fax ❚ Use present tense 1. Provider submits claim by fax ❚ Subject should be primary actor, system 2. Claim system drops forms, deskews, despeckles, and under design (always) and secondary uses OCR to convert to electronic form actors 3. Claim system checks claim to make sure it is legal 4. Mainframe payment system pays claim ❚ Verb should be what actor does to successfully move the use case forward Extensions: ❚ Avoid GUI: write in terms of goals, not 2a. Some fields have low confidence: Knowledge worker details of the GUI corrects 3a. Claim is not valid: send to adjudication CS361 5-21 CS361 5-22 Group Writing Discuss ❚ Group better for brainstorming, reviewing ❚ Use cases that you understand should have more detail than those you don ’ t ❚ Individuals better for writing understand ❚ Make list in a group ❚ What determines the level of detail? ❚ Write use cases in ones or twos ❚ Review as a group ❙ Writers ’ workshop CS361 5-23 CS361 5-24 4

Interview with Alistair Cockburn Next time TDD demo Read posted reading about JUnit tests CS361 5-25 CS361 5-26 5