System Context

What is the System Context and what are the goals and challenges of System Context Analysis?

System Context Definition

The System Context describes the interaction of a system with its environment. For a system to be developed, it is important to consider the System Context, because by defining the system and system boundary, as well as the relevant and irrelevant system environment, you define which aspects are to be taken into account in a development. Laws, standards and guidelines must also be taken into account when assessing context boundaries.

Determining the System Context

With the System Context, you determine who and what influences a system to be developed. You use this determination to define the scope of the development. If this scope is missing, requirements can remain incomplete or requirements that go beyond the actual scope of the development can be imposed. As a consequence, problems, efforts and costs arise which can be avoided by a clear definition of the system context.

The delimitation of the system context answers three questions:

  • What is to be developed?
  • Which other systems, interfaces, rules have to be considered during the development?
  • Which other systems, interfaces, rules do not have to be considered during development?

 

System context with boundaries and irrelevant system environment

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 blue). 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 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 (light blue) from the irrelevant part (grey), i.e. the part of the environment that has no influence on the requirements of your system (here systems 4 and 5).

Goals, Challenges and Presentation of the System Context

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

Challenges for companies

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 will find additional information from our Smartpedia section:

Smartpedia: What is a Goal Diagram?

What is a Goal Diagram?

Smartpedia: Which types of Structure Diagrams exist?

Which types of Structure Diagrams exist?

Smartpedia: What Behavior Diagrams exist?

What Behavior Diagrams exist?