Functional descriptions: circuit diagrams, use case diagrams, scenarios
Among the many project roles, the area of interest of a lot of them includes important characteristics of the system's operations time, when the system is ready and is being operated, in run-time/operations. Explaining how the system works (i.e., describing the causes and effects in subsystem interactions) can be done using functional descriptions. In them, we explain the purpose (function) of each part of the system and the contribution of this part to achieving the overall purpose of the system, the general behavior of the system in its environment (run-time).
Circuit Diagrams are diagrams showing connections of functional parts with each other and are convenient for explaining the principle of system operation (answering the question "how does the system work" - how functional parts interact with each other to provide the required external functionality of the system as a whole). Here are a few typical examples of circuit diagrams:
(The text refers to the provided images of circuit diagrams which are not visible in the text, but could be referred to in the translation)
During the operation/functioning of the system, the functional parts of the system interact with each other through flows, passing through the ports of these functional parts. In circuit diagrams, functional parts are usually depicted using graphical elements of different shapes, and flows are represented by lines between these graphical elements. A port is the point of connection of a connecting line to the graphical element of a functional part.
In a computer as a slide source, there is a port for connecting a slide projector, and through this port, data for the slide flows to the projector. This is what we call a functional description, as shown on the diagram. In the physical world, we would see the constructive part of a "laptop" with an outdated USB interface through which the projector is connected with a cable. The constructive (physical) laptop implements the functional source of slides, and the physical projector implements the functional slide projector, the cable implements the connection between the slide source and the projector, and the interface implements the interport connection. Here, "implement" means that the constructive (physical) object performs the role of a functional object. Functional descriptions usually include terms from the subject area ("presentation," "slides"), while these terms are not present in the constructive description. A hammer and a microscope do not know that they will be driving nails, so the description of their purpose does not include terms related to nailing, just as in the subject area of computers and laptops, there is no mention of "slides," but a slide projector can contain such a word if it is specialized for showing slides or may not contain this word if it can also show videos.
Functional parts are physical, they are selected for the system in such a way that it is easy to explain the system's operation during its operation (run time, operations). Flows are most often logical/role/functional objects, which are also physical, through which functional parts mutually influence each other. These flows can be light flows, electric current, energy-mass transfer (in thermal machines), or even data (in software systems).
In any case, we always translate our thoughts into the physical world but remember that circuit diagrams depict a functional flow, not the physical object serving as a conductor of this flow. For example, electric current can flow through a wire, through a casing, through a bolted joint, but this diversity of media will not be depicted in a circuit diagram. It is not necessary to have the exact number of wires shown on the schematic in an electrical circuit. However, between the products/modules implementing the functional parts, the current must be able to flow for the system to work; a "wire" is simply one of the ways of implementing the flow/connection/link/interaction.
Similarly, a "pipe" in a hydraulic diagram is just one way of implementing the interaction—constructive parts/modules playing the role of functional parts of the system can be directly connected, flange to flange, without a pipe, or instead of a pipe, the liquid can flow through a ditch; there are countless variations. The main thing is that the diagram shows connections of functional parts with each other in a way that the interaction through the transmission of substance or energy or data can be traced. In the end, the data will also be physically transmitted through the transfer of matter, for example, transporting a truck with magnetic disks or energy, for example, through fiber optic communication, or through electric current between computer parts.
Remember that functional descriptions can show not only functional/role parts of the system but also directly the behavior/functions of these parts—and this behavior will also be carried out over flows. Typically, we speak about entry (input flow), processing/function/process (transformation of input flow into output), and exit (output flow). In this case, we talk not about circuit diagrams but about functional diagrams, process descriptions.
Here is an example of such a functional diagram (function model): [Link to an image of a function model diagram]
These functional descriptions can also depict scenarios (use cases), sometimes referred to as usage scenarios. This is illustrated by the action of active parts of the system represented by figurines. In the image, these are project roles, but in reality, they could very well be functional/role parts that are not played by humans. In these diagrams, the "Aristotelian physics" is used (the finger presses on the table, but the table does not press on the finger), showing actions rather than interactions—functional elements are denoted by human figures/roles/actors, and their actions (functions) are modeled by separate elements on the diagram, reflecting "logical" scenarios (not in physical time! In a cause-and-effect sequence of explaining what is happening) such as actions performed by functional elements/roles/actors. Here, actors can be non-living entities, not "agents" making decisions. However, when we refer to an "actor" in the course materials, we imply that it is a part of an agent playing roles. What is called an actor in a use case is not necessarily an "executive role" but rather precisely a role, and not necessarily with agency (i.e., without free will, without decision-making capabilities—similar to how a hammer in nailing will also be an actor). Always remember that words in language are limited, and each word has many different meanings, and terms like "actor," "актор," "актёр" may refer to different concepts in different disciplines and practices, even though sometimes they may seem indistinguishable.
The modes of operation/functioning of a system are usually calculated based on functional descriptions because they are connected to the system's operation time and not its creation time. Multi-physics modeling is done precisely for functional descriptions: optimal characteristics of functional objects are sought for given operation modes. Of course, the system is modeled in its environment (as it is run-time/operation-time, and the system's operation significantly depends on the state of its environment).
Sometimes the discussed functional diagrams are further complemented with purely process diagrams, where the objects themselves are the functions/behaviors, depicted by verbs or verbal nouns such as "transporting," "cooling," "lighting." Process diagrams are less common than circuit diagrams with functional objects as elements of the diagram, not the behavior of functional elements as in process diagrams. For example, a process diagram may show the behavior of "increasing fluid pressure," while a circuit diagram will show a "pump" (an "object-increaser of pressure," not the action of "increasing pressure").
Certainly, it must be remembered that most descriptions in real projects are "hybrid"; people can elaborate in diagrams, tables, and texts to specify that the function of increasing fluid pressure is realized by a pump module, not by a height difference module, or even explicitly state the brand and technical specifications of the equipment that needs to be procured!
The main problem with functional descriptions is that they are usually only understood by narrow specialists, and the functional/role/functional division of the system can be counterintuitive. If you are asked how a system works, you cannot do without at least a simplified circuit diagram or process diagram. Be prepared for such questions: after all, systems are made to work, and most people are interested in how they work—and only after explanations on this topic can you discuss how the system is made.
Systems thinking does not teach you how to read and build functional descriptions and document them. Systems thinking says that functional descriptions should be made (and documented!). How to create functional descriptions (with functional decomposition) and then how to do modular synthesis (making decisions on which modules will realize which functional parts) is what systems engineering teaches. And if you want to become a professional, you will also need to study the applied discipline specifically associated with some engineering practice (for example, study a couple of textbooks that explain use cases and how to use them in projects for creating models of use).