BSS 310: Engineering Management

Systems Engineering
Module Outcome for Systems Engineering:
Create a conceptual design of an engineering system and explain the activities required for
development of the system.
Foundational Knowledge on Systems Engineering
Part 1: Chapter 1.1 and partly 1.3 of Systems Engineering Principles and
Practice and slide #1

Learning outcomes for section:

• Understanding the basics and fundamental concepts of systems engineering

• Ability to explain and give illustration of definitions, concepts and procedures

1. What is Systems Engineering?

~Function of Systems engineering is to guide the engineering of complex systems. Guide –
to lead, manage, direct based on superior experience in order to pursue a given course,
“show the way”

~“Systems engineering is concerned with designing integrated solutions to complex

problems”----United States Military Academy

~Interdisciplinary field of engineering (mix of mechanical, civil etc) that focuses on:

• Planning,
• Design,
• Development,
• Implementation,
• Management of complex systems.
• Ensures that the needs of all stakeholders of a system are satisfactorily met

Definition of Engineering – The application of scientific principles to practical ends, as

the design, construction and operation of efficient and economical structures, equipment and
systems.

“Efficient,” “economical” and “systems” – good systems engineering

Attributes of DESIGN in systems engineering:

 Performance -
 Acceptable cost
 Speed
 Operational Range -
 High Throughput -
 Error reduction -
Flowchart conceptualising the definition of what systems engineering is:

Other components of the System Family:

2. Why Systems Engineering?

3. Categorisation of the SE programme via (outputs) and

(specialization)
Categorisation by output:

• Product Systems Engineering

Produce new products
Rework existing products
Order parts
Deploy product development model
Uniqueness of new products
Create standards
Test products

• Service Systems Engineering

Satisfaction o customers
Evaluation of service provided
Reduction of overall operating costs
Verification of customer information
Innovation of new service techniques
Creation of standards
Encouragement of customers i.e. after sales service
 • Enterprise Systems Engineering
Efficiency of information flow
Notifications and awareness
Transparency in operations
Encryption of system
Reduction of system risk
Precision of goals, disseminate (spread) information etc.
Repeatability capability
Integration of system elements
Set operation standards
Evaluation of the process

Categorisation by specialisation:

• Systems Engineering Technical Process

⇒ Hard Systems Modelling: includes Engineering analysis techniques,
concepts, strategies, procedures, etc:
 Modelling and Simulation
 Optimization
 Systems analysis & synthesis
 Statistical analysis
 Derivatives/ Integral analysis/ Transforms
 Numerical Methods
⇒ Soft Systems Modelling: includes solving some societal problems that are
not premised on quantification
 Religious issues
 Gender
 Race
 Communal disputes
 Bitterness
 Hostage taking/kidnapping
 Dehumanization etc.

• Systems Engineering Management Process

 4. How does Systems Engineering differ from other Traditional
Engineering Disciplines (i.e. mechanical, electrical etc)?

1. Focuses on the system as a whole (total operation) and its interactions with other
systems and environments. Looks at system from INSIDE and OUTSIDE. Migration
from Component level thinking to System level thinking.
Not only concerned with the engineering design of system, but also how external
factors constrain the design.
External factors such as:
• Identification of customer needs
• System Operational Environment
• Interfacing systems
• Logistic support requirements
• Capabilities of operating personnel

2. Primary purpose: to guide. System engineers are responsible for leading the concept
development (formative) stage of a new system development.

Traditional engineering disciplines: design decisions based on quantitative

knowledge.
System engineers: design based on qualitative judgements.

3. Systems engineering bridges the traditional engineering disciplines. Various

elements cannot be engineered independently from each other as they are part of
one complex system.
System engineers coordinate the design of individual elements to assure the
interactions between system elements are compatible.

Overlaps technical and human centred disciplines:

o Industrial engineering o Organizational studies

o Mechanical engineering o Administrative and
o Manufacturing engineering o Management related studies
o Control engineering
o Software engineering
o Electrical engineering
o Cybernetics
 5. Systems Engineering and Project Management

The engineering of a new and

complex system: Requires many people with
diverse skills, time and effort to
Starts with Exploratory stage: transform system from:
a new system concept is evolved to concept  operational use
meet a recognised need or
opportunity

When decision is made to engineer the

concept into an operational system, it MAJOR Such an enterprise is called a “project”
results in: ENTERPRISE Directed by a project manager and
staff.

Systems Engineering is a part of project

Management, planning and control of
management:
project fiscal, contractual and customer
relations is supported by systems Only the part that is concerned with guiding
engineering BUT not considered to be part the engineering effort itself:
of system engineering function
 Setting objectives
 Guiding execution
 Evaluating results
 Prescribing necessary correction to
keep project on course
Foundational Knowledge on Systems
Part 1: Chapter 3: [3.1, 3.2 & 3.3] of Systems Engineering Principles and
Practice and slide #2

Learning outcomes for section:

• The basics of systems should be understood, specifically focus on:

 Ability to define a system
 Identify and classify different systems into: virtual, real, engineered and non-
engineered.
 Understand the attributes and structural flow of systematic elements
• Be able to work through specific case study systems and be able to deploy concepts to real
environment

