49004 Systems Engineering for

Managers

Study Guide

Table of Contents
Subject Learning Objectives

Section 1 - Introduction to Systems

Topic 1.1 - Systems Concepts

Introduction

Objectives

Topic Outline

Required Reading

11

Exercises

11

Section 2 - Soft Approaches

12

Topic 2.1 - Soft Systems Methodology

13

Introduction

13

Objectives:

13

Topic Outline

13

Required Reading

14

Exercises

15

Topic 2.2 - System Dynamics

16

Introduction

16

Objectives:

16

Topic Outline

16

Required Reading

18

Exercises

18

Section 3 Hard Approaches

19

Topic 3.1A Systems Engineering Introduction

20

Introduction

20

Objectives:

20

Topic Outline

20

Required Reading

22

Exercises

22

Topic 3.1B - The System Life Cycle

23

Introduction

23

Objectives:

23

Topic Outline

23

Required Reading

24

Exercises

24

Topic 3.2 - Requirements Engineering

25

Introduction

25

Objectives:

25

Topic Outline

25

Required Reading

27

Exercises

27

Topic 3-3 - Specialty Engineering Integration

28

Introduction

28

Objectives

28

Topic Outline

28

Required Reading

29

Exercises

29

Topic 3-4 - Systems Analysis

30

Introduction

30

Objectives

30

Topic Outline

30

Required Reading

33

Exercises

33

Topic 3-5 Verification and Validation V&V

34

Introduction

34

Objectives

34

Topic Outline

34

Required Reading:

35

Exercises

35

Topic 3.6 Systems Engineering Management

36

Introduction

36

Objectives:

36

Topic Outline

36

Required Reading

37

Exercises

37

Textbook:

37

Section 4 - Bringing it all together Topic 4.1 - Total Systems Intervention

38

Topic 4.1 - Total Systems Intervention

39

Introduction

39

Objectives:

39

Topic Outline

39

Required Reading

39

Exercises

40

Subject Learning Objectives

On the successful completion of this subject, students should:
I. appreciate the significance of systems thinking and concepts to engineering
practice and management;
II. understand the systems approaches closely identified with the engineering
discipline, the issues continually reshaping them under best practice imperatives,
and their distinctive assumptions;
III. recognise the problem domains in which the structured goal-oriented decisionmaking processes of hard (vis--vis soft) systems engineering and life-cycle
perspectives are most applicable;
IV. appreciate the contrasting ideas and approaches of soft systems engineering in the
management of complex organisational issues, and the opportunities in
engineering management to merge hard and soft approaches;
V. be able to benchmark their personal experience of systems practice and
management;
VI. be competent in the selection and application of selected techniques and tools for
dealing with complexity and uncertainty in the creation and/or sustenance of
engineering systems;
VII. be capable of adapting and applying appropriate methodologies of systems
engineering to the challenges of engineering management and their professional
circumstances.

Section 1 - Introduction to Systems

In this section we will explore the concepts of systems and distinguish between soft and
hard approaches to considering systems. We will also consider the situations within which
each approach is considered appropriate.

"When we try to pick up anything by itself

we find it is attached to everything in the universe."
-- John Muir

"Is the world actually composed of interacting sets of entities that

combine to create system? Or is the notion of a system simply a
convenient way of describing the world? In the final analysis, we
simply do not know."
-- Micheal Pidd

Topic 1.1 - Systems Concepts

Introduction
In order to approach our study of Systems Engineering within an appropriate context, in this
topic we will begin our exploration of "systems". We will see that there are many definitions
of this term, though each of them allows us to posit some characteristics that anything that we
call a system must have. We will also note that a "system" is in the eyes of the beholder.

Objectives
At the end of this topic you should:

Understand the concept of systems and its key ideas

Understand the notion of socio-technical systems
Distinguish between hard and soft systems approaches, and where they are appropriate
Understand the concept of the system life cycle and its relevance
Understand why systems thinking and systems engineering have gained such prominence
recently

Topic Outline
In this topic we will look at the concept of systems. We will consider various definitions of
the term and try to ascertain the essential characteristics that something must have in order to
be considered a system. We will go on to look at systems thinking and briefly introduce
systems engineering.
Activity

Before you proceed further, write down your definition of the term system. Write
down also some examples of the ways in which you have used the term. Does the
meaning of the term remain consistent in each of the ways in which you use the term?

Now look up any English dictionary and find its definition(s) of the term. Is (Are) the
dictionary definition(s) essentially different from your own? In what ways are the
different?

There is no single definition of the term system that is accepted in the literature. There are,
however, several concepts that authors in the literature commonly attach to the term (see, for
example, the material in your required reading).
One concept is that of systems comprising multiple elements or parts. This multiplicity of
constituent system elements or parts is an essential characteristic attributed to the concept of a
7

