I came accross a very nice technique that can be used to show the scope of a project.
It is called the Context Diagramme.
The idea is that the system is shown as one item. The internal structure within the system is not displayed. Instead the diagramme shows the interaction from the system with external interfaces. The end result is an overview where the external interfaces are displayed clearly with the type of interaction that they have with the system. The nice thing is that a graphical overview is given of the project that can be used for discussion with the end-user. In that discussion, the boundaries of the system will become clearer to all. Moreover, the external interfaces will be made explicit. As the end-user will be involved in discussions on these external interfaces, it is good to be able to inform him upfront on these interfaces and why they are needed.
If the external interfaces are listed explicitly with their interaction with the system, the scope of the system can be made clear. The system should be able to deal with all stimuli and data that stem from the external interfaces. In other words: the system should be able to consume the datastreams, or generate the dataflows that are indicated by the diagramme. Such streams are shown explicitly in the diagramme. The scope should then include all handling of such streams. In principle, the scope is indicated by the circle in the middle of the diagramme. The external interfaces are outside the scope. Whether the arrows between the external interfaces and the system are within scope is subject of negotiation between the project and others that are responsible for the interfaces.
Such a context diagramme uses three types of symbols:
- A circle that contains the system. The system is understood as one entity where the internal working is not displayed.
- A block that displays the external party. Think of customers as an external party.
- An arrow that shows the interaction between an external interfaces and the system.
The external interfaces can be manifold. Let me give a few examples:
- Users that actively use the system. An example is a user who issues an order to the system. Likewise, a user who required a certain report is an example of an external party.
- Users who depend on the system. An example is an accountant who receives a certain plan that is created by the system. The user doesn’t explicitly require such a plan; he only receives such a plan.
- An independent body who influences the system. One may think of a body that issues standards that need to be followed. Such standards may influence the system that is described in the diagramme.
- A system that sends data to the system. The system may have a role as data-provider. In that case the external system doesn’t benefit from the system that is described; it only must provide data.
- A system that cooperates with the system in question. An example might be an internet provides who provides the infra structute that is used by the system.
But one may also think of abstract types of interfaces, such as:
- A time dependent event, such as the end of a month when sales overviews must be provided.
- An event, such as the introduction of a new product.
The relations are mostly expressed as datastreams. As an example, one may think of a request for a report. The data that are conveyed to the system are: a reportindicator, a period for which the report is generated, a possible filter condition etc. The idea is that these diagrammes are mostly used for software engineering and communication between actors can always described with data.
This diagramme will be used in the discussion with the end-user. Hence the language that is used must be business terminology. Hence, system names should be avoided as such usage may lead to unnecessary discussions. It is better to use business names for the interfaces involved as the picture can be understood more easily.
I took the example of a data warehouse project. This project uses Balance Sheet data, Profit & Loss data, Inventory data and Cost data that are uploaded on a monthly base to a data warehouse. From that data warehouse, data are sent to external systems and the data that are used in a reporting environment.
The workpackage is above diagramme consists of collecting and storing data. The reporting environment is outside the workpackage. Hence the interface reporting (O2) is displayed outside the circle W1.
If reporting is part of the workpackage, the diagramme must be changed into:
In this diagramme, the work package W1 consists of reporting as well. The external interface is then directly with the end users who send paramters and receive reports.
This context diagramme is often seen as part of an hierarchy. In a related diagramme, the circle that indicates the system is detailed. In that related diagramme, the internal working within the system is shown. When such a hierarchy is used, the context diagramme is labelled as level-0 Data Flow Diagramme. The diagrammes that show the internal workings of the system are labelled as level-1 or level-2 Data Flow Diagrammes. In the example above, I labelled the items to allow later decomposition. As an example, in a level-1 Data Flow Diagramme, one might have P1.1, P1.2, P1.3 that are part of the P1 process.
More or less the same holds for time-depencies. The context diagramme cannot be used to indicate time dependencies. For that purpose, other techniques can be used, such as sequence diagrammes. If one would like to show the time-depencies, the context diagrammes could be expanded into sequence diagrammes.