The first point of discussion is whether these are actually separate usages or all just aspects of some master use case, such as travel from point to point. This is
an important consideration. The question boils down to, how similar are these usages, and how different? This can be a difficult question to answer until the details of each usage are specified, so our general guidance is, if it seems they might be different enough to warrant separate use cases, keep them separate until it is clear they can be combined. Note also that similar usages might give rise to new and important requirements. If we omit the go on vacation use case, we might build a car with a two gallon fuel
To continue our example, a little more thinking should produce additional usages for the car such as these:
Listen to music.
Watch a movie.
Cool off (this was mentioned by a group in Florida in the summer).
Put the baby to sleep (all mothers know that car motion can be sleep inducing).
Take a nap (just check the parking lots during lunch time for evidence of this; one vehicle I know allows the heater to run with the engine off to keep a napper warm for a while).
Each usage must be complete, that is, it must reflect a complete goal that someone has. By listen to music, we do not mean listen to music as one drives to a destination, we mean using the car to listen to music. This is also an important point. With use cases, we are after the main, complete usages. It is always useful to ask the question: Could this use case be a part of some larger usage? This is not an attempt to consolidate or combine use cases just so that there are fewer, but an attempt to find the real, complete usages of the system.
An example might help here. If we ask what the stakeholders for a large supply chain system use the system for, we might get answers like, look up inventory levels, determine
Chapter 3. | 49 |