system. The parts or elements of the system may themselves be systems in their own right.
As an example you may consider a car as a system, and its climate control facility as an
element of the car. The climate control facility is in turn made up of elements working
together to provide the overall climate control functionality. The key idea here is one of
hierarchy, with systems being made up of subsystems and, in turn, themselves being
elements of larger systems (often called containing systems).
A second concept is that of these parts being in some vital relationship to each other. The
notion here is one of parts working interdependently with each other.
A third concept is that these parts and these relationships give rise to properties that are
attributable only to the integrated whole and not to any individual part, although the parts
obviously contribute to the rise of such properties. Such properties are given the name
emergent properties (Checkland, 1999). Take the car as an example again. There are many
parts that make up a car. None of these parts alone can transport you from place to place.
When these parts are put together in some defined relationships, then the property of being
able to transport goods and people emerges.
Through the processes of communication and control, a system can survive in the face of
changes in its environment. That is to say, it can maintain its identity in some manner.
With these concepts in mind, a system is often defined in the literature as a number of
constituents or elements in active integration and acting as a bounded whole to achieve some
common purpose through the resulting emergent properties. The organisation of such
entities may be deliberate, as in built systems, or accidental (unplanned) or it may evolve
over time, as in biological and social systems such as communities.
Read:

The Preface, Chapter 1 and Section 2.2 of your Textbook 1.

Hitchins DK (1992), Chapter1 Understanding Systems, 2

Nicholas JM (2001), Systems, Organisations, and System Methodologies

Additional Reading 3: Skyttner L, Basic Ideas of General Systems Theory (chap. 2)

You will note the following from your reading:

All references to textbook in these study guides are to the assigned subject textbook.

All of the readings apart from your textbook are available via the library eReadings facility. See the relevant
link in UTSOnline.

Any reading labelled Additional Reading is not part of the required readings you may read such readings
to extend your exploration of the topic.

The notion of open and closed systems

The notion of soft and hard approaches, and why this distinction is made

The rise of systems thinking and its relevance

The notion of Weltanschauung or world view and its relevance

The system life cycle we will look at other representations of the life cycle later.

We will consider these and other concepts further during the lectures.
Activity
For any system of your choice, identify:

Who the stakeholders are for that system

What purpose does the system serve for its stakeholders

What are the system elements

What constitutes our notion of a system is determined both by our viewpoint and by the
system boundary that we use to delineate the system from its environment. These system
boundaries are neither self-defining nor self-evident (Belcher, W.R., pers. comm). They are
dependent upon the perspective of whoever is observing the system. One important and
essential point to note from this discussion is that the term system does not necessarily
refer to things or entities in the world, but may refer to systemically organised conceptions
of the world (Flood and Jackson, 1991). Kline takes this further and maintains that we need
to distinguish systems from our representations and conceptions of them (Kline, 1995). Kline
labels the latter sysreps. Our sysreps are often representations of some bounded portion
of all reality of interest; they are not, however, the reality.

Read:

Myers M and Kaposi A (2004), Key Concepts,

Additional Reading 4: Kline SJ (1995), Systems, Domains, and truth Assertions.

.
Note from these readings the need to distinguish between a system in the real world and
our view of that system. Why do you think this is important? The reading by Myers and
Kaposi mentions referents and representations. Are representations the same as sysreps?
Why or why not?

Any reading labelled Additional Reading is not part of the required readings you may read such readings
to extend your exploration of the topic.

Let us now look at what are called socio-technical systems. We will look at the origins of
this concept in more depth during the lectures. One definition of a socio-technical system is
as follows:
A socio-technical system is a system composed of technical and social subsystems. An
example for this is a factory or also a hospital where people are organized, e.g. in social
systems like teams or departments, to do work for which they use technical systems like
computers or x-ray machines. (Hornung) 5
Read:

Sommerville I, (2003), Socio-technical Systems

Note from your reading that the human element that either uses, or forms a part of, the
system tends to make the overall system very complex. This complexity means that we have
to be particularly careful when trying to create, modify or manage such systems. Are the
definitions in your reading and the one given above consistent?
A soft situation is one wherein issues and problems are rarely clearly and precisely
definable. We perceive that something is not right, but can not precisely define it. This is
very different from hard situations where our problems are definable clearly, and hence lend
themselves to solutions. Classical engineering relies on such clear definitions of problems.
For such situations we can sensibly talk of efficiency and optimisation of relevant systems.
For soft systems, however, notions such as optimisation do not make much sense. When we
do not have a clear idea of our problem, then what would we try to optimise, and with respect
to what would we optimise? In such situations our aim becomes to improve rather than
optimise. A number of soft methodologies aim to help us do that.
Hard systems engineering has distinguished between two types of functions associated
with systems, viz. characteristic and mission functions. Classical systems engineering
also assumes that a need is discernible and definable relatively precisely by the users.
From this definition of need may be derived the User Requirements that indicate the
functionality needed of any system seeking to fulfil that need (Stevens et.al., 1998). These
user requirements capture the mission functions of the system. In this sense, the mission
functions lie in the problem domain of the users. We will leave for now a definition of the
term user. For now, we shall use it in the most general sense. The important point to be
made here is that it is the user who has the critical role of establishing the mission functions
of a system. This is so because it is the users needs that the system does or will address. A
corollary to this is that it is the user who needs to establish some way to judge whether, and to
what extent, does a given system fulfil the need. This is the domain of system effectiveness
discussions which we will encounter later in the subject. For now let us note that the mission
of any system exists either directly or indirectly in a social context, and so its effectiveness
should be judged in that context as well.