1. Definition of a System
~ systems are everywhere, but system engineers are not

Is a system a project? Or is a project a system?

A system ideally is not a project and a project ideally is not a system.

Project - is a system in the making! A project is thus a system of interrelated activities that
must be executed at a predefined time towards the accomplishment of a goal.
System - A system is a set of interrelated components or elements working together
towards a common goal.

Which between a system and a project comes first in the development

cycle?
A project comes first, and then the system.

When can humans be referred to as “a project” and when can they be

referred to as a “system”?
Pre-birth (formation period)—a project
Pre-birth (development period) to post-birth (development period) ---a system
2. Types of Systems

• SIMPLE/ COMPLEX SYSTEMS

Simple Systems:

Semi-Simple Systems:
A washing machine consists of a main clothes tub, an electric motor, an agitator, a pump, a
timer, inner spinning tub, various valves, sensors and controls and performs a sequence of
times operations and auxiliary functions based on an operation mode set by the operator.

A refrigerator, microwave, dishwasher, vacuum cleaner, radio ALL perform a number of

useful, systematic operations. However, these appliances involve only 1 or 2
engineering disciplines and their design is based on well-established technology.
THUS, THEY FAIL TO MEET THE CRITERION FOR A COMPLEX SYSTEM. (section 3)

Complex systems:
Complex systems have a hierarchical structure; they consist of a number of major interacting
elements, generally called subsystems.
 • OPEN/ CLOSED SYSTEMS
Open systems interact and exchange with their surroundings, whereas closed systems
don’t.

• NATURAL/ MAN-MADE SYSTEMS

Natural and Man-made systems can fall under both Engineered and Non-Engineered
systems, as will be explained in part 3.
• LINEAR/ NON-LINEAR SYSTEMS
• ENGINEERED/ NON-ENGINEERED SYSTEMS
• DETERMINISTIC/ STOCHASTIC SYSTEMS
• INTELLIGENT SYSTEMS
• SPECIALIZED SYSTEMS ~Specialised in respect to different engineering disciplines

3. Engineered vs Non-Engineered Systems

NOTE: Systems Engineering covers both Engineered and Non-Engineered systems

What are Engineered Systems?

 They are goal-seeking an purposeful systems

 Designed and developed with scientific and engineering theories for actualisation of
optimal performance
 Engineered systems involve the anticipation of risk, the goal to minimize production
cost and high ergonomic (relating to or designed for efficiency and comfort in the
working environment) impact --- customer usage satisfaction

Engineered System Non-Engineered System

Man-Made Systems: Modified/Semi-Natural Systems: Man-Made Systems: Natural systems:

 Bridges  Sand-filled/ reclamation  Disarrayed store  Living organisms

 Edifices (Buildings) environments room and ecosystems
 Machines  Surface water diversion/  A dump site etc  Planetary/ solar
 Artificial Humans Groundwater pumping/ system
(Androids or Channelization
Humanoid robots)  Cave dwelling
 Ecosystem for human habitation
 Enhanced human parts (Plastic
surgery, enlargement or
reduction of body parts)
4. Classes of Systems
Real Systems:
~This includes all physical systems

 All physical systems that have been mentioned earlier- either simple or complex or
engineered or not etc.
⇒ Such as Gautrain
⇒ Radar System
⇒ Pin
 Real systems can be either:
⇒ Man-made
⇒ Modified
⇒ Or Natural

Virtual Systems:
~This includes all non-visible or touchable systems

 System of broadcasted images [Man-made]

 Atmospheric systems [Natural]

5. Attributes of a System
⇒ A system must be associated with the following attributes; it can be associated
with more but never less:
• (O)bjective
• (B)oundary
• (S)ubsystems or components
• (I)nter-relationship or inter-connectedness of subsystems
⇒ Modularity
• Systems exist in modules/ blocks or sub-systems
• The measure of degree of independency of the respective system blocks or
subsystems is referred to as “modularity”
• The process of dividing a system into modules is referred to as “functional
analysis” which facilitates system analysis

6. Structure of a System
 Examples:

Telephone substation, with its distributed lines to the areas that it serves  system
Hotel and office building switchboards, with their local line  subsystems
And the telephone instruments  components of system

At the same time, a telephone substation may be regarded as a subsystem to the city
telephone system, and that, in turn, a subsystem of the national telephone system.

“Supersystems” – overarching systems like the

Examples of hierarchical systems:

SYSTEM

Communication Information
Material Processing Aerospace
Systems Systems
Systems Systems

Sub-Systems

Signal Networks Databases Material Preparation Engines

Components

Data Database
Signal Power Material Thrust
Displays Programs
Receivers Transfer Reactors Generators

Subcomponents

Signal Cathode Library Gear Reactive Rocket

Amplifiers Ray Tubes Utilities trains Valves Nozzles

Parts

Transformer LED Algorithms Gears Couplings Seals

The systems engineer’s knowledge
must extend to the understanding of
key characteristics of components
from which the system may be
constituted (largely through
dialogue with specialists)
So that they can select types and
specify performance and interfaces
with other components
Systems engineer’s knowledge stretches from highest
level, the system and environment, down through the
middle level of primary system building blocks
Design specialist’s knowledge must stretch from
lowest level of parts up through the component level.
That is where their domains “overlap” and where
effective communication is necessary

Horizontal boundaries of these

domains ~ continuity lines

Functional Building Blocks:

Information elements more than
Functional Elements ~ 3 basic entities on which systems operate twice the amount of material and
energy elements, and is thus split
• Information into 2
Content of all knowledge and communication
 Information Propagation ~ i.e. sensing and communication (e.g. radio
signals), to be referred to as signal elements
 Information Processing or (Stationary elements) ~ i.e. analysis and
decision processes (e.g. computer programs), to be referred to as data
elements
• Material
Substance of all physical objects
• Energy
Energizes the operation and movement of all active system components

Thus, Total of 4 classes of system functional elements:

 Signal – sense and communicate information

 Data – interpret, organize, and manipulate information
 Material – provide structure and transformation of materials
 Energy – provide energy and motive power
 SYSTEM FUNCTIONAL ELEMENTS

Functional elements (building blocks) are built out of physical embodiments: such as
material, or powered by electricity.

Example: A TV – main function is to process information from radio frequency signal and
turn it into sound and picture (thus a “signal functional element”), but the TV is built with
materials, uses electricity and it is controlled by a user who generates information inputs

This brings us to the concept of:

Physical Building Blocks (also known as component building blocks)

– consists of hardware and software (things rather than processes)
-They are component elements  one level below subsystems, two levels above parts

Component building blocks are split into different classes based on different design
disciplines and the technology they represent – 31 component types – and these are split
into 6 categories; these are summarised in table below.
Categories based on Components – things Functional elements
discipline or technology items needed for process - processes
type to happen

Example of a system build up from all building blocks:

Systems Complexity
Part 1: Chapter 1: [1.3] and Chapter 3: [3.6] of Systems Engineering Principles
and Practice and slide #3

Learning outcomes for this section:

• Understanding different organs and levels of system complexity

• Understanding the conglomeration of systems into larger systems
• Attributes, difference and domains of existence for complex system
• Understanding how to model systems complexity for quantification and classifications of
systems complexity
• Be able to identify systems needing systems engineering theories

1. Definition of System Complexity

Complexity of a system – attribute characterized by a network of interconnected entities with
a high level of difficulty and disorderliness, measured by:
As a system grows in complexity – the sub
and lower levels and their connection and
• Multiplicity
interaction with each other become more
• Diversity
complex.
• Intricacy and connectivity
We have practices in Systems
• Adaptability Engineering that allow us to deal with
• Metamorphosis of connected entities this complexity

2. Levels of System Complexity

1. Simple System [No degrees of freedom]
 Easily known within a short period [Known-knowns]
 Stable situation
 Relationship between cause and effect is clear

2. Complicated System [Tightly coupled systems]

 Not Simple, but still know-able
 [Known-unkowns]
 There is a range of right answers

3. Complex System [Loosely coupled systems]

 Not fully knowable, but reasonably predictable [Unkown-unkowns]
 Causes and effects can only be deduced
 There are no right answers

4. Chaotic system [De-coupled systems]

 Neither knowable or predictable
 Causes and effects are unclear
 System of Systems
(SoS)
2. Systems Conglomeration: Enterprise Systems
~Systems of Systems (SoS’s)
A single system may become part of a larger entity  Supersystem concept
Systems that are considered more complex than single systems: SoS’s and enterprises

Definition of SoS: A set or arrangement of systems that results when independent and
useful systems are integrated into a larger system that delivers unique capabilities.

Levels of SoS
 Could be completely integrated from early development phase, the independent systems
are designed for the SoS. (Simple system)

 Multiple systems could be loosely joined for a limited purpose or time span to perform a
needed mission (Complex system)

CATEGORIES OF SoS:
Ordered from how loosely to tightly coupled the component systems are:

Loosely coupled Virtual

 Lacks a centrally agreed upon purpose

 Lacks a central-management authority
 Large-scale behaviour emerges and may be desirable
 Relies on relatively invisible mechanisms to maintain it

Collaborative

 The component systems interact more or less voluntarily to fulfil purpose

 Agreed upon central purpose
 Standards are adopted
 No central authority to enforce them
 The central players collectively provide some means of enforcing and
maintaining standards

Acknowledged

 Have recognised objectives

 A designated manager and resources for an SoS
 Constituent (being part of a whole) systems retain their independent
ownership, objectives, funding development and sustainment approaches
 Changes in the system are based on collaboration between SoS and the
system

Directed

 SoS is built and managed to fulfil specific purpose

 It is centrally managed during long term operation
 The component systems maintain an ability to operate independently, buy
their normal operational mode is subordinated to the central managed
purpose

Tightly coupled
Systems of Systems: Attributes/characteristics
1. Operational Independence of individual System
 SoS composed of systems that are independent and useful in their own right
 If an SoS is disassembled into individual component systems, these
component systems should be capable of performing useful operations
individually from each other
2. Managerial Independence of Individual System
 Component systems of SoS can operate independently to achieve intended
purpose
 These component systems are individually acquired and integrated
 They can serve purposes that aren’t necessarily part of the larger SoS
3. Geographic Distribution
 Geographic dispersions of individual components in a system are often large
 Often these component systems only exchange information and knowledge
with one another
4. Emergent Behaviour
 SoS performs functions and carries out purposes that are not necessarily
associated with any of the individual component systems
 These behaviours are emergent properties of entire SoS and not the
behaviour of the component systems
5. Evolutionary Development
 Development of SoS is evolutionary over time
 Components, functions and purposes can be removed or added or modified
as experience of system grows over time
 Thus, SoS is never fully formed or complete
6. Self-Organisation
 An SoS has a dynamic organisational structure that is able to respond to
changes in the environment AND to change goals and objectives of SoS
7. Adaption
 Similar to dynamic organisation
 The very structure of the SoS will be dynamic and respond to external
changes and perceptions of environment

~Enterprise Systems
-An Enterprise could consist of many SoS’s

- Anything that consists of people, processes, technology,

systems and other resources across organisations an locations
interacting with each other and their environment to achieve a
common goal
(Government agencies and departments, cities or nations are
also enterprises)
 • The term ’enterprise’ is used to refer to human co-operatives such as companies,
institutes etc..as well as networks of enterprises.
• The term ‘business’ typically used to refer to the function perspectives on the
enterprise by its customers.
• The term ‘organisation’ of an enterprise is strictly meant as the constructive
perspective of the enterprise, thereby disregarding all function perspectives.

Enterprise Systems

Enterprise Systems Engineering [ESE] Enterprise Engineering [EE]

The application of systems engineering Typically refers to architecting,

principles and practices towards developing the development, implementation and
individual component systems of the enterprise operation of the enterprise as a whole

Physical Complexity
3. Modelling Systems Complexity Virtual Complexity
Recall definition of complex system , characterised by:

1. Multiplicity We will model the complex

2. Diversity system according to these
3. Intricacy and connectivity attributes
4. Adaptability and metamorphosis

Physical Complexity
1. Complexity based on multiplicity -

o Complexity based on Numbers -

o Complexity based on size, constituent parts, interatomic make-up and sectioning

o A combination of all of the above

2. Complexity based on diversity -

3. Complexity based on connectivity -

⇒
⇒

⇒ IF then

Physical Complexity

1. Complexity based on multiplicity -

o Complexity based on available functions –

o Complexity based on size, constituent parts, interatomic make-up and sectionings -

o A combination of all of the above –

2. Complexity based on diversity –

3. Complexity based on connectivity -

o
⇒

⇒ IF then
 4. Systems Requiring Systems Engineering
The characteristics of a system whose development, test and application require
systems engineering:
 Is an engineered product ---> satisfies a specified need
 Consists of diverse components that have intricate relationships with one another
---> multidisciplinary and relatively complex
 Uses advanced technology in ways that are central to the performance of its
primary functions ---> involves development risk and often a relatively high cost

EXAMPLES OF ENGINEERED COMPLEX SYSTEMS: Signal and Data systems

EXAMPLES OF ENGINEERED COMPLEX SYSTEMS: Material and Energy systems

Engineered or Complex system:

• Engineered product
• Contains diverse components
• Uses advanced technology
Systems Interaction
Part 1: Chapter 3: [3.4 & 3.5] of Systems Engineering Principles and Practice
and slide #4
Learning outcomes for this section:

• Use context diagram to show how systems interact with their environments and vice versa
• Effectively explain the concepts of interaction and interfacing in a diversified system environment
• Identify and differentiate the different types of interactive environments

1. Context Diagramming
What is a Context Diagram?

• It is a connectivity diagram used to show different types of interactions that exist

between a system and its external environment.
~Inter-interactions: interactions with a system and its external environment

• Can also be used to show the internal interactions that take place within a system as
rightly represented in the system’s structural diagram.
~Intra-interactions: interactions amongst the elements in a system

SYSTEM BOUNDARIES:

Identifying boundaries can be difficult – hard to identify what is part of the system and
what is part of the environment.
- the system will be taken as that of the product being developed since we are looking at
development side of SE

General notes:
- human users or operators are consider as external entities

CONTEXT DIAGRAMS CONSIST OF 3 BASIC ELEMENTS:

1. External Entities
All entities that the system will react with:
• Inputs to the system
• Output destinations from the system

2. Interactions
• The interactions between the external entities and the system
• The interactions amongst the elements of the system

The interactions are represented by arrows  these arrowheads represent the direction of
flow of a particular interaction

3. The System
• Single geographic figure on diagram
 • It is an oval, circle or rectangular object in the middle of the context diagram
• Only the name of the system is written withim

5 categories of things that can

be passed between system
and external entities:

• Data
• Signals
• Materials
• Energy
• Activities

EXAMPLES:

Coffee
Machine:

Automobile:
 Grading System:

2. Interfacing and Interactions

• External Interfaces
At the boundary between the system and the external entities
• Internal Interfaces
Between individual components within the system

Managing interfaces through:

 Identification and description of interfaces during the concept definition
phase
 Coordination and control of interfaces to maintain integrity of system during
engineering development, production, and subsequent system
enhancements

Interactions:
 Communication between two or more elements in a system is affected by the
interface connecting these two interacting entities.

Functional interactions are affected by physical interactions that flow across

interfaces:

 [Car’s travel direction] influenced by [driver’s hands on the steering wheel]

 [Traction or the rate of velocity] influenced by [tires of the car on the road]

Basic Interacting Media:

 Electrical
 Mechanical
 Hydraulic
 Human and
 Pneumatics
 Functional interactions and Physical interfaces

Interface Elements:

 Connectors
Facilitates the transmission of electricity, fluid, force, etc. between components
 Isolators
Inhibits such interactions
 Converters
Alter the form of interaction medium
These interfaces are embodied in components and subcomponents, which can be
thought of as interface elements

The function of:

 Making or breaking connection between 2 components
-i.e. enabling or disabling the connection between the two
-this is an important design feature, involved in system control
 A large portion of system
failures happen at interfaces:
~ It is the systems engineers
responsibility to ensure interface
 Connecting nonadjacent system components compatibility and reliability
-via cables, pipes, levers etc
-attention must be given to ensure that their interfaces are configures correctly

3. Types of interactive Environments

Quasi-functional Interactive environment
It is important to note the difference between primary and secondary interactions.
Primary – elements that interact with the system’s primary functions
Secondary – elements that interact with the system in an indirect, non-functional manner, such as:
physical supports, ambient temp etc.
Primary:

• Inputs and Outputs

The primary purpose of system is to operate on external stimuli or materials in such a
manner as to process these inputs in a useful way
• System Operators
All systems do not operate entirely autonomously but are controlled by human
operators (operator is part of the system’s environment)
Human-machine interface
• Operational maintenance
During a system’s operating life it is to be maintained in such a way as to meet its
requirements for system readiness and operational reliability
The system needs to be designed to provide access for monitoring, testing and
repairs

Secondary:

• Support Systems
The part of the infrastructure of the system on which it depends for carrying out its
missions.
It is necessary to provide interfaces that are compatible with and capable of utilising
these support systems
Such as: Filling stations and suppliers for automobiles
• System Housing
Stationary systems are installed in an operating site, which imposes compatibility
constraints on the system
Such housings can provide protection for system from elements; rain, humidity etc
• System handling and environment
Many systems require transport from manufacturing site to operating site, these
impose special conditions around which system must be designed

Inhibitors:

• Threats
External entities (either man-made or natural) that pose a threat to system
Natural example: weather
Man-made example: theft
System Design: Concept Development Stage
Part 1: Chapter 4: [4.1, 4.2, 4.3, 4.5, 4,6]
Part 2: Chapters 6, 7, 8 of Systems Engineering Principles and Practice and
slide #5

Learning outcomes for this section:

 Ability to:
 Define and differentiate between system development process and system life cycle
 Identify and explain the different phases of system design and development in the
concept development stage
 Adapt this knowledge to designing and developing systems in the real world
 Create functional block diagrams

1. Drivers of Sew Systems

What Defines a New System?

Design and develop an A major improvement on an

entirely new system from existing system
scratch

What drives a new system?

 A new need
Examples of “New Systems” Driven by need:
• Government legislation in the automobile industry for:
o Safety and Pollution control
o Fuel economy for cars/aircrafts and machines, due to hikes in global
fuel prices
 Technological opportunities
Examples of “New Systems” driven by technology:
• Space technology to meet important public/ military needs
• Automation of labour-intensive processes

2. Introducing Systems Design Process and Life

Cycle of a System
What is a Systems Development Process?
It is a chain of activities:

 From the time when the need for a system is recognised

 And a feasible technical approach is identified
  Through the concept design stage
 And through the developmental stage
 Up until the end of the engineering design and development stages

What is a System’s Life Cycle?

The term “system’s life cycle” is commonly used to refer to:

 Stepwise evolution of a new system

 From concept
 Through to engineering development
 And then on to production
 Through operation
 And ultimately disposal (when life cycle ends)

System Life Cycle Model

Principal stages in a system’s life cycle

The Principle stages above will be further broken up and discussed in following sections

3. Concept Design and Development

Concept Development stage in System Life Cycle

The parts of the concept development stage will now be broken up even further

3.1 Needs Analysis

These are the primary inputs
into the Needs Analysis Phase

ACTIVITIES FOR THE NEEDS ANALYSIS PHASE:

⇒ Operational Analysis [requirement analysis]:

The primary objective of the needs analysis phase is to show:
 A clear and convincingly valid operational need for a new system or a major
upgrade to a system
 Thus defining the system objectives
 OPERATIONAL ANALYSIS PROCESSES:
o Assessment of the operational deficiencies of the current
system
o Obsolescence – (the process of becoming obsolete or outdated
and no longer used) thus decided what to make obsolete
o Technically feasible approach
o Affordable Cost
o Acceptable level of risk
o Potential market opportunities
o Assessment of competitive products

⇒ Objective Analysis:
 A process of developing and refining the objectives of the system

 The product of this effort is an objective tree:

o Where a single or small set of top-level objectives are decomposed into a
set of primary and secondary objectives

When deciding whether a objective requires further decomposition; you

need to ask the following questions?

- Does the objective stand on its own in terms of clarity of

understanding?
- Is the objective verifiable
- Would decomposition lead to further understanding?
- Are requirements and functions readily implied by the objective?

General structure of an objective tree

 An example of an objective tree for a passenger vehicle:

Overarching
objective

Primary
objectives

Secondary objectives

⇒ Functional Analysis [function definition]:

 Typical activities include:
o Translating operational objectives into system functions that must be
performed
o Allocating functions to subsystems by defining functional interactions
o And organising them into a modular configuration

 The General Product of this activity is a list of functional requirements

FUNCTIONAL REQUIREMENTS:
- These refer to what the system should be able to do
- They are usually action orientated and describe the tasks or activities
that the system performs

⇒ Feasibility definition [physical definition]:

 Typical activities include:
o Visualization of subsystem implementation
o Visualizing the physical nature of subsystems
o Defining a feasible concept in terms of capability and estimated cost by
varying (trade-offs)

 The general product of this activity is a list of initial physical requirements

DEFINITION OF FEASIBLE CONCEPTS:

This covers but is not limited to:
 - Discussions of the development process/strategy
- Anticipated Risks
- Design approach
- Evaluation methods
- Production issues
- Concept of operations
- Some cost information on systems development and production

⇒ Needs Validation [Design validation]:

 Operational Effectiveness model:
o The degree to which a given system concept may be expected to meet a set of
operational requirements – Operational effective analysis

EFFECTIVENESS ANALYSIS INCLUDES:

- Operational modes of the system, and

- Non-operating modes:
 Such as transport, installation, maintenance and logistic
support
 System performance parameters:
 The inputs from the system model to the effectiveness
analysis are values of performance characteristics that define
the system’s response to its environment

LEVELS OF EFFECTIVENSS MEASURE: o A quantitative or qualitative metric of a

systems overall performance
o An MOE always refers to a system as
a whole

o A quantitative measure of a system’s

characteristics of performance of a
particular attribute or subsystem
o An MOP typically measures a level of
physical performance below that of the
system as a whole

OPERATIONAL SCENARIO:

 How to create operational requirements that truly represent the full operational situations:
o Extensive study of the operational environment
o Discussions with experienced users of the predecessor and similar systems
o A detailed understanding of past experience and demonstrated efficiencies of current
systems
o Establishment of the user priorities for the required improvements, in particular, those
that appear most difficult to achieve
 Storage of the system and its components
 Transportation of the system to its operational site
 Assembly and preparing system for operation
  Extended deployment in the field
 Operation of the system
 Routine and emergency maintenance
 System modification and upgrading
 System disposition
 System operational requirement:
o Deals with conversions of systems objectives into quantifiable measures for
subsequent phases ahead

THUS, we get the DELIVERABLES for the Needs

Analysis Phase

3.2 Concept Exploration

Transition from Needs Analysis Phase to Concept Exploration:

Thus the outputs/deliverables of the

Needs Analysis phase, become the
inputs for the Concept Exploration Phase

The Principle object of Concept Exploration Phase is to convert:

 The operational-orientated view of the system derived in the needs analysis

phase  into an engineering- orientated view required in the concept definition
and subsequent phases of development.

⇒ Operational Requirement Analysis [Requirement Analysis/ definition]:

  Analysing the stated operational requirements in terms of their objectives
[basically analysing data from needs analysis first step]

 Restating or amplifying (as required) to provide specificity, independence and

consistency amongst different objectives:
o To assure compatibility with other related systems
o To provide such information as may be needed for completeness

⇒ Performance Requirements Formulation [Functional Definition]:

 Translating operational requirements into subsystem functions

 Formulating the performance parameters required to meet the sated operational

requirements

⇒ Implementation of Concept Exploration [Physical Definition]:

 Exploring a range of feasible implementation technologies and concepts offering
a variety of potentially advantageous options

 Developing functional descriptions and identifying the associated system

components for the most promising cases

 Defining a necessary and sufficient set of performance characteristics reflecting

the functions essential to meeting the system’s operational requirements

⇒ Performance Requirements Validation [Design Validation]:

 Conducting effectiveness analyses to define a set of performance requirements
that accommodate the full range of desirable system concepts

 Validating and conformity of these requirements with the stated operational

objectives and refining the requirements if necessary

Thus we get the DELIVERABLES for

the Concept exploration Stage
 3.4 Concept Definition
The deliverables from Concept Exploration phase become the inputs for the Concept
Definition phase, the transition between these two phases is shows:

This phase is also known as the system architectural phase

⇒ Performance Requirements Analysis [Requirement Analysis]:

 Typical activities include:
o Analysing the system performance requirements and relating them to
operational objectives and to the entire life cycle scenario
o Refining the requirements as necessary to include unstated constraints
and quantifying qualitative requirements where possible

⇒ Functional Analysis and Formulation [Functional definition]:

 Typical activities include:
o Allocating subsystem functions to the component level in terms of system
o Functional Elements and defining element interactions
o Developing functional architectural products
o Formulating preliminary functional requirements corresponding to the
assigned functions

⇒ Concept Selection [Physical definition]:

 Typical activities include:
