Start your system model with a context diagram

Domain and context modeling

Every system operates within a context, say, manufacturing, chemical process automation, or mission planning.

Every context exists within a domain. For example, mission planning could exist within the domain or spaceflight in the astronautics industry, or within the domain of battlefield in warfare.

Domain models and system context diagrams help establish the relevant conceptual space around the system under consideration. They serve a communication function that goes beyond technical details so that you can lead meaningful conversations with management and business decision makers when needed.

The context diagram

Building context for the system under consideration is a an important project-level step at the early stage of requirements formulation and gathering, a step that engineers and system modelers might be tempted to skip (and usually do.) Do not skip this step because it is your entry point into any present and future conversation with the non-technical community throughout the lifetime of the project.

It is a best practice in SysML to start a project with a context diagram in order to explain, in non-technical terms, the operational context for the system under development. By doing that, you are establishing a basis for conversation with various project stakeholders who are not involved in the technical aspects of building the system.

A domain model is defined separately and prior to a context diagram. For instance, the domain of battlefield is modeled in terms of a location of ground warfare, terrain, the point of contact between opposing forces, and the strategic importance of the geographical location. That domain model could be further extended to include "multi-domain battlefield" (*), which is the interconnection of multiple battlefield domains.

* “domain” in "multi-domain" is a battlefield concept, not the general notion of a domain used in this text, which is a sphere of activity, governance, or knowledge.

The diagram in Figure A is referred to as a "context diagram." It is modeled with an ibd. Note that the standard SysML notation for ibd properties is overridden with visually descriptive icons for the benefit of non-SysML consumers of this diagram.

The diagram itself is an ibd stereotyped with «ContextDiagram», which classifies what kind of ibd it is. The classification scheme is not normative SysML but one that is specific to your organization. This is considered to be a best practice in general. Look for industry standards that your organization conforms to.

Because the context diagram is an ibd, we must first create the bdd that it corresponds to.

Figure A — Context diagram for the Chemical Reactor