Problem Frames Approach - Describing Problems - The Context Diagram

The Context Diagram

The problem analyst's first task is to truly understand the problem. That means understanding the context in which the problem is set. And that means drawing a context diagram.

Here is Jackson's description of examining the problem context, in this case the context for a bridge to be built:

You're an engineer planning to build a bridge across a river. So you visit the site. Standing on one bank of the river, you look at the surrounding land, and at the river traffic. You feel how exposed the place is, and how hard the wind is blowing and how fast the river is running. You look at the bank and wonder what faults a geological survey will show up in the rocky terrain. You picture to yourself the bridge that you are going to build. (Software Requirements & Specifications: "The Problem Context")

An analyst trying to understand a software development problem must go through the same process as the bridge engineer. He starts by examining the various problem domains in the application domain. These domains form the context into which the planned Machine must fit. Then he imagines how the Machine will fit into this context. And then he constructs a context diagram showing his vision of the problem context with the Machine installed in it.

The context diagram shows the various problem domains in the application domain, their connections, and the Machine and its connections to (some of) the problem domains. Here is what a context diagram looks like.

This diagram shows:

• the machine to be built. The dark border helps to identify the box that represents the Machine.
• the problem domains that are relevant to the problem.
• the solid lines represent domain interfaces — areas where domains overlap and share phenomena in common.

A domain is simply a part of the world that we are interested in. It consists of phenomena — individuals, events, states of affairs, relationships, and behaviors.

A domain interface is an area where domains connect and communicate. Domain interfaces are not data flows or messages. An interface is a place where domains partially overlap, so that the phenomena in the interface are shared phenomena — they exist in both of the overlapping domains.

You can imagine domains as being like primitive one-celled organisms (like amoebas). They are able to extend parts of themselves into pseudopods. Imagine that two such organisms extend pseudopods toward each other in a sort of handshake, and that the cellular material in the area where they are shaking hands is mixing, so that it belongs to both of them. That's an interface.

In the following diagram, X is the interface between domains A and B. Individuals that exist or events that occur in X, exist or occur in both A and B.

Shared individuals, states and events may look differently to the domains that share them. Consider for example an interface between a computer and a keyboard. When the keyboard domain sees an event Keyboard operator presses the spacebar the computer will see the same event as Byte hex("20") appears in the input buffer.