6.5. Use Case Types and Formats
Black-Box Use Cases and System Responsibilities
Black-box use cases are the most common and recommended kind; they do not describe the internal workings of the system, its components, or design. Rather, the system is described as having responsibilities, which is a common unifying metaphorical theme in object-oriented thinking—software elements have responsibilities and collaborate with other elements that have responsibilities.
By defining system responsibilities with black-box use cases, it is possible to specify what the system must do (the functional requirements) without deciding how it will do it (the design). Indeed, the definition of “analysis” versus “design” is sometimes summarized as “what” versus “how.” This is an important theme in good software development: During requirements analysis avoid making “how” decisions, and specify the external behavior for the system, as a black box. Later, during design, create a solution that meets the specification.
| Black-box style | Not |
|---|---|
| The system records the sale. | The system writes the sale to a database. ...or (even worse): The system generates a SQL INSERT statement for the sale... |
Formality Types
Use cases are written in different formats, depending on need. In addition to the black-box versus white-box visibility type, use cases are written in varying degrees of formality:
brief— terse one-paragraph summary, usually of the main success scenario. The prior Process Sale example was brief.
casual— informal paragraph format. Multiple paragraphs that cover various scenarios. The prior Handle Returns example was casual.
fully dressed— the most elaborate. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees.
The following example is a fully dressed case for our NextGen case study.