Skip to content
Skip to main content

About this free course

Become an OU student

Download this course

Share this free course

Systems engineering: Challenging complexity
Systems engineering: Challenging complexity

Start this free course now. Just create an account and sign in. Enrol and complete the course for a free statement of participation or digital badge if available.

3 What is systems?

3.1 Introduction

As you would expect, since this course deals with systems engineering, it embodies the principles and methods associated with a systems perspective. So it is important that you understand systems and the systems perspective at the beginning of the course.

To have engineered a system successfully, all its features – the technology, control systems, people and related aspects of the physical environment – have to contribute to the achievement of its objectives. In other words, it has to operate in an integrated, coherent way. It has to meet the requirements of all stakeholders. There are also things that it must not do. For example, it should not exceed its agreed or projected running costs; it should not, in achieving its requirements, wantonly harm individuals or the physical environment, and so on. These sets of requirements and constraints can be represented by the three models shown in Figure 21.

Figure 21
Figure 21 Patterns of demand, choice and constraint in systems engineering


The demands, choices and constraints associated with a system can arise from any of the stakeholders in that system. If stakeholders are denned as an identifiable group of people or an organisation, or organisations, having a legitimate interest in the process or outcomes of a systems engineering project (see also Box 6), identify the stakeholders in the Millennium Bridge project.


The stakeholders involved in the Millennium Bridge were as follows.

  1. Those who put up the money:

    • The Millennium Commission through the Millennium Bridge Trust

    • The Corporation of London through the Bridge House Estates Trust

    • The Hong Kong and Shanghai Banking Corporation (HSBC)

    • The Financial Times (which sponsored the original competition)

    • and other contributors of funds.

  2. Those involved in the bridge's design or construction:

    • Ove Arup

    • Foster and Partners

    • Sir Anthony Caro

    • Sir Robert McAlpine

    • Monberg Thorsen

    • subcontractors.

  3. Local authorities, the Borough of Southwark.

  4. Those concerned with the bridge's context: e.g. the Tate Modern's architects, Herzog & de Meuron.

  5. The public wishing to use the bridge.

  6. River users.

Box 6 stakeholders

Mitroff (1980) defined the stakeholders in a system as all those:

  • having an interest in the change being considered

  • who stand to gain from it

  • who stand to lose from it.

The stakeholders in any system can be classified into one of four categories:

  1. Those responsible for its design and development, for example the project managers, system engineers, communications experts, technical authors.

  2. Those with a financial interest in the system, responsible for its sale or its purchase, for example the marketing manager, the buyer.

  3. Those responsible for its introduction and maintenance within an organization, for example training and user support staff.

  4. Those who have an interest in its use, for example user managers and all classes of users: primary (those who are likely to be frequent hands-on users of the system); secondary (those who are occasional users of the system or who make use of it through an intermediary); tertiary (those who are affected by the introduction of the system or who will influence its purchase but who are unlikely to be hands-on users).

Adapted from Macauley (1996)

The constraints define the area in which the system can legitimately operate. The articulated demands or requirements of the system are at the core of the system. They, together with the constraints, define the amount of choice that the systems engineers will enjoy. In practice, and even with the best endeavours of the various stakeholders in the system, demands and constraints are rarely articulated in a way that the clarity of the circles in Figure 21 might suggest. One way of looking at systems engineering is to regard it as a process of progressively refining demands (requirements) and constraints in such a way that design choice is eliminated. This process of progressing from an initial, fuzzy concept of what the system will do to a final, implemented and ambiguity-free system is illustrated in Figure 22.

Figure 22
Figure 22 The progressive definition of the system


Into which of the three categories shown in Figure 21 would you place the Autodesk and Millennium Bridge examples discussed in Section 1?


I would classify both Workcenter and the Millennium Bridge as type ‘b’ systems engineering projects.

The success of a systems engineering activity is judged by:

  • how well the outputs of the activity fulfil demands and how well the design of the system has avoided violating constraints, and

  • how successfully the systems engineers have implemented the choices that were available to them, and

  • the quality of the systems engineering process.

Although the quality of the systems engineering process may be regarded as a tertiary measure of a systems engineering project, it is the foundation of the primary and secondary measures of success.

Adopting a systems approach addresses the need to establish and maintain the internal coherence of the project and its external requirements. The systems approach consists of:

  • a set of concepts that provide a philosophic basis for the approach

  • a methodology that forms a framework for designing, developing, operating the system and managing change

  • a set of techniques, used within the context of the methodological framework, that provide a toolkit for planning, analysis and design work.

The relationship of these three elements of the systems approach is illustrated in Figure 23. Each of these elements of the systems approach will be discussed in turn.

Figure 23
Figure 23 Systems as concept, methodology, technique