Writing a brief description
As these use cases are identified, a brief description should be written. This serves several purposes. It clarifies the author (or group) thinking on what the use case really encompasses. Often good use case names are brief, and not too specific. For instance, does the use case maintain inventory levels include the receiving ordered goods, or only the ordering and purchasing side of the process? This can be stated in the brief description. Often such decisions are clarified when the use cases are identified and initially discussed, but such discussions are easily forgotten unless recorded in the brief description of the use case.
The best brief descriptions read like a Reader’s Digest condensation of the actual use case. They state who accomplishes what with the system in the specific usage. They are written much like a use case flow of events, but in very broad terms. A possible brief description for maintain inventory levels could be:
Marketing determines needed inventory levels based on sales projections. Warehousing and distribution report on current levels. Systems determines needed order quantities weekly and generates purchase orders for approval by procurement staff.
If these use cases are being identified in a workshop setting, have someone in the workshop create a brief description based on the group discussion at the time the use case is identified. This is a good
As we have noted previously, it can be very useful to analyze at least a portion of the enterprise to understand its use cases and operations, especially those which involve our system under consideration, If the enterprise is large and complex, we might not want to analyze all of its use cases and operations, but only those that we can identify as involving our system. It might be useful to draw a use case diagram for the enterprise level. Later we will draw them for other levels as well, but we will keep them separate. In an enterprise level use case diagram, the enterprise is considered as the system, and thus is not shown, so the diagram must be labeled so that it is clear to what system the use cases refers (Figure
