This chapter is from the book
This chapter is from the book
This chapter is from the book
1.3 Why a Use Case Pattern Language?
There are no absolute criteria we can use to differentiate between good and poor quality use cases. Authors and teachers have always had a difficult time saying why the good ones were good and what was wrong with the bad ones. To see the difference between good and bad, and the difficulty in identifying what makes the difference, try your hand at comparing this fragment against the poorly written example in Use Case 1.1.
Use Case 1.2 Main Scenario for a Well-Written Use Case
Register for Course
Student requests a new schedule.
The system prepares a blank schedule form and pulls in a list of open and available courses from the Course Catalog System.
Student selects primary and alternate courses from the available offerings.
For each course, the system verifies that the Student has the necessary prerequisites and adds the Student to the course, marking the Student as "enrolled" in that course in the schedule.
When the Student indicates the schedule is complete, the system saves the schedule.
Notice that the well-written use case is much shorter, contains fewer details, and is easier to read than the first one. Yet we cannot simply say, "Write concise, less detailed use cases that are easy to read." Some problems are long and incredibly complex, involving many details, and as a result yield long, detailed, and somewhat difficult to read use cases, no matter how well written.
To make matters worse, each development organization has its own culture, its own people, and its own way of doing things. What works for one organization may not work for another. This disparity makes it impossible to define a "one-size-fits-all" process for creating high-quality use cases.
We want to capture guidelines that can help us write good use cases and evaluate existing ones. We must find some way to describe these terms so that they are meaningful in different organizations and development cultures.
To counter the common problems in writing use cases and push the result toward well-written use cases, we have constructed and cataloged in this handbook a small set of patterns that gives us a vocabulary for describing the characteristics of a good-quality use case. Put another way, these are characteristics that signify that quality is present in the writing. Some of these patterns apply to a single sentence in the use case, some apply to a single scenario, and some apply to the set of extensions or to the use case itself. More patterns are needed to discuss multiple use cases and more still to discuss the entire use case set, even the place of a use case in the requirements document. We find that simply describing the use case itself is insufficient, and discussions quickly move from the use cases themselves to the teams writing them and the processes they use for constructing and reviewing the use cases.
The patterns in this language describe the signs of quality about the use cases and the writing process. These signs of quality serve several purposes. They provide a vocabulary for writing use cases, giving people the words they need to express what they want to see, or change, in a set of use cases. While we do not expect these patterns to help the starting writer produce excellent use cases, they can be invaluable for the more experienced writer, offering time-tested advice for improving their use cases. These patterns are best considered as a diagnostic tool, and should be of great use in reviewing the use case drafts to improve their quality. The absence of any sign indicates that something important is missing, because a good set of use cases exhibits all of these patterns.