The central responsibility of the systems engineer is matching the results produced by the solution system with the stakeholders’ requirements. The International Council on Systems Engineering (INCOSE) clearly defines the job of the systems engineer as “. . . ensur(ing) that the customer and stakeholder’s needs are satisfied . . . “ in a way that brings to bear a high quality solution “throughout a system’s entire life cycle.” The system referred to here is the one created or modified to provide the solution. It is, therefore, the job of the systems engineer to create a solution system (or modify an existing system) such that the results produced by the system act to meet the customer and stakeholder needs.
Performing that job requires the systems engineer to understand two things in a deep and rigorous way. That understanding is what we call “insight,” and for the systems engineer that insight must extend both to the requirements and the system results. Having that two-pronged understanding is critical because the systems engineer must match the two to effect a solution. The solution systems results must satisfy the requirements.
Much has been written on the road to insight into the requirements. Design teams must establish a sound process for eliciting and stating the requirements. That process is the key to requirements insight. But it is the other insight that is the subject of this article.
The systems engineer must take the insight into requirements and match it with the other insight – the understanding of the system results that will satisfy those requirements. To understand the source of the understanding of system results we turn to the nature of systems.
The INCOSE definition of a system reveals that fundamental nature. According to that definition a system is “a construct or collection of different elements that together produce results not obtainable by the elements alone.” There are three aspects to that description.
First, a system is composed of “different elements.” A single element cannot compose a construct or collection. The composition from different elements is a critical aspect of the nature of a system.
The second aspect of a system is that it is a construct or collection. This implies a rationale or intentionality. The different elements are not just randomly aggregated. They are related to each other. The structure of the construct holds the system elements in relation to each other.
When the different elements are held together in relationship as defined by the system construct they produce the third aspect of a system – “results not obtainable by the elements alone.” The particle physicist turned biologist, Fritjof Capra, observes that the system results (which he calls “properties”), “arise from the interactions and relationships among the parts.” The vantage point from which this is visible is called the “system view.”
In order to satisfy the customer and stakeholder requirements the systems engineer is charged with gathering the “different elements” and assembling them into a construct that will produce the desired requirements-satisfying results. This obviously requires that the systems engineer understand the elements and the structure in order to obtain the right results.
The understanding (insight) required is generated by the application of systems tools and methods by the engineer in the context of the problem space. To be useful, the engineer’s methods and tools must enable understanding of all three aspects. That requires that the elements and structure of the solution system be clearly seen in the tools and methods. Only in that way can the system results be understood.
Using tools and methods that allow a systems view, the engineer can make informed choices regarding the elements and structure and from them predict the results that will emerge from the design. It is by making those predictions and adjusting the elements and structure that the engineer can match the results to the requirements and create the optimal solution for the customers and stakeholders.
The system view is crucial to system insight. That view is the foundation of the system engineer’s ability to shape and predict the results of the solution system and match them to the requirements. Without the system view there is no system insight and without system insight there is no solution.
