Filter
Top Products
Chapter 3. Black-box thinking: Defining the system context 39
GPS navigation system usages:
– Help me identify my destination using the information I know.
– Guide me to a destination.
– Find a Mexican restaurant that is on my way to my destination.
– Show me the hotels that I can reach in about 5 more hours of driving.
– Where are the truck stops in the cities I will pass through today?
This is quite a different kind of list. By describing the actual usages to which the
system will be put, and basing our designs on those, we are assured that the
system we design will meet the real needs. It is also interesting to note that many
of these usages can be accomplished with little additional development effort,
and no additional hardware. They are a matter of imagination. By combining
existing elements, we can perform interesting new usages, provided we imagine
these in our design process.
The important question to ask at this point is, What is the relationship between
the features and the usages? The answer to this is one of the keys to
understanding the MDSD modeling process. Usages are, in a way, combinations
of various features or services arranged in a sequence so as to provide value.
Instead of using a set of features as the sole statement of requirements of a
system, what if we were to describe a comprehensive set of system usages, and
then from these, derive the necessary features and functions? This would result
in an architecture optimized for usage. We would be sure that we have all of the
capabilities needed to perform (or realize) the usages, and we would be sure we
have not required any unnecessary functions.
Then, if we took it a step further, and used the same usage-based models to
design subsystems and components within the overall system, we could provide
comprehensive traceability. We could show precisely how even the most minute
operation of a component contributes to particular system usages. Changes to
any part of the system could be analyzed for impact to all other system elements,
and we would be assured of complete requirements coverage.
This is the kind of model MDSD can produce through system decomposition and
operation analysis, as introduced in “System decomposition” on page 22 and
“Operations analysis” on page 30, and explained in “Operation analysis” on
page 72. Of course, we still have to consider how constraints on functionality and
on the system itself will influence the architecture, and we will do that when we
consider localities and joint realization.