Filter
Top Products
50 Model Driven Systems Development with Rational Products
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 check—if there is not enough
known to write a brief description, then perhaps the use case is too vague, or we
do not have the right stakeholders and subject matter experts in attendance.
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 3-3).