Skip to content
Create an account for full access.

Description formats of system levels

System levels consist of a hierarchy in terms of part-whole/composition relationship. These hierarchies are convenient to represent graphically as a graph-"tree", similar to the one we just discussed in connection with naming systems in relation to the target system. For illustrative purposes, this is suitable, but not for work. Graphic models are extremely inconvenient to edit and modify. When developing system breakdowns and coordinating them within the project team, you will need to quickly (this is key) change the options for system breakdowns. To do this, we suggest using an "outline", a textual representation of a hierarchy tree, where each level is represented by an indent.

Here is the previous picture as an outline, the same numbers are indicated as on the picture:

  • Supra system (1)
    • System in the environment
    • System in the environment (3)
    • System-of-interest (2)
      • Subsystem
      • Subsystem (4)
      • subsystem

Of course, these namings (like any terminology) are more or less arbitrary. For example, in TRIZ, the supra system is called as is, while English-speaking systems engineers do not usually use the word "supra system" (very rarely non-engineers say suprasystem, but not supersystem), although they do use "subsystem".

In the foundational standard of systems engineering ISO 15288:2023, there is no mention of all these types of systems, emphasizing their sameness: only the system-of-interest is distinguished as the top of the system breakdown. "Higher up the system levels" there are immediately "systems in the environment", which are considered separately, including the supra system itself. In the context of the system-of-interest in this standard, there are only systems (if these systems have parts) and system elements (if the decision has been made not to consider their parts, but only to limit themselves to the existence of these system elements as wholes, which are parts of their supra system).

Let's present this picture as a multi-level list/outline, translating it into English at the same time:

  • System-of-interest
    • System
      • System element
      • System element
      • System
        • System
          • System element
          • System element
          • System element
        • System element
        • System element
    • System
      • System element
      • System element
      • System
        • System
          • System element
          • System element
        • System element
        • System
          • System element
          • System element
    • System element

The picture and the text here are approximately equally clear because very few elements in the system breakdown are presented. Now imagine that you need to depict 500 elements (scale of the problem: in an airliner or an ice drilling platform there are 5-6 million elements). The diagram-picture will immediately only fit on many pages that are difficult to compare with each other, it will not fit on any computer monitor, and if it is split into parts, it will be completely unreadable. Edits in this diagram will be very time-consuming and many edits will lead to mistakes.

The text version with the outline is easy to edit, it can easily be stretched into a "long text" (people are used to working with multi-page texts, using scrolling), long names fit easily on one line (and you can even provide comments!). So, for working with system breakdowns, use outlines/nested lists.

An alternative way is to use explicit level numbering as a separate list item. Here is the same structure as in the previous list, but presented in tabular form (for example, an Excel table). The system-of-interest as a whole in our representation does not have a code, and the number of positions in the code is the system level (1.3.1.1. - this will be the fourth level if the system-of-interest is at level zero. Unfortunately, in the ISO 15288 standard, there is a numbering error in the diagram, the fourth level is shown as the fifth!)

| System Code | System Name        |
|-------------|--------------------|
| 1.          | System             |
| 1.1.        | System element     |
| 1.2.        | System element     |
| 1.3.        | System             |
| 1.3.1.      | System             |
| 1.3.1.1.    | System element     |
| 1.3.1.2.    | System element     |
| 1.3.1.3     | System element     |
| 1.3.2.      | System element     |
| 1.3.3.      | System element     |
| 2.          | System             |
...

Of course, in this table example, "system" and "system element" are types (from the meta-meta-model, types of important objects of the system approach) of those objects that will be specified in such tables or as types of the meta-model "from the domain textbook", or even as types of the enterprise meta-model, or even for a specific instance of a system - as names of specific physical objects. That is, the table will not contain "system", "system", "system", but for a car "chassis", "left wheel", "engine", for a sailboat "hull", "mast", "mainsail", etc.

Each time, convert graphic representations into hierarchies, and then represent hierarchies in tables - otherwise you will not be able to cope with maintenance, you will not be able to make numerous changes. Formats should be convenient not for "presentation" but for changes: descriptions of systems (including descriptions of system breakdowns) are the subject of continuous discussions in the project team, and therefore - the subject of continuous changes. Formats are tailored for ease of changes, all kinds of "clarity" of simple examples "from the textbook" and "from the standard" should not distract you: you don't need to change textbooks and standards, you don't need to split images from them into multiple pages. Use tabular representations (including for working with system breakdowns), it will be convenient.