Recursive consideration in systems thinking ​

If we consider the supra system of our system-of-interest as a black box, then it will be the target for the most important external project roles of the team. And the description of the supra system as a black box will be the concept of using their target system for these external roles, which for the team is the target.

When requirements were still made from the concept of use, this description was often called: stakeholder requirements (stakeholder needs, not to be confused with system requirements, system requirements, which are simply called requirements, omitting the word "system"). But in order to avoid confusion between this description of the supra-system-as-a-black-box and the descriptions of the target system-as-a-black-box, this description of the supra system as a black box is more often called needs (stakeholder needs, external project roles needs), and even more and more often they are called role interests or preferences. For example, we::team make a gear for a clock, that is, the target system of the team is the gears. Needs/needs --- for the clock::supra system, and the scenarios in the concept of use will be for the gear::"target system".

Thus, in the project, usually two "black boxes" are described in the concept of use:

• supra system --- described by the interests/preferences in some characteristics of the supra system important for external project roles (needs, stakeholder needs). According to the interests in the supra-system, there may be different preferences, we need to make a hypothesis about what values of characteristics will suit everyone and then not be afraid to adjust this hypothesis in the course of the project. It is necessary to start from the fact that the supra system is not just something "given in feelings", immutable, "descended from the heavens". No, the environment of the target system is also made by the creators, it also constantly changes, and it is possible to make hypotheses about how it should be arranged there. Modern engineering is based on the fact that you continuously adjust your understanding of the world, correct your knowledge about the situation of using the target system, knowledge about the possibilities of teams that create the supra system to adjust the environment of the target, knowledge about how to better satisfy the needs by modifying the target system so that it improves the work of the supra system. You need to take into account not only the various preferences of external project roles regarding the supra system as the environment of the target system, but also possible changes in these preferences.
• target system --- described as a "black box" mainly by gradually developing usage scenarios. Essentially, the same consideration as for the supra system, in ISO 15288:2023 this is called recursive application of systems thinking.

There are also described two "white boxes", one in the concept of use, and the other --- in the system concept:

• Supra system --- described primarily by the concept of use of the target system with an emphasis on the role/function of the target system in the supra system. It shows how the presence of the target system in the composition of the supra system leads to the satisfaction of the interests/preferences/needs of the external project roles. This is the important "device of the supra system" for us, the white box. The concept of use is to some extent a concept of the supra system (recursive application of systems thinking! The same thing happens at every level). with precision sufficient to describe the target as a black box, performing some functions in the supra system so that satisfaction of the interests of external project roles becomes understandable. For wall clocks, the supra system is the interior and people inside, you need to describe what surrounds the clocks and how they interact (for example, does the loud ticking of the clocks bother people at night).
• Target system --- described by the concept of the system, including architecture as additional solutions for constructing the system (with the expected impact of architectural solutions mainly on architectural characteristics/"concerns", not functionality). Of course, the system concept and including architecture shows how the interests of not only external project roles (their interests are more described by the concept of use) are satisfied, but also internal/project roles, that is the interests of visionaries, developers, architects, engineers of the production platform of the target system. For example, for clocks with a specified level of precision in their outer limits, decisions need to be made regarding their internal structure: will precious stones be used in the clocks to reduce friction and thereby increase accuracy, or in wall clocks, is this a luxury, will the required accuracy be achieved simply by using hard alloys for the gears and pallet forks? Or maybe wall clocks will not be mechanical at all, but electronic, to achieve the required accuracy.

In the diagram, the target system and its subsystems are shown with red circles, the "part-whole" relationship is shown by the circles entering each other. The environment --- blue circles, the nearest supra system --- a large blue circle, into which the target system and several other systems enter. Of course, there are still some systems in the environment that are not included in the composition of the supra system. There are many system levels inside the boundary of the target system and outside the boundary of the target system.

External project roles during usage time are shown as blue stick figures, but these are not people. These are roles that can be played by people, people with computers, teams, and companies with all their people and equipment. In terms of operations, such external roles, for example, "users", are shown in circles to emphasize that they are also systems in the environment (a role is a role-playing object played by some agent as a constructive object).

During the creation time (construction time), system creators::system, we simply do not draw circles and their nested/internal parts.

On the entire diagram, the relationships of creation (between the right and left parts of the diagram) and interactions between systems of the same level in their work (between circles of the same level) are not shown. The fact that systems can be divided into parts in very different ways (for example, functionally and constructively: like a spoon --- "handle" and "bowl" will be two functional parts of the spoon, but the constructive part of a solid or even wooden spoon will be a single "detail" constructively created), is also not shown, although in the system concept, the multitude of coordinated different types of descriptions within one system description will be fundamental. Usually, different options of coordinated decompositions are considered (including placement, pricing decomposition --- what will be manufactured in the system and what will be outsourced). And then, out of all the coordinated variants of different decompositions, only the "least bad coordinated variant" is left, because the "best option" is unattainable in evolution --- only a local optimum can be achieved.

It is important for this illustrative diagram that "blue" external roles at creation and development time are engaged in the arrangement of "blue" (supra system) on the diagram, but "red" is for them --- a "black box". And "red" internal project roles (project team roles) are forced to first investigate "blue", but then move inside "red", that is, first consider the environment of the "black box" as the nearest supra system (a "transparent box"), and then make the "black box" transparent --- to formulate hypotheses not only about the functionality of the target system as a black box (concept of use), but also about the construction (system concept, including initial architectural decisions).

The project team creating and developing the target system creates its concept. When creating the concept, they usually start with a description of the functional breakdown, gaining an understanding of what is happening inside the system in terms of subsystem roles (subsystems as role/functional objects), as well as subsystem functions. For example, "to show the time on the clock when looking at it at night, we will make constantly glowing hands, this won't be visible during the day, but at night everything will be fine" or "to show the time on the clock when looking at it at night, we will provide that when the surrounding light level drops, the illumination will turn on", or "to reduce the cost of the clocks, we will not consider that they will be viewed at night, if really necessary, let them put some kind of room lighting to illuminate the dial". These descriptions will be the concept of use of subsystems (recursive application of systems thinking! At each level, the same thing happens), and the subsystems themselves will have to be designed, to invent methods of manufacture and materials, from which these systems will need to be made (you will have to find affordances that will become the constructs of the system). For example, in the "clocks at night" example, you will need to invent what to make the dial illumination --- LEDs, incandescent bulbs, phosphors. Some will be suitable (an affordance is a "suitable thing"), some will not be suitable to perform the expected function of the subsystem in the target system.

Systems thinking is recursive, it is applied in the same way at each system level, by each system creator team. And each team has its "system coordinates" around its target system and also "their systems", so the most important thing is to agree on what these systems are! By defining it, primarily by describing the system's behavior in relation to the supra system, often beginning from the top levels!, trying to describe the system as a "black box", so that later various options of arranging this system can be tried, that is, considering different system options as a "transparent box"** (down through the levels --- later!).

In the section, we explain the recursiveness only in the example of two levels (system-supra system), but this recursiveness is used at all levels --- for a system with subsystems, subsystems with sub-subsystems, and so on to system elements, and for supra systems and the environment of the supra system, also for many levels. At all levels around any system, a complete system view can (and even must) be unfolded, roughly in the same way as it is unfolded around the target system.

Systems thinking says that the concept of use (previously --- needs and requirements) describes two different systems (supra system as a "transparent box" and the target system as a "black box"). However, methods/ways of how to effectively identify conflicting (different interests!) roles of engineers of the target system (visionaries, developers, architects, production platform engineers/internal development platform engineers), engineers of the system creating/managers (businessmen, organizers, org-architects, administrators), and add different roles from other project-involved areas, agree on them in collective thinking, and agree with each other within the framework of collective thinking, creating systems.

There are no "applied projects" of a particular orientation to which systems thinking would be particularly useful, and for others --- not particularly useful. Systems thinking is universally applicable: it is used in projects::"team behavior to achieve results," and in formulating project goals, essentially --- formulating the project's system-of-interest. For instance, systems thinking works well when making decisions when starting a business, when it's still unclear what specific system-of-interest the team will be creating (what the market hypothesis is), so the teams are usually not yet formed --- and the task is set for business engineering from scratch ("business engineering" which includes proposing a business model), which will already deal with the technical system (hardware or software) design, developing an initial vague concept of what the system could be.