The alternative response is:

I wouldn't like to say which is worse; it seems no better to deny that I'm in Mech. Eng. than to assert I'm not a programmer. Partygoers know some trades – doctor, plumber, lawyer, engineer, carpenter, programmer – and not others.

Systems Engineering is, of course, a relatively new term, but it stands for a task that has existed as long as machines and civil engineering projects: the Romans were superb engineers, and examples such as their majestic aqueducts continue to grace Europe today.

As a discipline, Systems Engineering is quite young. As a discrete group it is hard to locate, since most of its members necessarily graduated in something else, and practise skills ranging from aeronautical engineering through electronics and other types of hardware to software and requirements.

What is this thing that embraces project management, soft systems methodology, hardware, software, specification, testing, and configuration management, among others?

It is a discipline of organisation and control, but from the point of view not of project management but of engineering a system as a whole.

A project manager is concerned primarily with cost, and hence with risk: risk to schedule and budget, and eventually also with quality, lest the customer sue.

A chief engineer is concerned primarily with making systems work properly and safely. At Rolls-Royce they say a chief engineer has three concerns: integrity, integrity, and integrity. A jet engine must run as steadily as the river Trent in Derbyshire – it is no accident that Rolls-Royce engines are named after local rivers.

How can this be achieved? The key is to minimise risk. Specially risky things are untried technologies, new design approaches, and above all complexity.

In the subtitle of their book, Richard Stevens, Peter Brook, Ken Jackson and Stuart Arnold have called Systems Engineering 'coping with complexity'. This indeed catches much of its method and purpose. That complexity is always wrestled with for a purpose, such as the provision of power for aircraft with less noise, less fuel, and less maintenance.

Sometimes there are definite advances in the struggle: for example, modern jet engines have fewer parts than their predecessors, for two reasons.

Firstly, turbines and other assemblies have fewer blades and fewer stages, as powerful computer models have permitted much greater understanding and optimisation of gas flow, and advanced manufacturing techniques allow complete sets of blades and rings (or disks) to be made as single components.

Secondly, software has taken over most of the control of the engine, replacing many heavy mechanical linkages, each subject to a risk of failure. Nevertheless, the overall complexity of the system continues to rise, as the software content increases. The hardware/software system must be very carefully designed to ensure it is reliable. This raises difficult software engineering issues such as formal proof of correctness, but even this begs the question of how to ensure that the specification itself is correct.

Systems Engineering does not, of itself, encompass the mechanical, thermodynamic, fluid-dynamic, electrical, electronic, or software engineering of, say, a jet engine. Engineers in these fields are not, it seems to me, automatically 'systems engineers': if they were, the term would be merely generic, a category like 'public-sector workers' that says little about the work done. If these fields are the muscles of a project, then Systems Engineering has to be the central nervous system that integrates and controls all of them.

This integration and control is necessarily hierarchical, in contrast to soft systems work. Herbert Simon in his book The Sciences of the Artificial tells the parable of two watchmakers, Hora and Tempus. "Hora prospered, while Tempus became poorer and poorer and finally lost his shop." The reason was that Tempus had to start over each time he was interrupted, while Hora made "subassemblies of about ten elements each" which "could be put together into a larger subassembly". Hence, when Hora was interrupted "he lost only a small part of his work". Simon shows that Hora is about 4000 times more efficient than Tempus. The real gain in efficiency is not due only to assembly. Projects suffer from interruptions during design as well as manufacture; the key is to minimise design interactions between assemblies by controlling interfaces and by using known, predictable design approaches.

Requirements Engineering claims to be a steering discipline: we create and manage requirements that guide projects to success. Systems Engineering uses requirements, so there is evidently a large overlap between the disciplines, but requirements play a key role in other areas such as Software Engineering also. That said, techniques of Requirements Engineering including elicitation, analysis of requirements and constraints, modelling of behaviour with scenarios and other techniques, traceability, metrication, review and baselining play vital parts in Systems Engineering as a whole.

What Systems Engineering does that requirements per se do not is to make decisions. Trade-offs between requirements and design are made on the basis of what engineers believe is possible at reasonable risk on the one hand, and what the customer says can be afforded with the time, budget, staff, and other resources (like simulation) on the other. Trade-offs imply a cycle: requirements are placed; solutions are outlined; trade-offs are negotiated. If the result of such a cycle is not good enough, a further cycle may yield a better result – higher quality, lower risk, lower cost. Hence, the approach is iterative. A staged life-cycle is therefore often the most suitable.

The combination of hierarchical breakdown of problems - Caesar's divide et impera (divide and conquer) – with iteration to converge on an acceptable if never optimal solution, is distinctive, and forms the heart of the approach known as Systems Engineering. The method is arduous, and is justified only because for large and complex problems, no other way is known for obtaining workable solutions that meet all the constraints of cost, safety, reliability and performance that characterise modern systems.

© Ian Alexander 2001