Filter
Top Products
38 Model Driven Systems Development with Rational Products
The process is ironic in fact. Those writing the requirements for the system
clearly imagine using the system as they write, but what they write are
requirements, features, and attributes. They usually do not fully describe the
usages they are imagining that give rise to those features. Then, system
engineers and designers read these requirements and attempt to re-imagine how
the system will be used! Misunderstandings and unfortunate assumptions result
in a system that is only a partial fit for the intended uses.
Even when a document (or documents) such as a CONOPS (concept of
operations) is provided, the context is not maintained, nor is traceability provided
throughout the whole development process.
So, while there are many possible contexts from which to describe a system, the
most important one is its usage. By placing a system in the context of the people
and other systems with which it interacts, identifying the usages that deliver
value, and describing the precise nature of those usages, we describe a system
in the most
useful way possible!
Usage-driven versus feature-driven system design
To make this important idea clear, let us consider an example. Automobile
navigation systems based on the Global Positioning System (GPS) satellite
network have become fairly common in recent years. From examining and
comparing these systems and how they operate, it seems clear that for the most
part, they were designed by considering the features they should have instead of
the usages they should perform. If a designer (or more likely, a committee of
designers) were to sit down and try to write the requirements for a new GPS
navigation product, they would likely write a list of features similar to this:
GPS navigation system features:
– Plot route from current location to an address.
– Enter addresses by choosing the city, then street, then street number.
– Select fastest, shortest, or highway-avoiding routes.
– Locate nearest point-of-interest by category (restaurant, fuel station).
– Display remaining distance and time to destination.
– Resume navigation to destination after power on.
– Warn when off route and re-route based on new current location.
– Retrace my route back to my starting point.
Nothing here is bad or incorrect. Such a list, however, ignores a number of
important aspects of how such a system might be used in actual practice. If,
instead of trying to list features, the designers try to list how the system will
actually be used, quite a different picture emerges. Asking What will the system
be used for? instead of What should the system do? produces a list more like
this: