A helpful approach to begin the analysis and design of a system is by creating a context diagram. Doing so provides a high-level view of responsibilities of the system in its environment and the way the system integrates into the problem space. A context diagram is also a helpful tool for communicating the purpose of an existing system to another person.

What is System Context

System context is the environment in which the system operates.

A context diagram is a graphical representation of the system operating in it’s environment.

Here’s a generic context diagram to illustrate the definition.

A generic system context diagram

On this diagram the system is the thing we are going to build. Data source, user and data store are parts of the environment or context.

As you can see, the system receives input from a source, moves some processed data into a data store and provides some output in the form a view to a user.

The data moving between the system and it’s environment is also within the scope of the context diagram, as it’s part of the integration contract between the system and the environment.

Define the System’s Boundary

The first step to context analysis is defining the boundary of the system. For simplicity we assume that all external entities in the context are fixed (which is often the case). This means their inputs and outputs are predefined, and their design is outside of our scope of work.

As an example let’s say we are designing a web analytics platform (think Google Analytics). According to the requirements it should track site visits and provide management tools and reports to site administrators.

A system and it's environment

In this case, for the purposes of context analysis, the system boundary can be defined as a set of all software components, responsible for achieving the requirements. This would include tools for tracking, reporting and data storage, but not the actual sites we will track, or the visitors.

Specify External Components

Knowing what is within the system’s boundary, we now can add all relevant external components to the picture.

We know that the system is going to track site visitors, so the visitor should be reflected on the diagram somehow.

There will also be administrators and a piece of tracking code embedded into the web-site.

Adding external components

Isn’t the tracking beacon code a part of the system, according to our definition of system’s boundary?

It could be, but hiding it behind the boundary would obscure the integration between the browser and the system, which is valuable in this context. Besides, the tracking code can be seen as a non-essential part of the system. The platform can work without the beacon - if the website calls the analytics API correctly. The beacon exists only to make the integration between web sites and the platform easier.

Discover the Flow of Data

Now we can analyze the interaction between all components we’ve identified earlier. We present the results of this analysis as named data flows on the context diagram.

At this point our context diagram becomes a data flow diagram.

Complete context diagram by adding data flows

A data flow is a piece of data moving from one component or process to another. It’s irrelevant at which point of time the flow occurs or what event initiates it. What matters is the direction of flow and the type of data.

The goal of a data flow diagram is to make it clear how the data is transformed when it moves between different components of the system. At the same time, the data flow diagram omits unnecessary details, such as flow control and data transfer mechanisms.

It’s important to understand that a data flow is a higher-level abstraction compared to a procedure call or an event.

As a result of data flow analysis, we can see that our system’s responsibility comes down to two data transformations:

  • visit notifications and configuration into tracking cookies
  • visit notifications and configuration into reports

This already gives us a hint that in the future it might make sense to decompose the system into at least two smaller components, each one handling it’s own responsibility (tracking and reporting). While further decomposition is outside the scope of context analysis, this example illustrates how analysis outputs can drive design decisions.

Analyse Data Types

Since we know that our system’s purpose is to transform data (which is the case for almost any other software system), it makes sense to look more closely at what the data is made of.

To do this, we take each piece of data (data type) from data flows and specify which conceptually-distinct elements it contains.

  • tracking cookie
    • name (identifies the cookie)
    • id (identifies the unique visitor)
  • visit notification
    • tracking cookie (if exists, identifies the unique visitor)
    • tracking id (identifies the web site on which the visit occurs)
    • tracking properties (such as page URL, browser locale, user agent, and so on)
  • configuration
    • reporting preferences
  • report view
    • a view of audience and traffic metrics for a given web site

Note: no need to go into detail with specification of reporting preferences - different preferences represent essentially the same concept. At this abstraction level there’s no value in knowing exactly which preferences we will have. Same with reporting metrics.

Moving on

Hopefully, now we understand the problem domain and the system much better. This means we can move forward with deeper analysis techniques, such as use case specification and domain modeling.