System ContextWhat 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?
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).
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.