You are starting to write use cases with a SharedClearVision(95) and a ClearCastOfCharacters(105).
You will not make timely progress or create coherent use case sets if you waste energy writing detailed use cases sequentially.
Its hard to imagine building a house without an architect’s sketch or drawing that shows us the big picture of how the completed house will look, and how it will relates and influence its surroundings. The architect may also provide interior sketches to help us visualize the interior of the house. From these sketches an architect will begin to create the detailed plans for the house.
But homes have not always been designed in such a breadth first manner. Back in the “good old days”, there was no big picture, and people living on the frontier literally built their houses one room at a time. Materials were scarce, and people didn’t have the time to build large homes, so they just made do. Later, as they prospered and their families grew, they added more rooms onto the house, again one at a time. The results of this process are interesting; if you visit one of these homes today you will notice unusual features such as exterior walls on the inside, or bedrooms you can only enter through other bedrooms. The tour guides at Abraham Lincoln’s house in Springfield, Illinois will tell you that the second floor “floats”; it is not anchored to any supporting walls because someone added it on later.
You can write better use cases if you have a good idea of what they will look like when you are finished. Unfortunately, you usually don’t know that much about a system when you start.
Developing use cases is a process in which you are continually learning and reevaluating your model. Fortunately, there are some things that you can do to help guide you along the way, and provide order to your process.
Requirements gathering is a process of discovery. It starts with a vague notion of the desired system, which makes it impossible to get the details correct the first time around. In most cases the people who commission the software system do not know exactly what they want and are unable to articulate their needs. The use case writing process is an iterative one in which you must define, analyze and refine your underlying requirements in order to resolve conflicts and remove ambiguities from your model. The writing team will naturally write more suitable use cases once they better understand the system.
People are drawn into writing the details early. It is always difficult to begin a new project, and thinking about the whole, poorly understood system can be overwhelming. Trying to ramp up quickly is hard, and getting your head around a complex system is much akin to boiling the ocean. Developers often feel uncomfortable about spending the time necessary to comprehend a whole system as they feel that they are wasting too much time, and should be producing something tangible instead. When people are not sure how to proceed, they have a tendency to dive into the nitty-gritty details and start specifying detailed requirements about the small parts of the system that they understand, even if it is not very important to the big picture. Unfortunately, project managers encourage this tendency because they measure progress based on concrete deliverables and complete use cases fit the bill perfectly.
People lose energy or get bogged down in too much detail. A typical use case may have up to four general elements: actors and goals, main success scenario, failure conditions and failure
of the use case, as it is tempting to examine the alternatives. But whenever people follow a step with too many details, for example, its failure conditions and failure handling, they tend to lose their focus and energy describing all the possible extensions conditions.
It is advantageous to get an overview early. If you start with an outline and then write just the essence of each use case, you give each stakeholder the opportunity to offer correction and insight early in the process. It also permits the work to be prioritized and split across multiple groups and releases, increasing parallelism and improving productivity.
The more detailed in your early endeavors, the more you will have to change them as you learn more about the system. Most projects are short on time and energy so continually changing the same use case is discouraging and stressful. The participants may start questioning their involvement and lose confidence in their use cases altogether.
Therefore:
Conserve your energy by developing an overview of your use cases first, then progressively add detail, working across a group of related use cases.
Start writing your use cases by outlining them before adding detail. Identify candidate use cases by associating a meaningful goal for each actor, defining a use case for every combination (UserValuedTransactions(110)). Using the goal, derive an IntentionRevealingName(144) for each use case. Once you feel that you have defined a fairly complete set of use cases, work through your set, refining it, combining equivalent use cases and eliminating unnecessary ones (see MergeDroplets(211), RedistributeTheWealth(206), and CleanHouse(216). The resulting set of system goals provides a fundamental, shared understanding for the stakeholders and helps reduce the amount of refactoring required later on.
Once your overview is complete, develop the outlined use cases in an incremental manner, increasing the precision as you learn more about the system. Avoid the tendencies to complete an entire use case all at once or to write them one at a time. Instead, develop your use cases in a series of SpiralDevelopment(66) cycles, incrementally adding detail and reviewing the effect the new detail has on the model, until you determine that it is QuittingTime(71). Expand your use cases into ScenarioPlusFragments(136) by describing the main success scenario of each use case, naming the various conditions that can occur, and then fleshing out some of the more important ones. Again, be ruthless about eliminating non-essential pieces from the collection.
Add more detail to the fragments, creating a list of ExhaustiveAlternatives(140) in the next cycle.
Templates are an essential use case development tool that provide organization and a common look and feel to the use cases. They are especially valuable when doing incremental development, because templates can serve as placeholders which allow the writers to organize their use cases while they are still missing large pieces. Simple or lower priority use cases don’t always require the same amount of information as the more critical ones, so you can use MultipleForms(83) to document each use case with an appropriate level of detail and precision.
Sometimes you do need to finish some use cases before others. In that case, take an incremental approach based on project priority. Identify the most important use cases, such as those that define the project, or those that need to be done first, based on business or technical issues. Prioritize these as you start writing, and work them in groups for the aforementioned reasons. You may work on other use cases as well, but not at the expense of the most important ones.
BreadthBeforeDepth(XXX) provides order to the use case writing process. The overview lets you see the big picture without getting bogged down in details. Working at a high level makes it easier to sketch in the system and its boundaries, as well as verify that your use cases provide complete coverage of all of the system’s functionality. This high level view also allows you to start project planning and enables you to prioritize your work and develop the most important use cases first, and do the less important ones later.
Working across a group of related use cases makes it easier to realign the use cases and eliminate the ones you determine to be unnecessary before expending much effort on them.
Fredrick Brook’s classic quote “Be prepared to throw one away…because you will” [BROO1995]
is appropriate for writing use cases. Often a team learns more about a system’s requirements as the project progresses, and they may have to dramatically alter or even throw away earlier work.
The sooner you can identify unnecessary use cases, the better, because it is wasteful and demoralizing to throw away highly detailed use cases on which someone has spent a lot of energy.
Examples
This pattern is closely related to the following one, SpiralDevelopment(66). Therefore, we will defer offering an example until we have discussed it.
Breadth Before Depth and UML by Dan Rawthorne
The UML's Use Case Model is an overview of the functionality of the system. It does a very good
diagram during requirements gathering prevents use case writers from diving into the details too early.
It is tempting to put too much information on the diagram. At this early stage of development it is probably enough to just show the actors and use cases, and be very sparing with the use case relationships. Better yet, avoid the temptation to prematurely introduce use case relationships.
This pattern was influenced by Rick Ratliff’s Breadth First pattern from the OOPSLA 98 Use case patterns workshop.
1.2 SpiralDevelopment(66)