o Synthesizing alternative technological approaches and component
configuration
o Designed to performance requirements
o Developing physical architectural products
o Conducting trade-off studies among performance, risk, cost, and schedule
to select the preferred system concept, defined in terms of components
and architecture
⇒ Concept Validation [Design Validation]:
 Typical activities include:
o Conducting system analyses and simulations to confirm that the selected
concept meets the requirements and is superior to its competitors
o Refining the concept as necessary

Thus we get the

DELIVERABLES for the
Concept Definition Stage

4. Sample Functional Building Block

Functional Block diagram

EXAMPLE: Coffee machine

INPUT FUNCTIONS:

5. Accept user command (on/off)

6. Receive coffee materials
7. Distribute electricity
8. Distribute weight

TRANSFORMATIVE FUNCTIONS:

• Heat water
• Mix hot water with coffee grinds
• Filter out coffee grinds
• Warm brewed coffee

OUTPUT FUNCTIONS:

• Provide Status
• Facilitate removal of materials
• Dissipate heat

THREE EXTERNAL ENTITIES also identified:

• The user
• The power source (assumed to be an electrical outlet)
• The environment
System Design: Engineering Development Stage
Part 1: Chapter 4: [4.2 & 4.3]
Part 2: Chapters 10, 12, 13 of Systems Engineering Principles and Practice and
slide #6

Learning outcomes for this section:

• Be able to identify and explain the different phases of system design and development in the
engineering development stage
• Be able to adapt this knowledge to designing and developing new systems in the real world

Engineering Design and Development Stage

Engineering Development Stage Diagram in System Life Cycle

The parts of the Engineering Development Stage will know be broken up even further

1. Advanced Development Phase

• It should be noted that all new system developments do not have to go
through a formal advanced development phase if:
o All major subsystems are directly derivable from proven predecessors or
otherwise mature subsystems
o Their characteristics can be reliably predicted
 If all this is true then one can proceed to the Engineering
Design Phase

The inputs into the Advanced Development

Phase of the Engineering Development Stage,
are the outputs from the Concept Definition
phase in the Concept Development Stage

⇒ Requirements Analysis :
• Analysing the system functional specifications
o With regard to the functional specifications derivation from operational
and performance requirements 
o And the validity of their translation into subsystem functional
requirement

• Identifying components requiring development

o Assessment of component maturity via:
 Proven components with similar functionality and characteristics
 Proven components with similar physical construction, materials and
architecture
 Interplay amongst the functional interaction, physical interface and
operational environment
 Development of new components

⇒ Functional Analysis and Design:

• Typical activities include:
o Analysing the allocation of functions to components and subcomponents
o Performing analyses and simulations to resolve outstanding performance
issues

⇒ Prototype Development:
• Typical activities include:
o Identifying issues of physical implementation especially with regards to
unproven technology
o Determine the level of analysis, development and test required to reduce
risks to acceptable values

⇒ Development Testing:
• Typical activities include:
o Creating test plans and criteria
o Conducting tests of critical components

FURTHER MOTIVATION ON TESTING:

• Development testing is carried out in this phase. The tests are
carried out on components and subsystems usually by the
developer
• Developmental testing involves the engineered system being
tested within a series of test environments. Involves only developer
• Operational test involves engineered systems being tested in a
more realistic environment with the customer involved
TEST AND EVALUATION PROCESS OF SYSTEM ELEMENT
SYSTEM TEST AND EVAULATION TEAM

Thus we get the DELIVERABLES

for the Advanced Development
Stage
2. Engineering Design Phase
Transition from Advanced Development phase (outputs of this phase) to Engineering
Design Phase (become the inputs of this phase):

This phase deals with:

 Design component parts for reliability and maintainability among other things
 Fitting together of these parts to achieve an operating system that meets the
requirement analysis
 Producible within a prescribed and affordable cost
 Detailed consideration of the interfaces elements (both internal and external)
 The engineering design phase is where the design is first fully implemented
in hardware and software

⇒ Requirements Analysis :
• Typical activities include:
o Analysing the system design requirements for consistency and
completeness
o Identifying requirements for all external and internal interactions and
interfaces

⇒ Functional Analysis and Design :

• Typical activities include:
o Analysing components interactions and interfaces and identifying design,
integration and test issues
o Analysing detailed user interaction modes
o Designing and prototyping user interfaces
⇒ Component Design :
• Typical activities include:
o Laying out preliminary designs of all hardware and software components
and interfaces
o Implementing detailed hardware designs and software code after review
o Building prototype versions of engineered components

⇒ Design Validation:
• Typical activities include:
o Conducting test and evaluation of engineered components with respect
to functions, interfaces, reliability, maintainability and producibility
o Correcting deficiencies
o Documenting product design

Thus we get the

DELIVERABLES for the
Engineering Design

3. Integration and Evaluation Phase

The outputs from the Engineering Design Phase are the inputs into the Integration
and Evaluation Phase
 This phase is concerned with:
• Assembly and integration of the engineered components of the new system
• Qualifying the engineered components for the production phase and other post
development activities

⇒ Test Planning and Preparation:

• Typical activities include:
o Reviewing system requirements and defining detailed plans for
integration and system testing, and defining the test requirements

