1. Conversation Form l One path through a use case that emphasizes interactions between an actor and the system l Can show optional and repeated actions l Each action can be described by one or more substeps l May describe: Actor actions System responsibilities and actions

2. A Conversation Make A Payment - General Flow

3. Maintain a Consistent Level of Detail l Do not mix intent, action and detail in the same use case l Write at a level that seems appropriate to your readers l This typically means describing actions, not minute details l Description within a use case should be at the same level of abstraction (± one)

4. Maintain a Consistent Level of Detail

5. Choosing Between Conversations and Scenarios l Use a scenario when: a simple list of actions is sufficient actor-system interactions aren’t interesting l Use a conversation when: there are many interactions and you want to describe them you want to show more detailed system responses you want to separate the roles of actor and system

6. Don’t Embed Alternatives

7. Leave Out Information Formats and Validation Rules

8. Don’t Mention Objects in System Actions

9. Leave Out Presentation Details l Widget details described: Display note in a read/write text field From account in a drop-down list box Amount in a currency field l Fixed: Display payment template editable fields (note, from account, amount) l Reference screens used by a conversation Screens: See Login Page

10. Writing a Conversation

11. Showing More Detail l Describe what is done to accomplish the use case Basic functionality Variations Exceptional conditions Things that must be true before starting the use case Things that must be true on exiting the use case

12. Keep Rules in a “Policies” Section

13. Use a Table for Complex Rules

14. Document Global Requirements in a Central Place l Distinguish between system-wide requirements and those than span several use cases Example: System must run 7 by 24 Example: Account information should be encrypted and transmitted over a secure connection l Reference those requirements that are satisfied by the use case below the use case body

15. Document Hints and Ideas l Design Notes l Errors and warnings about registration information contents should be collected and returned to the user in a detailed message rather than stopping at the first detectable error. l Payments should be shown in time order, with the current date first. l The user should not see payments that he should have visibility of. Prevent a user from seeing a payment from secret accounts that he should be unaware of. l Add design notes as they occur to you

16. Alternative Paths l For each significant action: Is there another significant way to accomplish it that could be taken at this point? (Variation) Is there something that could go wrong? (Exception)

17. Choices for Describing Variations l Add textual descriptions of variations in the variations section of the use case template, which may reference an additional use case or l Modify the body of the use case to show the variation, especially when you want to emphasis the variation, which may reference an additional use case or l Draw an activity diagram that shows decision points, alternate paths, and parallel activities

18. Choices for Describing Exceptions l Add textual descriptions of exception in the exceptions section of the use case template, which may reference an additional use case or l Draw an activity diagram that shows decision points, alternate paths, and parallel activities

19. Describing Exceptions Makes Requirements More Complete

20. Exceptions Added to Place An Order

21. When to Create a New Use Case to Describe An Alternative l Write another... when an alternative appears complex when an alternative is important and you want to emphasize it l Document simpler alternatives in the supplementary part l Document more complex ones as separate use cases l Rewrite and reorganize for clarity! l Give new use cases specific names that identify specific conditions

22. Alternatives in Registration w/ Auto Activation

23. Keep Steps at Roughly the Same Level of Detail

24. Describe Exceptions at a High-Level

25. Documenting Exceptions l Name the exception below the use case body l Tell what step it relates to l Tag an exception when it is unrecoverable. Describe what happens after it is detected, or l When an exception is recoverable, describe the steps the actor or system takes to recover l Document what happens: Choose an appropriate form Briefly describe what happens, or Refer to another use case describing the exception handling

26. Documenting Variations l Decide whether the variation should be described within the use case body or if it should be referenced below the use case body (consider emphasis) l Decide whether it needs a separate description l Document what happens. Either: Briefly describe the variation, or Refer to a new scenario or conversation that describes the variation in detail

27. Use Cases Can Be Related

28. Use Case Levels l Use cases can be written at differing levels of abstraction and scope. Each serves a purpose: Summary— General descriptions and sweeping overviews of system functionality or business processes Core— Task-related descriptions of users and how they interact with the system; descriptions of a specific business process Supporting— Descriptions of lower-level activities used to complete subparts of a core use case Internal—Descriptions of the behaviors of and interactions between internal system components

29. Use Case Model Example Classic Business Functions

30. Use Case Model Example Ad hoc information query/data warehousing

31. Use Case Model Example Software application development environment

32. Emphasize What’s Important Within a Use Case

33. What’s Emphasized?

35. Emphasize What’s Important Within a Use Case Model l Place first those use cases you wish to emphasize l Choose the form of use case descriptions according to what you want to emphasize: A conversation emphasize the dialog between system and actor A narrative emphasizes the high points of a story, not the details l Repeat and restate things to make them stand out l Choose a template that doesn’t inadvertently emphasizes the wrong things

36. A Use Case Writing Process

37. Organize Your Use Case Descriptions l Choose an organization for your use cases by level (summary first, core next, supporting, then internal ones last) by actor by type of task arranged in a workflow

38. Use Case Model Review Checklist l Check for internal consistency between use cases l Identify “central” use cases l Identify unmet or externally satisfied preconditions l Review the actor’s view for completeness l Review the handling of exceptions l Document use case dependencies, extensions and includes relationships l Document external dependencies

39. Example – Register for a Course 1. Display a blank schedule. 2. Display a list of all classes in the following way: The left window lists all the courses in the system in alphabetical order. The lower window displays the times the highlighted course is available. The third window shows all the courses currently in the schedule. 3. Do 4. Student clicks on a course. 5. Update the lower window to show the times the course is available. 6. Student clicks on a course time and then clicks on the "Add Course" button.

40. Example – Register for a Course 7. Check if the Student has the necessary prerequisites and that the course offering is open. 8. If the course is open and the Student has the necessary prerequisites, add the Student to the course. Display the updated schedule showing the new course. If no, put up a message, "You are missing the prerequisites. Choose another course." 9. Mark the course offering as "enrolled" in the schedule. 10. End do when the Student clicks on "Save Schedule." 11. Save the schedule and return to the main selection screen.

41. Improved Version 1. Student requests a new schedule. 2. The system prepares a blank schedule form and pulls in a list of open and available courses from the Course Catalog System. 3. Student selects primary and alternate courses from the available offerings. 4. For each course, the system verifies that the Student has the necessary prerequisites and adds the Student to the course, marking the Student as "enrolled" in that course in the schedule. 5. When the Student indicates the schedule is complete, the system saves the schedule.