Source: http://pespmc1.vub.ac.be/ASC/hornung.html, viewed on 06 Feb 2008.

10

Required Reading
As indicated above.

Exercises
1. Textbook Chapter 1 Problem 2
2. Textbook Chapter 1 Problem 4
3. Textbook Chapter 1 Problem 17
4.

A system is neither self defining nor self evident. Discuss this statement in
the light of your readings.

5. The Australian economy is a system. True or false? Justify your answer.

6. How would YOU define a socio-technical system?
7. If you were a project manager, or an engineering manager, would the notion of
socio-technical systems be significant to you? Why or why not?
8. Consider the thermometer. Is it a socio-technical system? Explain. What
about a football team? Explain.

11

Section 2 - Soft Approaches

In this section we will look at some of the soft systems approaches, and look at a metamethodology called TSI.

Some problems are so complex that you

have to be highly intelligent and well informed
just to be undecided about them.
--Laurence J. Peter

12

Topic 2.1 - Soft Systems Methodology

Introduction
Soft Systems Methodology (SSM) was developed by Peter Checkland at Lancaster
University in the 1960s as a result of his dissatisfaction in applying Systems Engineering
(hard approach) to problems in business organisations. He noticed that the systems
engineering approach of clearly defining a problem, and then using top down decomposition
was not suitable in situations where you could not precisely pin down the problem. SSM was
his response.

Objectives:
At the end of this topic you should:

Understand how to apply the methodology called SSM

Be able to explain the notions of real world thinking and systems thinking as it
pertain to SSM

Explain the streams of enquiries in SSM

Explain how the SSM works

Explain why SSM was deemed necessary

Topic Outline
SSM seeks to foster enquiry, learning and understanding of a problem situation, rather than
treating a situation as a pre-defined problem to be solved. It insists upon very close
involvement of various stakeholders in this enquiry. Checkland used the term Human
Activity System (HAS), to denote groups of people within organisations acting out various
(social) roles to achieve some purpose. In such systems, consensus of objectives and the
means to achieve them is often difficult to obtain, since each person in the system will have a
particular viewpoint and perspective which may not coincide with that of others in the HAS.
Problems in such situations can be messy, and not lend themselves to classical problem
solving techniques.
You will note from your reading that SSM has two main modes real world activities and
applying systems thinking to the real world.
13

The methodology starts by trying to express the problem situation through the use of such
artefacts as rich pictures. The idea here is to gain understanding and consensus about the
problem situation, and what it is that we are trying to do and achieve in our situation. All
relevant stakeholders are needed for this. CATWOE analysis helps us to identify the relevant
stakeholders, and their world views, as well as the transformations that are carried out by
the HAS.
Once we have a consensus regarding the problem situation and what we are trying to achieve,
we can try to formulate activities that we would ideally carry out to achieve our purpose.
This is the step for formulating Root Definitions. Root Definitions are statements describing
the activities that we are or should be engaged in. CATWOE is the first step to formulating
the Root Definition.
Having formulated the Root Definition, we leave the real world behind for a while and apply
systems thinking to conceptualise models of ideal systems that need to exist for us to carry
out the activities suggested by the root definitions. Again we try to achieve consensus
regarding which Conceptual Models are the best in our situation. In order to do this, we
need some criteria that help us choose. Checkland suggests the 5Es - efficacy (will it work?),
efficiency (with minimum resources), effectiveness (and contribute to the enterprise),
ethicality (and is moral) and elegance.
Having formulated our conceptual models, we can return to the real world and compare
what we are actually doing with what we agreed via our conceptual model we should be
doing. This enables us to identify areas that require improvement. There may be many ways
to achieve such improvement, however not all of them may be suitable for our organisation
and situation. We need to therefore determine which of the possible ways of improvement
would be acceptable for our organisation. Having determined this, we implement our
changes, and continue to monitor the situation for further improvements.
This is a VERY brief overview of the methodology. We will consider more details in the
lectures.

Required Reading

Checkland P (1993), The Development of Soft Systems Thinking,

Jackson MC (2004), Soft Systems Methodology,

Additional Reading6: Staker RJ (1999), An Application of Checklands Soft Systems

Methodology to the Development of a Military Information Operations Capability for
the Australian Defence Force.

Any reading labelled Additional Reading is not part of the required readings you may read such readings
to extend your exploration of the topic.

14

Exercises
1.

Explain in your own words how SSM works.

2.

Explain the notion of a human activity system (HAS).

3.

Why is the notion of Weltanschauung important to SSM? What would be a possible

consequence of ignoring it?

4.

Given the following root definition, perform a CATWOE analysis and indicate the
elements (i.e. customers, owners etc.):
A house-holder owned and staffed system to paint a garden fence by conventional
hand painting in order to enhance the visual appearance of the property.

5.

Attempt to construct a conceptual model of the system indicated in the above root
definition.

6.

What are some of the criticisms levelled at SSM? In your view are they justified?

15

Topic 2.2 - System Dynamics

