This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
There is a common misconception that use cases have one form or can be stated in only one way. Practitioners are therefore confused when they see use cases stated in different ways. Many of the differences between use cases stem from the fact that a use case has a life cycle, and it will take different forms at different points in that life cycle.
The life cycle of a use case can be considered from many perspectives. It is important that people working with use cases understand the life cycle from the broader team working and software development perspectives as well as the use-case authoring perspective.
For the purposes of this book, the most important life cycle is use-case authoring. Initially, use cases begin as drawings that show the use cases and the actors who interact with the system during the use case. The use cases are little more than "ovals" and very terse names. This is sufficient for identifica-tion, but not much more. Very quickly, however, they evolve into brief descriptions, short paragraphs that summarize the things that the use case accomplishes. This brief description is sufficient for clarification, but more is still needed. The brief descriptions quickly give rise to outlines of the flows of events. Initially, these are just bulleted lists illustrating the basic flow and identifying the significant alternative flows. These bulleted outlines give an indication of the size and complexity of the use cases and are very useful for initial prototyping aimed at revealing requirements and technology-related risks.
For user-interface-intensive systems, the flows are often elaborated to cover the important things the user sees and does when interacting with the system. These "essential" use-case outlines are the primary drivers of the user interface's design. This level of description, while more than sufficient for users and interface designers, is greatly lacking for software developers and testers.
Additional evolution adds more information about the internal interactions, about testable conditions, and about what the system does, providing a more complete picture of the behavior of the system. These complete descriptions drive the development and testing of the system.
It's important to keep in mind that these are not "different" use cases, but the same use case from different perspectives and at different points in time. This "unified" view makes understanding and employing use cases easier.
The key to deciding how detailed to make your use cases is to consider two factors:
How unknown the area of functionality covered by the use case is. The more unknown, misunderstood, and risky the functionality described by the use case, the more detail is required.
What use is to be made of the description. It is very difficult to know when the use-case descriptions are complete if the downstream activities that the use cases are going to support are not also understood.
The following table summarizes the purpose, risks addressed, and downstream activities for each of the use-case authoring states:
|
Authoring State |
Primary Purpose |
Risks Addressed |
Downstream Activities |
|
Discovered |
Identify the use case |
|
|
|
Briefly Described |
Summarize the purpose of the use case |
|
|
|
Bulleted Outline |
Summarize the shape and extent of the use case |
|
|
|
Essential Outline |
Summarize the essence of the use case |
|
|
|
Detailed Description |
To allow the detail to be added incrementally |
|
|
|
Fully Described |
Provide a full requirements specification for the behavior encapsulated by the use case |
|
|