USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT
The indispensable first step to getting the things you want out of life: decide what you want. —Ben Stein
• • • • Identify and write use cases. Relate use cases to user goals and elementary business processes. Use the brief, casual, and fully dressed formats, in an essential style. Relate use case work to iterative development.
This chapter is worth studying during a first read of the book because use cases are a widely used mechanism to discover and record requirements (especially functional); they influence many aspects of a project, including OOA/D. It is worth both knowing about and creating use cases. Writing use cases—stories of using a system—is an excellent technique to understand and describe requirements. This chapter explores key use case concepts and presents sample use cases for the NextGen application. The UP defines the Use-Case Model within the Requirements discipline. Essentially, this is the set of all use cases; it is a model of the system's functionality and environment.
6 - USE-CASE MODEL: WRITING REQUIREMENTS IN CONTEXT
Goals and Stories
Customers and end users have goals (also known as needs in the UP) and want computer systems to help meet them, ranging from recording sales to estimating the flow of oil from future wells. There are several ways to capture these goals and system requirements; the better ones are simple and familiar because this makes it easier—especially for customers and end users—to contribute to their definition or evaluation. That lowers the risk of missing the mark. Use cases are a mechanism to help keep it simple and understandable for all stakeholders. Informally, they are stories of using a system to meet goals. Here is an example brief format use case: Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items. Use cases often need to be more elaborate than this, but the essence is discovering and recording functional requirements by writing stories of using a system to help fulfill various stakeholder goals; that is, cases of use.] It isn't supposed to be a difficult idea, although it may indeed be difficult to discover or decide what is needed, and write it coherently at a useful level of detail. Much has been written about use cases, and while worthwhile, there is always the risk among creative, thoughtful people to obscure a simple idea with layers of sophistication. It is usually possible to spot a novice use-case modeler (or a serious Type A analyst) by an over-concern with secondary issues such as use case diagrams, use case relationships, use case packages, optional attributes, and so forth, rather than writing the stories. That said, a strength of the use case mechanism is the capacity to scale both up and down in terms of sophistication and formality, depending on need.
The idea of use cases to describe functional requirements was introduced in 1986 by Ivar Jacobson [Jacobson92], a main contributor to the UML and UP. Jacobson's use case idea was seminal and widely appreciated; simplicity and 1. The original term in Swedish literally translates as "usage case."
USE CASES AND ADDING VALUE
utility being its chief virtues. Although many have made contributions to the subject, arguably the most influential, comprehensive, and coherent next step in defining what use cases are (or should be) and how to write them came from Alistair Cockburn, summarized in the very popular text Writing Effective Use Cases [CockburnOl], based on his earlier work and writings stemming from 1992 onwards. This introduction is...