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
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
–Locate nearest
–Display remaining distance and time to destination.
–Resume navigation to destination after power on.
–Warn when off route and
–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:
