| Programmers have used use cases in the design of software for years. Indeed, it is this tradition that gives use cases some of their power: developers are very accustomed to seeing them and will likely understand them immediately, as will the business people who have over the years had to use them to communicate with programmers. Other design documents, while gaining recognition and acceptance, are simply not as well established. Use cases are a means of roughing out the functionality of a product or service. A use case attempts to explain in plain language what a certain function does and why. Use cases also describe whom the function involves. Use cases begin by identifying a set of potential actors. These actors can be based on the personas, but they can even be simpler than that. For example, "the user" can be one of these actors. Another of these actors is typically "the system." The system is the generic actor for any automatic or computing process. It is typically these processes that programmers have been interested in defining, but use cases don't need to be limited to describing events involving the system. Use cases have the following form: A title. This should be descriptive, since it will be referenced often, both in documents and conversation. For example, a use case from an e-mail project might be called "Send an E-mail." The actors. Who is performing the function? In the Send an E-mail example, the actors are the user and the system. The purpose. What is this use case meant to accomplish and why? For the function sending an e-mail, the purpose would be something like this: "An actor wants to send a message to someone electronically." The initial condition. What is happening when the use case starts? In our example, it is simply that the e-mail client is open. The terminal condition. What will happen once the use case ends? In the e-mail example, the condition is again simple: an e-mail will be sent. The primary steps. Discrete moments in this piece of functionality. In the e-mail example, these would be the steps: 1. | Actor opens up a new mail window.
| | | 2. | Actor enters the e-mail address of the recipient or selects it from the address book.
| 3. | Actor enters a subject.
| 4. | Actor enters message.
| 5. | Actor sends mail via some method (for example, a button click).
| 6. | The system checks to make sure the mail has a recipient address.
| 7. | The system closes the mail window.
| 8. | The system sends the mail.
| 9. | The system puts a copy of the mail into the Sent Mail folder.
|
Alternatives. Alternatives are other use cases that may consider the same or similar functionality. In the Send an E-mail example, Reply to Sender and Forward Mail might be use case alternatives. Other use cases used. Frequently, one piece of functionality is built upon another. List those for reference. The e-mail example includes a few functions that could have their own use cases: Open an E-mail Window, Select an Address from the Address Book, and Confirm Recipient Address might all be separate use cases.
Use cases can be broad (Send an E-mail) or very detailed (Confirm Recipient Address). Use cases can also be very time consuming to create, and a complicated system could potentially have dozens, if not hundreds, of use cases. Use cases are, however, an excellent tool for breaking down tasks and showing what the system will have to support. |