Introduction
System Dynamics allows us to create models that help us understand how and why systems
behave as they do over time, that is, their dynamic behaviour. The methodology was
developed by Jay Forrester in the 1950s. Even though we have classed the methodology
under Soft Systems Approaches in this subject, there are many who would challenge this.
The treatment of the methodology in this subject is largely in accordance with the text by
Maani and Cavana (2000).

Objectives:
At the end of this topic you should:

Understand the concepts and philosophy behind Systems Dynamics (SD)

Be able to draw Causal Loop Diagrams and Stock and Flow Diagrams

Appreciate the exploration of system behaviour using these diagrams to model

systems

Understand the concept of System Archetypes

Topic Outline
A)

General

System Dynamics is concerned with the dynamic behaviour of systems. It allows us to do so

by recognising the causal connections between variables in our system, and by allowing us to
model the system using what are called Stock and Flow Diagrams. There are a number of
software tools such as Vensim and Stella that may be used for this purpose. Fundamentally
what we try to do is to identify the structure of our system so that we may model it. To do
so we need to establish:

The system boundary (establish our system of interest)

The feedback loops that exist in our system

The variables that may be the stocks and flows in our system (defined later)

The leverage points in our system that would give us the greatest impact
16

Maani and Cavana (2000) offer a methodology involving five phases as follows:
1. Problem structuring
2. Causal loop modelling
3. Dynamic modelling
4. Scenario planning and modelling
5. Implementation and organisational learning
The methodology encourages organisational learning via the last two phases. We will look at
these in more detail during the lectures.
B) Causal Loop Modelling (CLD)
Read:

Kirkwood, System Behaviour and Causal Loop Diagram,

Additional Reading7: Sterman, JD, Causal Loop Diagrams

Ensure that you understand how to construct a CLD for a given situation. Ensure that you
understand how to identify reinforcing and balancing loops. Note that a cause and its effect
may be separated in space as well as time. The time aspect is handled within CLD as a delay
symbol. Why is it important for policy makers and decision makers to understand this notion
of delay between a cause and its effect?
C) System Archetypes
Archetypes may be considered as basic patterns that we recognise over and over. System
archetypes are patterns of behaviour that have been observed and documented using CLDs.
The reading by Braun gives you several examples of system archetypes. As you read through
that reading try to recall if you have come across any of the archetypes in your experience.
Read:

Any reading labelled Additional Reading is not part of the required readings you may read such readings
to extend your exploration of the topic.

17

Braun W (2002), The System Archetypes

D) System Behaviour
System Dynamics posits that dynamic behaviour in systems occurs due to the Principle of
Accumulation. The world is considered to be made up to stocks into which stuff
accumulates, and flows through which stuff passes. The principle states that dynamic
behaviour results when flows accumulate in stocks. We can convert CLDs into Stock and
Flow diagrams which can then be converted into simulations that can be used to model the
system behaviour. To get an insight into this:
Read:

Maani E and Cavana RY, Dynamic Modelling,

Binder T, Vox,A, Belyazid S, Haraldsson H, Svensson M, Developing Systems Dynamics

Models from Causal Loop Diagrams

Note that different notations are used for Stocks and Flows and other entities by various
software tools. What is important here is that you understand the principles behind System
Dynamics, and familiarise yourself with some of the notation.

Required Reading
As indicated above.

Exercises
1.

Comment on the concept of system archetypes.

2.

You will be required to do a group project soon for this subject. Identify several
variables which can impact your project either positively or negatively. Draw a causal
loop diagram using these variables.

3.

Do you think that causal loops are a good tool to use in thinking about systems? Why
or why not?

4.

Explain in your own words how SD works.

5.

In your view, is SD a hard or soft systems approach? Explain your response.

6.

What, in your view, is the Weltanschauung that underlies SD?

7.

You were asked to create a causal loop diagram for your group project in exercise 2.
Try to model this using SD concepts. (Along the lines of Fig 4-3 in the Maani and
Cavana reading).

18

Section 3 Hard Approaches

In this section we look at the predominant hard systems approach practised by engineers
Systems Engineering. We will examine the process of systems engineering in the context of
the System Life Cycle.

Science: Determines what Is

Component Engineering: Determines what Can Be
Systems Engineering: Determines what Should Be
-- adapted from Arunski, Brown and Buede8

Arunski JM, Brown P, Buede D, Systems Engineering Overview, Presentation to the Texas Board of
Professional Engineers, 1999.

19

Topic 3.1A Systems Engineering Introduction

Introduction
We have already looked briefly at the concept of a System Life Cycle (SLC). In this topic we
re-visit the life cycle and introduce the systems engineering (SE) process in its context. You
will see that the SE process iterates through the life cycle phases.

Objectives:
At the end of this topic you should:

Understand the concept of system life cycles

Be familiar with the overall systems engineering process

Appreciate the iterative nature of system development

Topic Outline
Engineers have used the discipline of Systems Engineering to develop complex systems
requiring application of multiple sub-disciplines of engineering. The process of system
development advocated in the discipline of Systems Engineering begins with the recognition
that a holistic, multidisciplinary view of a need and the system that fulfils it is essential. It
then typically follows the following phases:
Phase 1.

