• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint

Good Goals

For these reasons, Lucy Lockwood and I developed essential use cases as a simplified, generalized, and more abstract model compared to their concrete cousins (see Chapter 22). Abstraction (as argued in Chapter 44) encourages innovation and robust design. The rationale behind essential use case modeling is to describe user tasks in and of themselves, stripped of any technological assumptions or constraints. An essential use case represents the abstract essence of something that a user may be trying to accomplish; it is cast in terms of user intentions rather than user actions. The users of the programmed tech support system, for example, intend to get help, to say who they are, and to make clear what problem or problems have been encountered.

Essential use cases not only separate the user problem from the designed solution, they separate user intentions from the system responses that support the realization of those intentions. Instead of one, free-form narration of the interaction—the story-telling approach taken in scenarios and most concrete use cases—essential use cases take the form of a structured narrative that divides the dialog into two columns: what the user wants to do and what the system should do in supporting response. These two columns are termed the user intention model and the system responsibility model, mimicking the format Rebecca Wirfs-Brock introduced for concrete use cases. For the task of using a programmed tech support system, one essential use case might be called getting technical help and could take this form:


PREVIEW

                                                                          

Not a subscriber?

Start A Free Trial


  
  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint