The whole of systems engineering is based on the use of a small repertoire of elementary, underlying processes (1) which can be applied repeatedly and at multiple levels in the system development, in order to bring about closure between stakeholder needs and a developed system which satisfies them. Not all processes produce tangible product; as the discussion below makes clear, some processes - especially those in the early stages of system development - deal only in information.
Real systems engineering processes on a project may themselves become very complex and inter-related. However, they all derive their underlying meaning from a number of simple paradigms which depict the elements of process in stylised form. The basic form shown in Fig 1 has on the top left the analysis of the needs of users and other stakeholders, which are expressed in the User Requirement Document (URD). Further systems engineering work will lead to a logical, or functional, model of the system to be built. Along with technical constraints and interfaces with other systems, this information forms the basis for the Systems Requirements Document (SRD).
In order to express the design (or designs) in high-level terms, and explore options and evaluate performance, systems engineering requires the development of a systems architecture. Put simply, an architecture allows us to view the outline of the solution, and evaluate the implications of its realisation at an early stage, and well before large sums are expended. It also becomes possible to check the conformance of the potential solution options with the requirements, and to assess the overall emergent properties of each option with respect to those of their components. The architectural design document (ADD) forms the basis for the technical integration of the product.
Figure 1 Basic Systems Engineering Processes
The URD, SRD and ADD together form an important triad - a trade-off triangle - which must be traversed a number of times in the development of the product. Put simply, the content and purpose of each can be expressed as follows:
In addition, there are matching processes at the right hand side of the figure, which are:
The advantage of this basic model is that it depicts the relationships between the different elements of process. Although they might in practice be applied in a very intricate manner, the basic properties described here are usually preserved. (There is an analogy to be struck with music: we learn the rudiments through scales, chords and rules of harmony. An experienced composer can take these pieces as building blocks, and compose a vast orchestral creation, which weaves them together in intricate patterns. Doing so clearly requires competence, which is usually only acquired through experience.)
It can be said that systems engineering is concerned with conducting sufficient activities, particularly at the early stages, that eventual integration, build and assembly will be as simple as possible, with a minimum of re-work and nugatory effort. It is impossible for this to be achieved with any degree of assurance in a single pass through the sequence of processes. There are a number of underlying reasons for this, for example:
All these reasons and more underpin the necessity for feedback and iteration.
(1) A process can be defined as a set of actions that receives information or material input and operates on it in a specified manner to produce an information or material output.