Understanding the need and establishing the user and system requirements.

Phase 2.

Exposure and understanding of the required system behaviour.

Phase 3.

Synthesising of a physical solution that manifests this required behaviour.

Phase 4.

Validation that the system that results does indeed fulfil the need.

A management effort to ensure the integrity of the process is overlaid throughout the process
phases. This process is well described in the literature of Systems Engineering (see, for
example, Blanchard and Fabrycky (1998), and Stevens et.al (1998)).
We class SE as a hard systems approach because it requires that the need or problem be
clearly defined, and the requirements to be captured unambiguously. This is further
reinforced by the need to often have a contractual framework around most system
development projects.
As you go through this topic, note that there are many depictions of both the systems
engineering process and the system life cycle. Your textbook gives some examples. An
example of the Australian Defence Force (ADF) view of the system life cycle is given below.
20

Source : ADF, Life Cycle Disciplines Guide v1.5

An example of the SE process model from the SE standard EIA IS 632 is given below:
Process Input

Customer Needs/
Objectives/
Requirements

Mission/
Operations

Measures of
Effectiveness

Environments
Constraints

Requirements Analysis

Systems
Analysis

Analyse Missions & Environments

Identify Functional Requirements
Define/Refine Performance & Design
Constraint Requirements

Requirements Loop

Technology Base

Functional Analysis/Allocation

Prior Output Data

Program Decision
Requirements
Requirements from
Tailored Standards
and Specifications

Decomposition to Lower-Level Functions

Define/Refine Functional Interfaces (Internal/External)

Allocate Performance & Other Limiting

Requirements to Lower-Level Functions
Define/Refine Functional Architecture

Design Loop

Trade-off Studies
Effectiveness Analysis
Risk Management
Configuration Mgmt
Interface Management
Data Management
Performance Based Progress
Performance Measurement

SE Master Schedule
Tech Perf Measurement

Synthesis

Verification

Select Preferred Alternatives

Transform Architectures (Functional to Physical)

Define Alternative Product Concepts
Define/Refine Physical Interfaces (Internal/External)
Define Alternative Product & Process Solutions

PROCESS OUTPUT

The Systems Engineering

Process

Integrated Decision Data Base

Decision Support Data

System Functional & Physical
Architectures

Specifications & Baselines

Balanced System Solution

This process iterates throughout the system life cycle. This life cycle is depicted in your
textbook as follows:

We will consider this in more detail in the next topic.

Read the material indicated in the Required Reading below.
21

Required Reading

Textbook: Chapter 2

Lacy JA (1992), Chapter 2 Systems engineering activities

Exercises
1.

In your own words indicate what you believe Systems Engineering is.

2.

What do you think is the relationship between Systems Engineering and Project
Management?

22

Topic 3.1B - The System Life Cycle

Introduction
Preliminary Design is the 2nd phase of the life cycle in accordance with Blanchard and
Fabrycky (B&F). Other authors and practitioners may use different terminology. As you go
through the reading, remember that the process and activities such as Functional Analysis are
carried out iteratively, both to accommodate our growing knowledge and to develop our
system in greater levels of detail. In this sense, the systems engineering function is run again
and again at each phase.

Objectives:
At the end of this topic you should:

Understand the outcomes of the life cycle phases, particularly Preliminary design and
Detailed Design

Reinforce your understanding of the need to control changes

Appreciate the importance and elements of reviews

Appreciate that the SE process iterates through these phases

Topic Outline
The following diagram presents the system life cycle as depicted in your textbook.

The systems engineering process iterates through each of the phases of this cycle. We will
consider the details of Conceptual Design phase in the next topic. We will look briefly at the
Preliminary and Detailed design phases here.
Preliminary Design builds upon the work carried out in the previous phases. It takes the
functional baseline established and extends it to develop system requirements at subsystem
level. It does so by continuing the functional analysis, allocation and synthesis at the
subsystem level. Using the terms Lacy provides, we continue the activity of decomposition.
As we identify alternate ways of proceeding, trade studies are used for decision making
regarding the way to proceed. The set of requirements we end up with is detailed enough to
allow us to proceed to equipment design. The baseline produced from Preliminary Design is
termed the Allocated Baseline.
Read your textbook Chapter 4 and Appendix B
23

Note carefully the activities that are carried out and the reviews that are essential to produce
the baselines.
The process continues during detailed design to develop what is known as the product
baseline.
Skim your textbook Chapter 5.
Note how the Product Baseline results, and the need to control changes to these baselines.
Ensure that you understand the concept of configuration management, and the need for it.

Required Reading
As indicated above.

Exercises
Textbook Chapter 4: Questions 1, 6, 22, 26.
Textbook Chapter 5: Questions 1, 3, 17, 21, 22

24

Topic 3.2 - Requirements Engineering

Introduction
This topic introduces you to the requirements engineering process. We saw when
considering the life cycle that system development is typically a result of some need or
opportunity that some stakeholder perceives. Requirements engineering is concerned firstly
with capturing this need and the implied required capability to meet this need in some form of
user requirements, and then specifying the required system functionality and performance
so that this need may be fulfilled. Along the way we need to manage the requirements to
ensure their integrity with respect to the need.

