The system context defines the system boundary and all system actors – humans and external systems – that interact with the system under development. It is one of the most important parts of the system model. Many artifacts of the system specification and architecture are relative defined to the definition of the system. Every system behavior and structural element is completely inside the system and not covered by any system actor. If you change the system boundary, you must also change the behavior and structural description and the interfaces of the system.
I distinguish between the simple and the extended system context. The simple system context is more or less only a list of system actors. The extended system context adds description of the interfaces and internals of the actors and the system itself. I’ll publish a post about the extended system context in the near future. This post focuses on the simple system context.
The figure shows a simple system context of a forest fire detection system. It is a SysML use case diagram and shows the system itself and the system actors.
The system is a SysML block with stereotype system. Here the system actors are SysML actor elements with stereotypes to specify the different actor categories like external system or environmental effect. Instead of using the actor element you can also use the SysML block to define actors (see Death of the Actor).
Consider the base architecture when elaborating the system context. Be careful to clearly separate the requirements from the technical solution on the same abstraction level (see also SYSMOD zigzag pattern).
3 Best Practices for the Simple System Context
- Never skip the definition of the system context.
- At least distinguish between human and non-human actors.
- Use the SysML block instead of the actor element to model system actors if you plan to move the system boundary or to integrate your system model in a system of systems model (see Death of the Actor).