Use Cases

This page provides a review of the Use Case sites on the web. After an introductory discussion of Use Cases, including their purpose, applications, and techniques for their use, links to some of the best web sites for learning about Use cases are discussed, including the sites with the most instructive examples, and those teaching advanced concepts that might not be apparent from a quick search of the web.

Overview

Use Cases are a modeling aid used in software design to describe a sequence of events in a way that both the end users of a system, and the system designers and developers, can each understand completely. Use cases typically describe an event initiated by either a human user or another application, however the event and response are usually external, to maintain separation of responsibility between the designer and the user. The users should not have to be concerned about thread synchronization, for example, and the users should not need to care how the feature will be implemented. By communicating in a common language, end users may indicate what they require from the system, and designers may understand how those externaly visible requirements from the users translate into derived requirements internal to the system, in modules and subsystems not necessarily visible to the users. Most Use Cases simply describe a flow of events from input, or request, to output, or response. A typical use case for purchasing a ticket could be described by a user as follows:

1. Customer requests ticket
2. Agent determines if space is available and informs customer
3. Customer purchases ticket, or declines price offered
4. Agent accepts payment and delivers ticket, or terminates
5. Customer terminates

Even an example as simple as the one shown above can help designers understand the implications, in terms of the system design, so that the system will satisfy the requirements. For example, there are multiple potential exception processing points in this use case; the Agent could determine there is no ticket available, or the price offered may be more than the Customer wants to pay. The Customer may decide not to purchase a ticket for any reason. Both the Customer and Agent will have to be designed to handle these exception cases. After satisfactorily working through the use case with the user, the designer will understand the user expects to be able to refuse to purchase the ticket, and the designer can then flow that requirement into the system internals.

Just as use cases help to identify Actors, Roles, and resources, they also help expose internal state and corner cases that designers may miss without this valuable input from the users. In addition, a well developed set of use cases can help designers make the system more robust, by enforcing restrictions on what users are allowed to do at certain points (for example, not allowing a subsequent missile launch, until the user presses a button on the firing panel indicating the previous launch was successful).

History

Use Cases were initially developed in the late 1960s by Ivar Jacobsen. Jacobsen continues to develop use case theory and applications to the present day, hosting many presentations and research articles on his website (most of the documents require a free registration by email address, however it should be well worth the cost to learn about use cases from the inventor). Wikipedia has a good writeup on Jacobson's contributions.

Alistair Cockburn is another important authority in use case theory and application; on his web site he describes the history of use cases, from before they were invented, until the present day, and hosts many resources for use cases from his site.

Another heavy hitter on use cases from the software development community is Ward Cunningham, the inventor of the wiki. Ward Cunningham has a page linked from his site that describes User Stories, which are different from use cases. Ward's main site is full of valuable information from one of the pioneers of software development.

Review of Use Case sites on the Web

developer.com has a practical walkthrough of Use Case Diagrams and how they are used to represent use cases. Wikipedia of course has many useful pages related to use cases, including Activity Diagrams, how use cases fit into the Unified Modeling Language, and the Essential Unified Process. The site http://www.agilemodeling.com/ has, in addition to plenty of information about agile methods, a page on use cases within agile processes. Among the many use case tutorials on the web, some of the more useful to this reviewer are Kennesaw State University's Object Oriented Analysis and Design page, and this page at Carnegie Mellon. In addition, this page from University of Washington presents some of Alistair Cockburn's use case wisdom in a tutorial format.

Another big player in use case application and theory is Andy Pols, who maintains a resource site known as the Use Case Zone, hosting many use case papers.

This paper from Microsoft presents some of the finer points of use case application, showing how designers can make a system more reliable by understanding how users can get into trouble, and yet avoiding disaster.

For some striking accounts of how use cases can really matter to the utmost, enter the world of embedded systems. This article begins the discussion of what can go wrong when use cases are ignored, including the failure of the Patriot missile, where designers did not expect the control system to remain running for more than a few hours. Another disaster described in the article the case of the Therac-25, a medical treatment device that, due to the failure of the designers to guarantee certain use case outcomes, allowed operators to deliver fatal doses of radiation to patients.

Here is what the US Government has to say about capturing user requirements with use cases for web pages, on their site [http://www.usability.gov/methods/usecases.html usability.gov].

Summary

Use cases are one of the most effective tools a designer can employ to bridge the gap between technical know-how of the developer and the domain knowledge of the user's requirements and expectations. The web has plenty of resources on Use Cases, and this page should provide a good starting point for learning about them.

http://www.ivarjacobson.com/resources/module/publications_action-download/file_id-172/

http://www.ivarjacobson.com/resources/module/publications_action-download/file_id-167/

http://www.ivarjacobson.com/resources/module/publications_action-download/file_id-173/

http://www.ivarjacobson.com/resources/module/publications_action-download/file_id-171/

http://alistair.cockburn.us/index.php/Main_Page

http://alistair.cockburn.us/index.php/Writing_Effective_Use_Cases_course

http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases

http://alistair.cockburn.us/index.php/Basic_use_case_template

http://alistair.cockburn.us/index.php/Use_case_fundamentals

http://alistair.cockburn.us/index.php/Structuring_use_cases_with_goals

http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases#Articles_online

http://alistair.cockburn.us/index.php/Resources_for_writing_use_cases#Presentations_online