System context: meaning, modeling and practical applications
Every development project has a system context. This is the part of a system's environment that is relevant for development. We should therefore also explicitly record it. This can be done with or without modeling. What exactly the system context is and how we can model it is the subject of this article.
The system context
The system context is a tool for communicating with stakeholders. It is therefore generally used to define and understand the requirements. The stakeholders are therefore part of the system context. The context also includes external systems (including the interfaces with which they are connected), as well as laws and standards.
Everything in the universe is interconnected by the laws of physics. However, most of it is irrelevant to our system and therefore not part of the system context. However, ever greater interconnectedness ensures that the context also grows, which can have a strong impact on the size of the context.
If we want, we can subdivide the system context even further. For example, we could introduce the application area outside the context, but this is not part of the context.
Modeling system context with UML
A system context does not have to be modeled formally. The famous "boxes and dashes" are sufficient for simple systems. However, it has been common practice for decades to model the context with UML modeling. The catch: UML is not actually suitable for this, because there is officially no context diagram in UML. UML context diagrams are therefore more like pictures, not formal models. In practice, we often find context diagrams "inspired" by UML, but these also work with talking pictures.
The effort of a formally halfway correct UML modeling is only justified if the model has an added value compared to the informal image. Added value is precision. However, this can only be realized if the team understands the notation well, thereby avoiding errors in communication. Another added value is automation, i.e. the machine processing of the model.
System context with SysML
In SysML, we can model the context with blocks. Basically, the procedure is similar to UML. However, with SysML we often also find methodical support that can ensure real consistency.
More than ten years ago, Tim Weilkiens wrote in his SysML book (and also in his blog) describes how we can describe the system context with blocks (shown in the box on the right).
Due to the further development of SysML, however, the notation is already outdated. Tim already recommends in the article that the actor symbol should no longer be used. He explains this approach in detail in the article The Death of the Actor.
Methods based on SysML have largely adopted this approach, such as the MagicGrid method (MagicGrid® Book of Knowledge).
Useful, but not a model: System Footprint Canvas
Particularly useful for brainstorming is the System Footprint Canvas. This is a system connected to the Business Model Canvas leaned Single pagewhich contains all information relevant to the system context:
- Value proposition
- Most important functions
- Most important components
- Most important use cases
- Most important product/result
- Most important stakeholders
- Technical framework conditions and Assumptions
- Most important stakeholder restrictions
- Interfaces
In contrast to the business model canvas, the order of these points on paper has no deeper meaning. In this respect, we can also simply use this list as a checklist when developing the system context.
The procedure for creating the system context is at least as important. I can recommend Markus Unterauer's approach in his book Recommend workshops in requirements engineering.
Conclusion
The system context is a simple but important artifact that should not be missing in any development project. It can be useful to create a formal context model. However, this only makes sense if the architecture is also to be formally modeled. In this case, we also need a method. And every method that is any good also provides specifications for context modeling.
A simple image is often sufficient for the system context if the aim is to sharpen stakeholder communication. It is then only important that all stakeholders understand the notation used.