Objectives:
At the end of this topic you should:
Understand the notions of capability, user and system requirements
Appreciate the need to define the operational environment within which the capability is
needed
Understand the process of identifying, clarifying, capturing and managing the
requirements
Be competent to use the techniques for requirements analysis introduced in the subject
Appreciate the importance of identifying the verification method for each requirement

Topic Outline
A stakeholders need typically requires some capability to be provided for this need to be
fulfilled. Note that we are using the term need very broadly here. Any problem, deficiency
or opportunity that a stakeholder perceives is classed as a need for our purpose here. The
term user requirements is generally used for the set of requirements that define this
required capability. The capability will be enabled by some system that behaves in some way
i.e. functions in some particular way. A set of requirements is developed to capture this
required system functionality. This set of requirements, which specifies system functionality
and performance, is termed system requirements.
We use the term Requirements Engineering to denote the set of activities that we carry out
to specify and manage these requirements. Requirements Engineering typically involves:

Requirements Elicitation identification of relevant requirements

Requirements analysis and clarification to ensure that we remove any ambiguity

Requirements Capture documentation of requirements via specifications

Requirements Management to ensure that any changes to requirements are

controlled
25

An example of a user need may be your need to provide protection for your belongings inside
your house. This may translate to a set of user requirements that include watching for
intruders, preventing intruder entry, notifying you or some authorities in case of intruder
entry, and so on. This set of requirements may be met in a number of possible ways,
including automated and non automated means. There may be constraints such as cost or
legalities that prevent you from using some options. These constraints may mean that you
modify your requirements to screen out the unwanted options.
Once we have established the user requirements and captured them in some User
Requirements Document (URD), we can try to establish the required functionality of a
system that can help us achieve our goals. In our example, such functionality may include
the ability to sense presence of people, the ability to identify these people as legitimate or
intruders, the ability to raise alarms, prevent entry etc. Regardless of what our system
looks like, it must do these things. This is a very important point about systems
engineering. We are interested in determining what our system must do and how well before
determining what the system is, or look like.
To proceed from the need to user to system requirements we use many techniques, including:

Mission and context analysis

Functional analysis

Techniques for clarifying individual requirements, such as parsing and primitive

requirements analysis

We will consider these techniques during the lectures.

Read:

Hull E, Jackson K and Dick J (2005), Chapter 2 A Generic Process for

Requirements Engineering,

Kotonya G and Sommervaille I (2002), Chapter 1 Introduction,

Stevens R, Brook P, Jackson K and Arnold,S ( 1998), Chapter 3 The Systems

Requirements Process

Textbook Chapter 3 and Appendix A

Carefully note the process of identifying both user and system requirements from your
readings. Note that while we have mentioned user or stakeholder above, in practice there
will be more than one stakeholder e.g. owner, operator, maintainer, end user and so forth. In
26

practice these stakeholder needs may be in conflict, and need prioritizing by some authority.
Often we find that the set of requirements we end up with form a compromise amongst a set
of conflicting requirements.
Note also that the user requirements capture the user view of the need, not the designers
view.
As we go through the process of requirements analysis in the context of Conceptual and
Preliminary design (as we see later), we end up developing our System Architecture. In the
lectures we will discuss notion that System Architecture has at least three perspectives
(Stevens et.al., 1998):

Structural View we will use hierarchy diagrams and N2 diagrams to capture this
view

Behavioural View we will use FFBDs and State Transition Diagrams for this

Layout View - we will use System Block Diagrams to capture this view.

Required Reading
As indicated above.

Exercises

1.

Using an example, distinguish between user and system requirements.

2.

What do you think is the difference (if any) between a requirement and a constraint?
Illustrate your answer with an example.

3.

Textbook Chapter 3, Questions 4,6,7,15,18.

27

Topic 3-3 - Specialty Engineering Integration

Introduction
In the development of systems we often encounter areas of knowledge which are the domain
of specialists in those fields. This topic examines some of these areas. In your textbook the
main areas covered here are described in the part of the book that deals with designing for
operational feasibility. The implication of this is that for a system to be useful and fit for
purpose, it should not only carry out the required functions to the required level of
performance, but it should do so in a sustained and sustainable way. Some of the specialist
areas that we will examine enable such sustainable performance.

Objectives
At the end of this topic you should:

Understand the concept of engineering speciality and its importance

Understand the speciality areas considered in this topic

Understand how to specify and manage the requirements pertaining to the speciality
areas considered

Be able to apply the techniques covered in this topic to the types of problems
encountered in the exercises

Topic Outline
In this topic we will look at the following specialty engineering areas:

Reliability

Maintainability

Availability

Human Factors Engineering

Life Cycle Costing

The first three of these will be considered in more detail in the lectures. The following
reading will give you an understanding of the key issues involved.
Read the following from your textbook:

Chapter 12 up to and including Section 12.4

28

Chapter 13 up to and including Section 13.5.1 and 13.6

Chapter 14 up to and including Section 14-2, and Figure 14-9

Chapter 17 up to and including Section 17.2.4, and Figure 17.5.

