IBM SG24-7368-00 manual System in context, An important context Usage

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.

Chapter 3. Black-box thinking: Defining the system context 37