Filter
Top Products
Chapter 3. Black-box thinking: Defining the system context 49
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 tank—great for commuting and
shopping, but no good for long trips. On balance, it pays to try to discover the
required usages and then combine them as possible.
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 re-order points, and so forth. Are these complete usages? They
could be, and they will work as use cases, but it should be considered that maybe
there is one larger usage that encompasses both of these smaller interactions.
One could ask if determining re-order points is one of the purposes of the
system, or is it really in the service of some larger goal, such as maintain
inventory levels? If the latter, then we could try using that as the use case and
see if it can be expressed as a flow of events. If so, we have found something
closer to the heart of the system’s purpose, and a better use case.