Required Reading
As indicated above.

Exercises
Chapter 12: Questions 1, 2, 5, 7, 12, 16
Chapter 13: Questions 1, 4, 8, 9, 25
Chapter 14: Questions 1, 3
Chapter 17: Questions 1, 3

29

Topic 3-4 - Systems Analysis

Introduction
As we progress through our system development, we will encounter many instances where
we need to choose amongst various alternatives. For example, we may need to choose
amongst various ways of communicating with the user e.g. through printed reports, via
displays, using voice communications, and so on. The process used to make this decision is
often termed trade study. Systems Analysis includes the set of activities that allows us to
make such choices, and to predict and assess the performance of our system to ensure that we
are meeting the system performance requirements.

Objectives
At the end of this topic you should:
o Understand the importance of, and systems analysis
o Understand various elements of systems analysis, including:
o Trade Studies
o Technical Performance Measurements
o Modeling and simulation
o Optimisation

Topic Outline
As your text says, systems analysis is a large discipline in its own right. We will consider
briefly only the topics listed above. You are encouraged to skim through Part3 of your
textbook to get an idea of the sorts of things that we are concerned with in analysing systems.
Trade Studies is the name given to the process of choosing between a number of alternative.
We may be faced with a choice at any of the stages and phases of the systems engineering
process an the life cycle. Sometimes our choices are made intuitively and at other times we
use more formal processes, depending upon the importance of, and the risks inherent in, that
choice. In order to make a choice, we need to have some criteria against which we can judge
our alternatives. These criteria also need to be ranked or weighted in some way. Lacy calls
this our value system.

30

Read the section on value system design the Lacy reading 9 and review the material in your
textbook Chapter 4.
Note the importance that Lacy places on ensuring that our value system is well designed, with
inputs from, and review by, the relevant stakeholders. Our value system then forms the basis
of our trade studies.

Activity
You decide to buy a car. Identify a value system that you can use to choose type of car you
would buy. How did you assign weightings (if any) to your criteria? Do you think that your
set of criteria will change over time e.g. as you get promoted and earn higher salaries? Why?
Compare the criteria that you used with those of a colleague in class. Were the two sets of
criteria identical? How similar were they? If not, why were they different?
Now read the section Systems Analysis from the Lacy reading.
Note carefully the technique that Lacy calls Pughs Controlled Convergence. We will also
look briefly ate the Analytic Hierarchy Process (AHP) in the lectures.
Note also that Lacy includes processes such as optimisation and modelling within the topic of
systems analysis as well. In practice, systems engineers tend to consider any type of analysis
that we do on our system to be within systems analysis. Your textbook identifies a number
of models that are used in systems analysis.
A model is a representation of some aspect of reality, be it a system or whatever. As such,
we make a number of assumptions regarding which aspects we model and which ones we
ignore or simplify. This has to do with our objectives in modelling.
In accordance with INCOSE The function of modeling is quickly and economically to create
data in the domain of the analyst or reviewer, not available from existing sources, to support
decisions in the course of systems development, production testing, or operation. (INCOSE,
1998) 10. Accordingly, INCOSE posits the following as the objective of modelling:
The objective of modelling is to obtain information about the system before
significant resources are committed to its design, development, construction, testing,
or operation. Consequently, development and operation of the model must consume

Lacy JA (1992), Chapter 2 Systems engineering activities

10

Robertson T. C., Systems Engineering Handbook, INCOSE, Release 1.0, 1998.

31

time and resources not exceeding the value of the information obtained through its
use. (INCOSE, 1998)
As you can see from your text, models are used in every phase and stage of the system
development process. There can be models of the product we are creating, as well as models
of the processes we are using to create the product. So far in this course we have encountered
both. Our models can be:
Conceptual
Physical
Mathematical
Graphical
Other?
Activity
Identify one process model that we have discussed that captures systems engineering, and one
behaviour model we have used to capture product behaviour.
Another element that is often classed within Systems Analysis (although it cuts across most
of the life cycle) is Technical Performance Measurement. We have come across this during
or consideration of Conceptual and Preliminary design. Basically TPM uses the following
steps:
1. Identify the relevant performance requirements.
2. Identify the relevant Measures of Effectiveness.
3. Identify the standards or levels of performance required.
4. Plan the monitoring of these measures.
5. Monitor the measures.
6. Compare monitored values with requirements.
7. Take corrective actions as needed.
See your textbook for a number of examples of factors that are typically monitored. One
important type of parameter that is monitored is called a Measure of Effectiveness
(MoE). We discussed these when we considered socio-technical systems, and what it means
to say that a system is effective. Sproles provides useful discussion on MoEs.
Read:
32

Sproles N (2002), Formulating Measures of Effectiveness, University of South

Australia and DSTO

See your lecture material for a flow diagram describing the process of technical performance
measurement, and for a model depicting Measures of effectiveness.
Activity
Identify some MoEs for an ATM system. Who can decide if these are the appropriate MoEs
for this system?

Required Reading
As indicated above, and
Skim through Textbook Part III.

Exercises
There are no additional exercises for this topic.

33

Topic 3-5 Verification and Validation V&V

