What is the System Context?

The Terms in the System Context

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).

The Goal 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.

The 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.

Notes:

Here you can find a video about System Context and System Boundary in Requirements Engineering.

Here you will find additional information from our Smartpedia section:

What does t2informatik actually do? One click and you'll know.