6.13. Guideline: Write Black-Box Use Cases
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 thinkingsoftware elements have responsibilities and collaborate with other elements that have responsibilities.By defining system responsibilities with black-box use cases, one can specify what the system must do (the behavior or 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… |