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.
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.
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.
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.
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:
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.
- name (identifies the cookie)
- id (identifies the unique visitor)
- 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)
- reporting preferences
- 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.
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.
Feel free to leave your questions, comments or suggestions below. I will get back. Subscribe for more.