Home
Smartpedia
System Context

What is the System Context?

Smartpedia: The system context determines which systems and interfaces must be considered for product or software development and which are irrelevant.

System context definition

The system context describes the interaction of a system with its environment. The definition of system and system boundary, as well as relevant and irrelevant system environment, is important because it defines the aspects that must be taken into account during development. Laws, standards and guidelines must also be taken into account when assessing the context boundaries.

With the system context, you determine who and what influences a system to be developed. By determining this, you define the scope of the development. If this scope is missing, requirements may remain incomplete or requirements may be raised that go beyond the actual scope of the development. This results in problems, effort and costs that can be avoided by clearly defining and delimiting the system context.

The delimitation answers three questions:

What is to be developed?
Which other systems, interfaces and rules need to be taken into account during development?
Which other systems, interfaces and rules do not need to be taken into account during development?

System context terms

In this simple representation, you see system 1 to be developed and systems 2 and 3 to be considered during development (each in white).

The border of system 1 is the so-called system boundary. The system boundary separates the planned system from its environment and thus separates the changeable part of the development from aspects in the environment that cannot be changed by the development process.

The dark light blue area stands for the system context, which we consider accordingly in our project. The system context boundary separates the relevant part of the environment of your planned system (dark blue) from the irrelevant part (light blue), i.e. the part of the environment that has no influence on the requirements of your system (here systems 4 and 5).

System Context - determining the scope of a development

Goals of system context analysis

The aim of system context analysis – sometimes simply called context analysis – is to determine all of the

relevant persons (e.g. stakeholders),
processes (e.g. business processes),
systems (for example, external systems with which the planned system is to interact via an interface),
events (e.g. the replacement of an existing, different system), and
documents (e.g. laws, norms, standards).

The System Context is the part of the environment of a system that influences the system and is relevant for the collection of requirements. The system itself cannot influence the system context, it must adapt to it.

Context analysis challenges

In the scope of system context analysis, there are two challenges in defining the system context:

Not all information is available for evaluation.
Decisions on how to assign information are missing.

Not all information is always available at the start of the project. It could be that not every standard to be observed or every future legal change is known to the project participants. The classification of information in terms of system, system context or irrelevant environment often depends on management decisions. So-called grey zones emerge. It is important to eliminate these as early as possible in order to avoid later problems, efforts and costs.

System context diagram

When developing a system, it is not sufficient for only the software architect to see the system context in his mind’s eye. The system context should be documented and made accessible to all project participants. Various diagrams are available for documentation purposes: With a system context diagram – sometimes also referred to as a context diagram – from the “structured analysis” you can record the system environment in an early design or analysis phase. It is an abstract data flow diagram that you can use to map the system’s interfaces to its environment. Alternatively, you could use an use case diagram or a composite structure diagram of the Unified Modeling Language (UML) or an internal block diagram of the Systems Modeling Language (SysML).

Definition of system and system boundaries

With the definition of system and system boundaries, companies create a common understanding for the development of a solution. The entire project team benefits from this understanding. It does not pursue requirements that lie outside the context. At the same time, however, it can consciously record information that lies outside the context, because this is the only way to ensure that no one deals with the same irrelevant aspects again and again. Ideally, grey areas should be identified and eliminated early on. This makes it easier to identify requirements and to design a suitable software architecture. This saves companies time and money.