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 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 most 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. Keep Rules in a “Policies” Section

10. Use a Table for Complex Rules

11. Document Global Requirements in a Central Place l Distinguish between system-wide requirements and those that 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

12. Document Hints and Ideas l Design Notes l Examples 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

13. 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)

14. 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

15. 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

16. Describing Exceptions Makes Requirements More Complete

17. Exceptions Added to Place An Order

18. 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

19. Alternatives in Registration w/ Auto Activation

20. Keep Steps at Roughly the Same Level of Detail

21. Describe Exceptions at a High-Level

22. 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: Briefly describe what happens, or Refer to another use case describing the exception handling

23. 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 Document what happens. Either: Briefly describe the variation, or Refer to a new scenario or conversation that describes the variation in detail

24. Use Cases Can Be Related

25. 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

26. Use Case Model Example Classic Business Functions

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

28. Use Case Model Example Software application development environment

29. Emphasize What’s Important Within a Use Case

30. What’s Emphasized?

32. 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 narrative emphasizes the high points of a story, not the details A conversation emphasizes the dialog between system and actor A scenario emphasizes a sequence of actions. l Repeat and restate things to make them stand out l Choose a template that doesn’t inadvertently emphasizes the wrong things

33. A Use Case Writing Process

34. 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

35. Use Case 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

36. 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.

37. 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.

38. 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.

39. Abuse Cases – Some Warnings l Be careful not to put too much effort into structuring the use cases. l UML uses a pair of relationships between use cases: uses and extends. l These can be useful, but beware (especially of uses) l In such cases: Analysts take a fairly coarse grained use case and break it down into sub-use cases. Each sub-use case is further broken down usually until they reach some kind of elemental use case, which seems atomic to some degree.

40. Abuse by Decomposition l This is functional decomposition a style of design that is the antithesis of object- oriented development. l It leads to problems in a various ways. l One way is when this use case structure is reflected directly into the code. The design of the systems looks like the use cases. A common symptom is to find behaviorally rich controller objects manipulating dumb data objects.

41. Abuse by Decomposition l This kind of design loses most of the benefits of objects. l The system duplicates behavior across the different controllers. l Knowledge of the data structures is spread around these controllers. l The essence of the problem is that functional decomposition encourages you to think of a behavior in the context of a higher- level behavior. l That makes it difficult to use that same behavior in another context, even if it is mostly the same. l With objects you want to think of behaviors that are usable in many contexts. l Functional decomposition does not encourage that approach.

42. Abuse by Decomposition l You can avoid this problem by remembering that the internal structure of the system does not need to look like the external structure (the use cases). l However, this is a difficult concept for developers without object oriented experience who are also the most likely to build a functional decomposition.

43. Abuse by Decomposition l Even if you don’t find that the functional decomposition affects your internal design, a heavily structured set of use cases runs into trouble because people end up spending a lot of time on them. l A team can waste a lot of time by driving every use case down to elemental steps. arguing about which use cases fit into which higher-level use case. l Capturing every detail of the use cases isn’t needed in the early phases of development. l You do want to look early at the areas of high risk but a lot of the details can be left to the later stages of an iterative development. l That’s the whole point of iterative development.

44. Abuse by Abstraction l Objects are all about abstraction. l A good design is one that finds powerful yet simple abstractions making complex problems tractable. l As designers we are used to abstraction, encourage abstraction, even glory in abstraction. l But abstraction can lead to trouble with use cases.

45. Abuse by Abstraction l Here is what can happen. You understood the use cases at the beginning. But now you feel lost with the more abstract use cases. “I think I understand them when the developers explain them to me, but I can’t remember the explanations later.” l One of the primary purposes of use cases is to communicate with the users—the customers—of the system. l Abstracting the use cases beyond the level of comprehension isn’t going to help anyone.

46. Abuse by Abstraction l A lack of abstraction in the use cases does no harm, since the internal structure need not be the same as the external structure. l A lack of abstraction in the use cases does not seem to lead to lack of abstraction in the internals. l On the contrary, using less abstract use cases helps because mapping an abstract internal structure to a concrete use case helps us understand the abstraction.

47. Abuse by Abstraction l Abstracting use cases can also lead to larger use cases, which, in an iterative development, are more difficult to plan with. l You can also spend a lot of time arguing about the abstraction. l Generally better to err on the side of being too concrete. l Above all, don’t go more abstract that the user can follow. l Use the concrete use cases to explain and verify your powerful abstractions.

48. Abuse by GUI l With all the GUI painting tools out these days, more people are using them to help determine the use cases. l The logic is appealing. A GUI is concrete to a user. It helps catch the easy-to-forget details. It gives the user a sense of what the system will look like. GUIs are easy to prototype. They make reasonable demos to explain the capabilities of the future system. l GUI’s seem like a good requirements tool!

49. Abuse by GUI l But there is a fundamental problem. l When you show a GUI prototype to a user, it looks like nearly everything is done, that all that’s left is a bit of wiring behind the scenes. l Of course, we know that what lurks behind the scenes is the most complicated part of the exercise but this is exceedingly difficult for customers to understand. l GUIs lead to a false indication of progress and difficulty. It may be just a button on the UI. But providing it could take weeks of effort. l There’s a huge gap between the real effort and the perceived effort. l This makes it difficult to do the negotiation that is so important in scope control.

50. Abuse by GUI l And despite the fact that GUI tools seem so easy to use, there’s always a lot of fine tuning to make it look just right. l This fine tuning sets people’s expectations in a particular direction. l And that makes people reluctant to make changes when a simpler design idea comes along.

51. Abuse by GUI l One possible approach: Never show any GUI that hasn’t got fully working code behind it. l It’s still good to mock up GUIs. But you might want to do it with pen and paper. That way you avoid the false indication of progress. l Of course, the best approach depends on the level of sophistication of your customer. Something you should always be sensitive to.