Introduction
As we progress through our system design, we need to demonstrate at each stage that we are
meeting the specified requirements of our system. When we have finished constructing our
system, we need to prove to our clients that the system that we have built does indeed meet
their requirements. The client, in turn, needs to ensure that the resulting system is fit for
purpose.

Objectives
At the end of this topic you should be able to :
Understand verification and validation and distinguish between them
Appreciate the need for thorough planning for V&V
Understand the different types and levels of verification commonly used in system
development

Topic Outline
There are two terms that are often used in systems engineering when it comes to
demonstrating that we are creating an appropriate system. These terms are Validation and
Verification.
Validation has to do with ensuring that we create a system appropriate to our needs. That is
to say, that we are creating the right system. This has to do with the problem domain, and
our understanding of that problem domain. Any activity that we carry out to ensure that our
requirements are good and appropriate to the need, is within the ambit of validation.
Verification, on the other hand, deals with ensuring that the system that we are creating meets
the requirements as specified. We assume here that the requirements are appropriate, i.e. the
are validated requirements. Any testing, and other activities, that we carry out to prove that
our system meets its requirements therefore falls within the ambit of verification.
Read:

Textbook Chapter 6

Bahill and Henderson (2004), Requirements Development, Verification and

Validation Exhibited in Famous Failures.

Note carefully the requirements for test and evaluation, and the types of testing described in
the text. There are other terms used in practice as well. We will look at some of these and
some tools for managing the verification process in the lectures.

34

Required Reading:
As indicated above

Exercises
Textbook Chapter 6: Questions 1, 2, 3, 14, 16, 20.

35

Topic 3.6 Systems Engineering Management

Introduction
In this topic we will look at some aspects of management as they relate to SE. We will only
consider some elements of this large topic. You have looked at elements of project
management, risk management and others in more detail in other subjects. Here we will revisit some of these very briefly.

Objectives:
At the end of this topic you should:

Understand the importance of the SEMP

Appreciate the linkages between SE and Project Management
Understand the notion of capability improvement
See how SE management fits within an overall management effort
Understand the importance of change control (Configuration Management)
Appreciate the importance of reviews

Topic Outline
Management is often spoken of in the literature as comprising the functions of planning,
organising, leading, implementing and controlling (see any introductory textbook on
Management). To control something implies that we know our objectives and the means to
achieving them. Unless we know this, it makes little sense to speak of controlling something.
Hence the importance of planning, which helps us to determine these things. Systems
Engineering on projects needs to support the overall project effort. As you read through the
material for this topic, try to see the relationships between SE and Project Management.
SE management is the management of all the systems engineering activities on a project. The
management approach and its success factors are captured in the Systems Engineering
Management Plan (SEMP).

The management effort in Systems Engineering has several important foci, including:

Management of requirements and their baselines

Configuration management

Management of the system architecture and interfaces

Management if risks

Management of the V&V programme

36

Carrying out reviews and audits as necessary

And others

We will look at these elements in the lectures. We have looked at some of these elements
already e.g. requirements management (Topic 3.2), Configuration Management (Topics 3.2
and 3.3), reviews (Topics 3.2 and 3.3).
In order to gain some understanding of the other elements above read Chapters 18 and 19 of
the Textbook. You should re-visit the earlier readings at this point as well to refresh your
understanding.

Required Reading

Textbook: Chapters 18 and 19

Textbook Sections: 3.10, 4.8, 5.8, and 5.9.

Exercises
Textbook:
Chapter 18: 1,2

Chapter 19: 1, 7, 15, 18.

37

Section 4 - Bringing it all together

38

Topic 4.1 - Total Systems Intervention

Introduction
There are many approaches and methodologies that have become popular amongst systems
thinkers and practitioners. Everyone has their own favourite methodology that they pursue in
most cases. It is important to recognise that each situation and problem presents different and
unique characteristics, and so there is no one method that can be said to apply to every
situation. It is useful therefore to have a system that guides us in choosing a methodology
appropriate to a given situation or problem.

Objectives:
At the end of this topic you should:

Understand the significance of metaphors to characterise a situation

Understand the use of SOSM

Recognise the need for some methodology such as the TSI to guide our intervention
into problem situations

Be able to explain in your own words how TSI works

Topic Outline
Read:

Flood RL and Jackson MC (1991), Total Systems Intervention.

You should note the three phases of TSI viz. creativity, choice and implementation. Try to
understand the tasks, tools and the expected outcomes of the phases. You should particularly
note the significance of metaphors and their use in TSI.
TSI requires us to view problem situations from multiple perspectives - hence the usefulness
of the metaphors. This allows us to ascertain what the key or dominant issues might be in the
problem situation. When we know this, we can use tools such as the System of Systems
Methodologies (SOSM) to choose appropriate methodologies for our intervention into the
problem situation.

Required Reading
As indicated above.

39

Exercises
1.

Why do you think TSI has been proposed by Flood and Jackson?

2.

What is the significance of the metaphors?

3.

This reading was from a book titled Creative Problem Solving. How do you think
TSI relates to the concept of problem solving?

4.

Explain the concept of System Of Systems Methodologies

40