⇒ System Integration:
• Typical activities include:
o Integrating the tested components into subsystems and the subsystems
into a total operational system by the sequential aggregation (the
formation of a number of things into a cluster) and testing of the
constituent elements
Tested components  subsystems  total operational system

o Designing and building integration test equipment and facilities needed

to support the system integration process and demonstrating end-to-end
operation

⇒ Developmental System Testing:

• Typical activities include:
o Performing system – level tests over the entire operating regime and
comparing system performance with expectations
o Developing test scenarios exercising all system operating modes, and
eliminating all performance deficiencies

System Element test Configuration 1

 System Element test Configuration 2

⇒ Operation Test and Evaluation:

• Typical activities include:
o Performing tests of system performance in a fully realistic operational
environment under the cognizance of an independent test agent [control
test]
o Measuring degree of compliance with all operational requirements and
evaluating readiness of the system for full production and operational
deployment

Thus we get the

DELIVERABLES for the
Integration and
Evaluation phase
Design and Development Team Members:
o Systems engineer
o Systems Analyst
o System Architects
o Design Engineers
o Integration Engineers
o Test Engineers
o Other Engineering & Non-Engineering Professionals

Principal Participants and their estimated effort per developmental phase

Systems Engineering Management
Part 1: Chapter 5: [5.1 & 5.4]
Part 2: Chapters 9: [9.1-9.5] of Systems Engineering Principles and Practice
and slide #7

Learning outcomes for this section:

o Be able to differentiate between making in anticipated government or private sector project

projects and viability of existing projects
o Use the cost-benefit or benefit-cost ratio, occasionally linked to annuity or present
worth of costs or benefits for alternative decision making
o Deploy the quality function deployment chart in systems design exercise
o Discuss the fundamentals of risk in systems and categorise them using the risk chart

1. Alternative Decision Making

 We make decisions everyday from the moment we wake up until we go to bed
 Decisions are of different weights and scopes e.g.
o Decisions on what to eat for breakfast compares to decision on best location
to place a nuclear plant

 Decision making can be regarded as simple, when the decision is:

o Less technical and more deterministic in nature
o Relatively low degree
of risk
o Require mild
information and
intuitive reasoning
o Limited outputs

What differs simple decisions from

hard decisions, their:

 Input
 Output
 Organisation
 Integration
 Processing of information

What is trade-off analysis? A set of procedures utilized to make decisions where

there are a lot of alternative decisions.
 2. Quality Function Deployment
Evaluations of Public Alternatives or other Alternatives about to be
Implemented

• Evaluation of Public Alternatives

BENEFITS

BENEFITS

COST INCOME

The initial cost does not get multiplied

by the table number
HOW TO USE TABLES

IMPORTANT INFORMATION:

 Interest rate = 12 % = i (P/A, i, n) = (P/A, 12%, 50)

 Life of project = 50 years = n P/A  turning annual into present
worth
GO LOOK IN TABLES:

1. Look for heading with 12 %

2. Look in column (P/A,i,n) and row n = 50

Benefit cost ratio:

Benefits outweigh the costs in this case

IF BC < 1 then the costs outweighs the benefits
PROJECT A1

A/P  turning present

costs into annual costs

PROJECT A2
 • Evaluation of Alternatives Already in Existence

Trade-off criteria for a case study commercial software:

 Speed of operation: measured in minutes per run
 Accuracy: in terms of errors per 10 runs
 Versatility: in terms of number of applications addressed
 Reliability: measured by program crashes per 100 runs
 User interface: in terms of ease of operation and clarity of display
 User support: measured by response time for help and repair

Quality Function Deployment (GFD)

What is a QFD?

 A technique that helps to transform customer requirements into design parameters.

 It identifies all factors which can affect the ability of a design or product to satisfy the
customers
 This method was developed in Japan by Yoki Akao and Shigeru Mizuno in 1966 – to
help transform the voice of the customer into engineering characteristics for products
EXAMPLE:

Design parameters

Direct
Product comparison of
Customer features
requirements design with
competitors

Engineering
specifications
PRESSURE COOKER EXAMPLE

Vital Weight Determination Criteria:

 Cost of requirement
 Guiding contextual question
 Hierarchy of requirement
 Function of requirement
 3. Basics on Risk Management
What is Risk?

 It is an unpredictable or predictable situation that can negatively impact a system’s

performance

Risk Management? -The act of identifying and minimising risk in system development
Risk Management can be divided into 2 categories:

1. Risk Assessment
 Risk Planning
 Risk Prioritisation
2. Risk Mitigation
 Risk Handling
 Risk Monitoring
Risk Likelihood and Consequence Chart

Risk
Criticality

Risk criticality: (Impact of

failure)
Given the likelihood of risk – status of design

Risk Mitigation:

 Common methods of dealing with identified program risks, focused on

different elements:
o Design focused- intensified technical and management reviews of the design
o Component focused- special oversight of designated component engineering
o Complex unyielding integration- consideration of relieving critical design
components
 Common methods of dealing with risks from unproven elements:
o Components with unresolved advanced tech – special analysis and testing of
critical design items
o Unproven components – rapid prototyping and test feedback
o Components with new tech – initiation of fallback parallel (alternatives, “plan
b”) developments

THE END