Filter
Top Products
Chapter 3. Black-box thinking: Defining the system context 37
The system in context
In MDSD, we consider multiple viewpoints in describing a system. We must make
choices about what to describe, where to start, and how to know we are done. To
begin, we place the system in its context. This might seem like an obvious step,
but many systems are described without reference to their context; or, if context
is considered, it does not play a central role in the development methodology. It is
natural to describe the pencil in isolation, considering only, or mainly, the
attributes and qualities of the pencil in a vacuum, so to speak.
If we wish to describe the pencil in its context, then we must first choose the
context in which the pencil exists. We might consider the pencil as a
stock-keeping unit (SKU) in an inventory system. This would give us one kind of
contextual description. Yet another context would be the pencil as an item being
manufactured, a participant in the many shaping, assembly, and finishing
processes it undergoes. The context we choose is determined by our needs.
Consider also a car. The context in which we intend to use it will determine many
of its features and requirements. If it is to be used in an urban setting for daily
transportation, it will be a very different car than a stock car to be raced on a
track, or a Formula One racer. The context will impose a different set of features
and services required from the car.
An important context: Usage
In MDSD, one of the most important contexts to consider is usage, that is, how a
system is used, and how it interacts with entities outside itself as it is used. Why?
Because our purpose is to develop a system, or enhance an existing one, one of
our most important considerations should be that the system is
useful. If we can
base our designs on the actual usages to which the system is to be put, we will
be assured that we build what is needed. After all, systems are built to be used!
Relating this to a set of services is fairly straightforward. The system will be used
through the services it provides. In fact, the usage provides context for the
services. How the system will be used, either by people or other systems, helps
determine what services the system needs to provide.
This dynamic—of describing a system in the context of its usage—might seem
completely obvious, but in our experience it is rarely done, or if done, is
minimized in importance. Most large systems are built based on requirements
written by teams of people with varying ideas and requirements, each with some
idea of how the system is to be used. Seldom is a unified and comprehensive
picture of the system’s usage created. Required features of the system are listed
and even elaborated, without being connected to actual usages.