Wits Transnet Centre of
Systems Engineering: TCSE
Partnering for Systems Solutions
Systems Engineering Overview
Lecture 14: Systems Engineering
Mr Nicolas Cloete-Hopkins
MECN 4020
1
1
Disclaimer & Referencing
• This presentation is issued for the party that commissioned it and for
specific purposes of illustrating ideas and concepts.
• It should not be relied upon by any other party or used for any other
purpose.
• Examples used herein do not represent the views of Wits University and
are based on publically available data for illustrative purposes only.
• We accept no responsibility for the consequences of this document being
relied upon by any other party, or being used for any other purpose, or
containing any error or omission that is due to an error or omission in data
obtained from external sources referenced herein.
• This document contains proprietary intellectual property related to
systems and should be referenced with consent from the Wits TCSE;
as follows:
Wits Transnet Centre of Systems Engineering (TCSE).
Introduction to Systems Engineering, Eskom Centre for System Dynamics.
May 2021.
2
Systems Engineering Competency
Source: Adapted from INCOSE UK Ltd; 2015
3
Lecture 14 Overview
What is Systems Engineering What is Systems Engineering?
Covered?
Systems Engineering Processes
Why Systems Engineering?
Systems Engineering Management
Plan (SEMP)
Additional Reference Material
4
Part 1: What is Systems Engineering?
Source: Text courtesy of systems-studio.com; Accessed 2017 5
Source: Image courtesy of Daily Quotes by duanemarino; Accessed 2017
5
What is Systems Engineering
• First, it is definitely
– NOT Project/Programme Management
– NOT Engineering/Construction Management
– NOT Confined to Engineering
• Essentially Systems Engineering transliterates as
“Wholes Creating” or…
• “synthesising wholes/systems from interacting parts
to perform with optimum effectiveness in their
operational environment”
Source: Adapted from Hitchins D.K. Systems World (2016) 6
• Systems Engineering is NOT Project/Programme Management; it is NOT
Engineering/Construction Management; and it is NOT even confined to Engineering
• The next two slides highlight two definitions for Systems Engineering from INCOSE and
Rechtin respectively.
6
What is Systems Engineering?
INCOSE definition
• An interdisciplinary approach and means to enable the
realization of successful systems through lifecycle while
considering the complete problem
– Cost & Schedule; Performance; Test; Manufacturing;
Training & Support; Operations; and Disposal
• Integrating all disciplines and specialty groups into a team
effort forming a structured development process that
proceeds from concept to production to operation.
• Considering both the business and technical needs of all
customers with the goal of providing a quality product that
meets the user needs
Source: Adopted as the INCOSE Definition for Systems Engineering – BKCASE Editorial Board. 2016. The Guide to
the Systems Engineering Body of Knowledge (SEBoK), v. 1.7. R.D. Adcock (EIC). Hoboken, NJ: The Trustees of
7
the Stevens Institute of Technology. Accessed 26 January 2017.
7
What is Systems Engineering?
Favoured definition
• “Systems engineering is a methodical, disciplined approach
for the design, realization, technical management,
operations, and retirement of a system.
• A ‘system’ is a construct or collection of different elements
that together produce results not obtainable by the
elements alone.
• The elements, or parts, can include people, hardware,
software, facilities, policies, and documents; that is, all
things required to produce system-level results.”
8
Source: Rechtin, E. (1999), Systems Architecting of Organizations: Why Eagles Can’t Swim
• The Rechtin definition builds on his definition of a system.
• Note the technical management process through lifecycle from concept through to
retirement of a system.
• The technical management looks to integrate all disciplines and speciality groups considering
both the business and technical needs of all customers ensuring the satisfaction of user
needs.
8
What is Systems Engineering?
(Self-directed Learning)
Source: YouTubeZA; “A Very Brief Introduction to Systems Engineering”; Luke Edelston;
9
08 November 2015; https://www.youtube.com/watch?v=BErtl_ZcGpw
• Luke Edelston, in his presentation “A Very Brief Introduction to Systems Engineering”, states:
• Systems Engineering is a bit of everything
• Systems Engineering involves everyone (note multiple views)
• Systems Engineering is accomplished by using a process called the V-diagram that
looks at the system through lifecycle
• Systems Engineering ensures the system is not just built according to the
specifications but also meets the customer (i.e. client) as well as the user needs.
9
Part 2: Systems Engineering Processes
Source: Text courtesy of systems-studio.com; Accessed 2017 10
Source: Image courtesy of Daily Quotes by duanemarino; Accessed 2017
10
Systems Engineering Processes
Standards
ISO/IEC 15288 & 29110
EIA 632
IEEE 1220
Source: Wallace C; University of the West of England; Foundations of Systems Engineering, 11
“Systems Engineering Process Models”; June 2005
• This slide highlights various standards associated with Systems Engineering.
• It should be noted that the standards are associated with differing stages of the systems
lifecycle from concept to decommissioning and disposal.
• IEEE1220 is only associated with the system under development.
• EIA632 is associated with the system from concept to transition to operations.
• ISO/IEC 15288 and 291010 are associated with the system through lifecycle. ISO/IEC
15288 “Systems engineering – system life cycle processes” highlights the different
Systems Engineering processes associated with a mature organisation practicing
Systems Engineering.
• ISO/IEC 29110 “Software engineering – lifecycle profile for Very Small Entities (VSEs)” is often
used by organisations looking to incorporate Systems Engineering (i.e. an immature Systems
Engineering organisation) – it is not as onerous as ISO/IEC 15288.
11
Systems Engineering Processes
Standards
Source: ISO/IEC 15288:2015 Systems and software engineering -- System life cycle processes 12
Source: ISO/IEC 29110:2016 Software engineering — Lifecycle profiles for Very Small Entities (VSEs)
12
Systems Engineering Processes
ISO/IEC 15288
13
13
Part 3: Why Systems Engineering?
Source: Text courtesy of systems-studio.com; Accessed 2017 14
Source: Image courtesy of Daily Quotes by duanemarino; Accessed 2017
14
Why Systems Engineering (1)
• Describe the system related to the actual situation
• Address systems development through lifecycle
considerations from ‘cradle-to-cradle/grave’
• Generation of potential credible system solutions taking
account of System-of-Interest and Containing System
• Selection of preferred solution at every level within the
system – this is to be selected through a formal decision
making process
• Determine and manage stakeholder viewpoints, concept of
operations and translation of needs into requirements to
develop a robust system
15
• Bullet 1: “Describe the system related to the actual situation”
• Systems Engineering provides tools/processes to ensure that the system is described
in the context of the actual situation (i.e. related to the root cause(s) of the problem;
within the actual context in which a decision needs to be made; and/or taking
cognisance of the future environment for which preventative or protective
contingency planning is required).
• Systems Engineering aids the process of seeing the “Bigger Picture” relevant to its
systems hierarchy; within its business and world view; as well as looking at it through
lifecycle (i.e. past, present and future).
• Bullet 2: “Address systems development through lifecycle considerations from
‘cradle-to-cradle and/or grave’”
• Systems Engineering provides tools/processes to ensure that the system is described
in the context of its lifecycle (i.e. not just in the context of a project or product
development lifecycle).
• Systems Engineering assesses various lifecycles to determine the appropriate
lifecycle for the system through lifecycle from concept through to decommissioning
and disposal.
• Bullet 3: “Generation of potential credible system solutions taking account of
System-of-Interest and Containing System”
• Systems Engineering provides tools/processes to ensure that the system is described
within its context (i.e. systems hierarchy).
• Drawing the systems boundary associated with the “System-of-Interest” and in the
context of the larger “Containing System” is paramount.
• Note System Definition slides
15
• Bullet 4: “Selection of preferred solution at every level within the system – this is to be
selected through a formal decision making process”
• Systems Engineering provides tools/processes to aid option selection through a
formal decision making process that incorporates a trade-off between requirements
based on options provided.
• Formal decision registers should be kept to track these decisions.
• Bullet 5: “Determine and manage stakeholder viewpoints, concept of operations and
translation of needs into requirements to develop a robust system”
• Stakeholder needs are captured by looking at the various viewpoints associated with
the system (note Architectural Frameworks).
• These needs need to be communicated as a story, so a Concept of Operations is
adopted to do this.
• The Concept of Operations answers the simple questions: Why, What, Where, When
and How associated with the system.
• INCOSE provides a guide to writing good requirements.
• Writing bad requirements rank annually in Project Management Institute
(PMI) as one of the primary reasons for projects going wrong.
• The INCOSE guide provides a process for determining and translating needs
to requirements – it should be noted that boiler plates can be used to aid
the writing of requirements and acceptance criteria should be captured
when capturing requirements.
15
Why Systems Engineering (2)
• Analyse interfaces and system functionality to develop a
solution that meets its key requirements
• Integration and verification of the system elements taking
account of inputs from differing disciplines
• Validation of the system against the needs of the
stakeholder/customer/user
• Transition of the system to operation
(i.e. the integration into the super-system)
• Configuration management and change control
16
• Bullet 1: “Analyse interfaces and system functionality to develop a solution that meets its key
requirements”
• Systems Engineering notes the importance of interfaces between the “System-of-
Interest” and its “Sibling Systems” within the context of the “Containing System”.
• Furthermore, the “System-of-Interest” can be broken down into its elements or
“Sub-systems”.
• These “Sub-systems” are also interconnected to get the desired Emergent Properties
of the system.
• Note System Definition slides.
• The “System-of-Interest”; the “Sibling Systems” within the “Containing
System” as well of the “Sub-systems” produce results not obtainable by the
elements or parts themselves.
• These can take the form of people, hardware, software, facilities, policies,
and documents; that is, all things required to produce system-level results or
desired Emergent Properties.
• Note the definition of a system by Rechtin.
• These outputs can also be described in terms of functionality associated
with the different layers within the systems hierarchy associated with
requirements written in line with the INCOSE guide to writing good
requirements.
• Bullet 2: “Integration and verification of the system elements taking account of inputs from
differing disciplines”
• The Systems Engineering V-model starts with concept or user needs at the top of the
left-hand side of the V-model flowing down to the design process at the bottom (i.e.
16
partitioning).
• The right-hand side of the Systems Engineering V-model depicts the integration,
verification and validation process from the design process at the bottom to
Transition to Operation or User satisfaction at the top.
• The titles in each of the boxes varies based on the context of the system and the V-
model employed, however the general process of partitioning and integration with
links across at every stage are consistent depicting testing, verification and
validation.
• It should be noted that the full systems lifecycle starts at concept and ends at
decommissioning and disposal with the “Vee” in the middle that constitutes the
project or product development process.
• A system will only be successful if it is satisfies the User. This implies that the needs
of the User must be understood and that their expectations should be managed
(note that disappointment = failure), but who are the Users (note CATWOE
mnemonic).
• The purpose of System Integration is to ensure that system parts or elements will
function as a whole when brought together at differing levels within the system
hierarchy. That is integration of “Sub-systems” to produce the desired Emergent
Properties as the functionality of the system (i.e. what it was designed for); or the
integration of the “System-of-Interest” with its “Sibling Systems” to achieve the User
Needs of the “Containing System”. This primarily involves identifying, defining, and
controlling interfaces, as well as verifying system functionality that require multiple
system parts or elements.
• Verification is the process of confirming that the output from a development phase
truly reflects, and is fully compatible with, the requirements for the phase (i.e. meets
what was written in the scope or specification). Verification is often seen as
“ensuring that we have developed the thing right!”
• Bullet 3: “Validation of the system against the needs of the stakeholder/customer/user”
• This occurs at the top of the right-hand side of the Systems Engineering V-model.
• Validation is the process of confirming that the output of the development phase is
fully compatible with its intended functionality and importantly use (i.e. User
Satisfaction).
• Validation is often seen as “ensuring that we have developed the right thing!”
• Bullet 4: “Transition of the system to operation (i.e. the integration into the super-system)”
• This is the Systems Engineering process that integrates the “System-of-Interest”
emanating from the development phase into operation interfacing with its “Sibling
Systems” to attain the “system-level results” or desired emergent properties.
• Bullet 5: “Configuration management and change control”
• Configuration Management is the Systems Engineering process for establishing and
maintaining consistency of a system’s performance, functional, and physical
attributes with its requirements, design, and operational information through
lifecycle.
• Captures baseline information (incl. requirements, designs, plans, lists, etc.).
• Baselines consist of Configured Items in Configured Documents.
• Change Control is the Systems Engineering process for making changes to Configured
Items.
• This is vital at the customer / supplier interface to avoid confusion and
16
“requirements creep”.
• It is essential to agree early how change requests will be handled
commercially.
16
Concept Generation
Legislative/ Cargo Owners/
Regulatory Shippers/Mines
Sibling Sibling
System System
Sub
Sibling
System
System
Sub Sub
System System
Sibling
Sub
System
System
Corporate/ Operations/
Commercial
Sibling Technical
System
17
• Refer to System Definition slides
17
Basic Concepts
18
18
Stakeholder Viewpoints and
Requirements Practices
• Follow a documented requirements process
• Consider all stakeholders and viewpoints
• Capture all requirements
• Analyse and refine the requirements
• Ensure each requirement is testable
• Specify the requirements
• Review the requirements
• Maintain traceability
• Manage the requirements
Source: Adapted from UCL Systems Lifecycle Module; December 2006 19
• Stakeholder requirements originate from one or more stakeholders (including the customer and the
users), and represent what the stakeholders require of the system.
• System requirements state what the system must do – the set of system requirements define what
the system must do to meet the stakeholder requirements.
• Derived requirements are new requirements needed to facilitate the design, resulting from the
functional and architectural design activities.
19
Stakeholder Viewpoints and
Requirements Practices
• Follow a documented requirements process
• Consider all stakeholders and viewpoints
• Capture all requirements
• Analyse and refine the requirements
• Ensure each requirement is testable
• Specify the requirements Requirements
• Review the requirements
• Maintain traceability
• Manage the requirements Qualification/
Acceptance
Criteria
Source: Adapted from UCL Systems Lifecycle Module; December 2006 20
20
Requirements Management
Translation of Needs into Requirements
21
Source: INCOSE Guide for Writing Requirements Summary
21
Requirements Management
Requirements/Sets of Requirements Characteristics
Requirement Statements Sets of Requirements
• Necessary • Complete
• Appropriate • Consistent
• Unambiguous • Feasible
• Complete • Comprehensible
• Singular • Able to be Validated
• Feasible
• Verifiable
• Correct
• Conforming
22
Source: INCOSE Guide for Writing Requirements Summary
22
The V-Model
Functional Decomposition, Integration, V&V
Current Operations Future Operations Demolition
and Support and Support and
Disposal
Architecture Operational
Development T&E and
Transition
System Integration
Design and Test
Hardware/Software
Acquisition
Progra
Managem
m
ent
INCOSE Systems Engineering Handbook v. 3.2.1 INCOSE‐TP‐2003‐002‐03.2.1 January 2011 23
• There are a number of different ways to present a System Lifecycle.
• The choice of System Lifecycle Model to apply will be determined by the type of project, the
project timescales, project novelty, etc.
• Traditionally Systems Engineers preferred the V-Model to present the System Lifecycle.
• The Vertical axis indicates the System Level, while the Horisontal axis represents Time.
• The top-left of the V starts with the Business Needs (often presented as the Business Case).
• Down the left leg of the V, Needs are confirmed through Requirements and then translated
to Specifications, Architecture Development and System Design.
• This left leg follows the processes of Decomposition, Disaggregation and Analysis.
• The bottom part of the V provides for obtaining all the hardware, software and firmware
elements needed for the System.
• Up the right leg of the V, the elements are integrated into aggregates, sub-systems and into
the main System.
• This right leg applies the processes of Integration, Verification and Validation.
• The future system must then meet the system characteristics initially stated in the System
Requirements for the then future system as indicated in the slide.
23
The V-Model
Concept of Operations (CONOPS)
Current Operations Future Operations Demolition
and Support and Support and
Disposal
Architecture Operational
Development T&E and
CONOPS
Transition
System Integration
Design and Test
Hardware/Software
Acquisition
Progra
Managem
m
ent
INCOSE Systems Engineering Handbook v. 3.2.1 INCOSE‐TP‐2003‐002‐03.2.1 January 2011 24
24
Concept of Operations (CONOPS)
• The Concept of Operations
(CONOPS) addresses the needs
and goals of the system
• Captures the operational and
support environments; required
functionalities; and desired
characteristics of the system
• “Communicates A Story” from
User’s point of view on Why,
What, When, Where, Who, and
How a system will be used
throughout it’s lifecycle
25
Source: California Department of Highway Patrol
• Good for inclusion in ‘All Views’ perspective of Architectural Framework
• Note: CONOPS is not an Architectural Framework
• Helps with communication with non-technical stakeholders
25
Verification vs. Validation
Verification Validation
Meets what is written in the Meeting the
contract or specification spirit of the contract
‘building the system right’ ‘building the right system’
“Was the right question asked?”
• Verification : The process of confirming that the output from a development phase truly
reflects, and is fully compatible with, the requirements for the phase. “Ensuring that we
have developed the thing right!”
• Validation: The process of confirming that a product is fully compatible with its intended
functionality and use. “Ensuring that we have developed the right thing!”.
26
Summary: Why Systems Engineering
• Understanding the problem
• Capturing all stakeholder viewpoints
• Translation of needs into requirements
• Capturing requirements and functionality and enables
structured development of specifications
• Holistic evaluation/ objective decision making
– Identification of all possibilities and through lifecycle thinking
– Selection of preferred solution
• Integrated solution that is both verified and validated
• Traceability of decision making
27
27
Summary: Why Systems Engineering
28
28
Part 4: Systems Engineering Management Plan
(SEMP)
Source: Text courtesy of systems-studio.com; Accessed 2017 29
Source: Image courtesy of Daily Quotes by duanemarino; Accessed 2017
29
Systems Engineering Master Plan (SEMP)
SEMP is the technical master plan that integrates and
co-ordinates all elements of the system (i.e.
hardware, software, people, processes, policy,
procedures, etc.); that is everything working together
to make the system work
The SEMP also assists in objectively evaluating
technical and operational maturity
30
30
Systems Engineering Master Plan (SEMP)
What is the System
of Interest and
Conceptual Design
Containing System
Functionality and
Through Lifecycle Interfaces
Thinking Integration,
Planning Interface
Verification &
with PM
Validation
Transition to
Operation
Stakeholder Configuration
Viewpoints and Management and
Requirements Change Control
31
31
Why Systems Engineering?
Provides an Integrated Technical Strategy
Ensuring there is an Integrated STRATEGY
on day one of the Project.
If things change (and they will change),
the remedy will become more apparent
if the process is logical and based on
sound reasoning.
32
Part 5: Additional Reference Material
Source: Text courtesy of systems-studio.com; Accessed 2017 33
Source: Image courtesy of Daily Quotes by duanemarino; Accessed 2017
33
Systems Engineering – Reference Guides
Source: Meadows D.H. Thinking in Systems: A Primer, Paperback. Chelsea Green Publishing Company. ISBN: 978-1-60358-055-7,
August 2015
Senge P. 1990. The Fifth Discipline: The art and practice of the learning organization, 6th Edition. New York: 34
Doubleday/Currency. ISBN: 0-385-51725-4, March 2006
34
Additional Reference Material
Systems Engineering Handbook
Source: INCOSE (2015). INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities,
4th Edition. John Wiley & Sons, Inc. ISBN: 978-1-118-99940-0. August 2015
• The International Council on Systems Engineering (INCOSE).
35
Additional Reference Material
INCOSE BKCASE®
Source: INCOSE BKCASE Editorial Board. 2016. The Guide to the Systems Engineering Body of
Knowledge (SEBoK), v. 1.7. R.D. Adcock (EIC). Hoboken, NJ: The Trustees of the Stevens Institute of
Technology. Accessed 26 January 2017).
• The International Council on Systems Engineering (INCOSE).
• BKCASE (Body of Knowledge & Curriculum to Advance Systems Engineering - pronounced
"Bookcase") is an international effort to develop a systems engineering body of knowledge
(SEBOK) and a Graduate Reference Curriculum for Systems Engineering (GRCSE - pronounced
“Gracie”)
36
Additional Reference Material
ISO/IEC Systems Engineering Standards
Source: ISO/IEC 15288:2015 Systems and software engineering -- System life cycle processes 37
Source: ISO/IEC 29110:2016 Software engineering — Lifecycle profiles for Very Small Entities (VSEs)
37
Thank you
Nic Cloete-Hopkins
[email protected]
38
