Introduction to Systems

Engineering

Hassan Berbia
ENSIAS 2021

Credits to Incose, NASA, Northrop Grumman, Vitech, SEBOK, M. Di Natale

 Agenda

Introduction
What is a System and System Thinking?
What is Systems Engineering?
What is the Systems Engineering Process?
What is the System Life Cycle?
What is the V-Model?
What are requirements?
What are Model-Based Systems Engineering?
Introduction to SysML
Hands-on
What is a System?
Key Terms
MIL-STD-499B
EIA/IS-632 & JOC
MIL-STD-499B
EIA/IS-632-1994

Pr
cts

oc
du

es
o
System

se
Pr

s
People

System

Extracted by J Clark from MIL-STD-499B Draft – 1993.

Provided with the permission of EIA from EIA/IS-632-1994.
Copyright 1995 EIA. All rights reserved. Products Processes People

Credit to Northrop Grumman

What is Systems Thinking?

 Everything and everyone (from the universe to the nucleus

of an atom is a system, a SoS, and a subsystem of a higher-
order system
 Everything and everyone that exists/existed (things,
people, thoughts, sayings, writings, actions, etc.) uses/used
the systems engineering process
 You see everything and everyone as a system, a SoS, a
subsystem of a higher-order system, and a member of a
SoS
 You “Stand on the standards”
 System Thinking

What is system thinking:

Observe:
1. Identify the boundaries of the system and identify its exchanges
with the outside world.
2. See the whole to establish the links between events and
situations in Independent, singular and unpredictable.
3. Change the angle of view and change the focus of its
observations to understand.

Identify influences:
1. Nothing is completely isolated and independent.
2. Understand the needs without forgetting those that are hidden or
not formulated.
3. Know how to differentiate an effect and its causes, always go
back to the causes primary effects.
 System Thinking

Understand the system:
 Identify the elements of the system, understand their arrangement and
identify their interactions.
 Identify incoming and outgoing flows, inventories accumulated by the
system.
 Observe the evolution of the system over time.
 Imagine use cases for relevant stakeholders (contextual interactions).

Challenge yourself:
 To doubt one's own convictions and to look beyond the first intuition.
 Accept the pause (temporarily) and resist the urge to find a solution(at
once).
 Before making a choice, always assess the feasibility of several
solutions, and then identify the reasons for this choice.
 Seek win-win solutions.
Systems Engineering
What is Systems Engineering?
Problem and Solution Space for Systems Engineering

Problem Translate Solution

Space to Space

Systems
Engineering
 Systems Engineering-
Terminology

Terminologies - Definitions
 System stakeholders (expression of need)

A stakeholder is an entity concerned with the system, its design, its use, its
impacts on a given context and hence the stakeholder is likely to issue
expectations or constraints on the system.

Different stakeholders are involved throughout the life cycle of the system, thus
having different viewpoints on the system.
 Objectives (expression of need)

On the basis of the purpose and the mission, the objectives characterize the need
qualitatively and quantitatively, by measurable data: What performance? At what
cost? For what length of life? For which stakeholders?
 Architecture (solution)

Architecture is the fundamental organization of a system represented, on the one
hand, by its constituents, their interrelations, their relations with the environment
and, on the other, by the principles guiding its conception and evolution.

The architecture of a system is a representation, at a given level of abstraction
and granularity, of a system in the form of a structure identifying the constituent
elements of the system and their interactions.
The Need for Good SE
Balance (Technical, Cost, & Interfaces, Integration, &
Schedule) Interoperability

Human Operational
Element Environment

Credit to Northrop Grumman

SE Standards
Sheard and Lake
Scope and Detail of the SE Standards

Breadth of Scope

ISO/IEC 15288:2003-2008
Depth of Detail

EIA/IS 632:1994

EIA 632:1998

IEEE 1220:1994-2005
Provided and modified by John Clark with the permission of Sarah Sheard from
Sheard, Sarah A., Software Productivity Consortium (SPC), and
Lake, Jerome G., Systems Management international (SMi),
Systems Engineering Standards and Models Compared, July 1998.
ISO/IEC 15288 System Life Cycle Stages - vice
Phases
ISO/IEC TR 24748-1

Provided with the permission of ANSI from ISO/IEC TR 24748-

1. Copyright 2010 ISO. All rights reserved.
What is the System Life Cycle?

Provided with the permission of INCOSE from INCOSE SE Handbook, Version

3.2.2 Copyright 2011 by INCOSE.
Systems Engineering vs. Project
Management
Project Management

Systems Engineering Project Control

• System Design • Technical • Planning • Management

Planning
• Requirement Management • Risk
Definition • Technical Management • Integrated
Planning Assessment
• Technical • Configuration
Solution • Technical management • Schedule
Definition Control Management
• Data
• Product • Technical Management • Configuration
Realization Assessment management
• Assessment
• Design • Technical • Resource
• Decision Management
Realization Decision Analysis
• Evaluation Analysis • Documentation and
Data Management
• Transition
• Acquisition
management
 Key Systems Engineering
Functions
Verification and
Validation
Project Requirements
Objectives and Development and Architecture and
Constraints Management Design

Verification Verification and

and Validation
Validation

Project Objectives
Met,
Operations Ready for Operations
Concept
Systems Engineering
Management Plan
Vee Model for ISO 15288
 • •

• 2
What is the V-Model? (cont)
CSM

System
End V-Model
Start

Entity
V-Models

1 System
2 Subsystems
4 Lowest Configuration Items (LCIs)
Dual V-Model excerpted, modified by John Clark (Northrop Grumman), and Copyright 2005 by
The Center for Systems Management (CSM) Inc., and used by permission of Kevin Forsberg.
 System Decomposition

PBS Example
 System Decomposition

WBS Example
Requirements
What is requirements

What Is A Requirement?



If it prescribes that something must be accomplished, transformed, produced, provided, or
constrained . . . it’s a requirement!

Requirements state WHAT is needed – the product team determines HOW the requirement will be
accomplished

Requirements Management -



Integration of requirements from multiple and separate sources (statement of work, specifications,
standards, customer discussions, management directives) at program start - minimizes post-design
integration of hardware and software

Analysis of these integrated requirements for ambiguities, conflicts, and omissions so the project team
operates to a single, validated set of requirements (i.e., team members begin from the same starting
point)

Identification and resolution of issues - identification of those requirements needing further analysis,
simulations, or trade studies to establish quantitative and measurable objectives

Conversion of analytical results into balanced, derived requirements

Controlled evolution of requirements throughout a product’s life cycle

Incose August 1997 Systems Engineering a primet

 What is a requirement?

RATIONALE STAKEHOLDER

Emitted_by
Supported_by ASSUMPTION
Conditioned_by

Associated_with
REQUIREMENT RISK
Result_from
Verified_by
TRADE_OFF
Allocated_to

VERIFICATION PRODUCT
PROCEDURE
 Where Do Requirements Come From?

At the highest level, from your scoping exercise


Stakeholder and Customer need statement

Defined goals and objectives

Assumptions and constraints

Concept of Operations
Project analysis and trade studies

Figures of merit
Project system hierarchy

What functions must the system and subsystem do to perform the
mission?
 Requirements Also Come From Organizational
Standards and Government Regulations

Guiding Documents, such as


Launch Vehicle payload/user requirements

Standards-based Requirements

Regulation Requirements
Further operational considerations

System boundaries and external interfaces
 Are other systems driving some of your design requirements, like
interfacing with the International Space Station?

The operating and supporting environments
 What requirements does the space environment impose on your
system?

Use of legacy systems
 What requirements originally designed to?
Requirement Process
 Requirement Analysis
Is the requirement traceable to a user need or operational
requirement?
Is the requirement redundant with any other requirement?
Is the requirement consistent with other requirements?
Is the requirement unambiguous and not subject to
interpretation?
Is the requirement technologically feasible?
Is the requirement affordable?
Is the requirement verifiable?

Does the set of requirements cover all of the user needs and
operational requirements?
Is the set of requirements feasible in terms of cost, schedule,
and technology?
Can the set of requirements be verified as a whole?
 Requirement Modeling
This is an essential task in specifying requirements
Map elements obtained by elicitation to a more precise/“formal” form
Help better understand the problem
Help find what is missing or needs further discussion
Different modeling languages

Informal:
 natural language

Goal-oriented modeling (GRL)

Functional modeling:
 UML / SysML
 SDL (Specification and Description Language)
 Logic, temporal logic
 UCM (Use Case Maps)

Domain Modeling
 DSLs, UML Profiles
 The Cost of Error Recovery or a Requirements Change
Increases Dramatically with Project Phase
Why requirements
change:
• New requirements are
10,000 added or discovered
• Priorities change
Change a Requirement
Cost to Fix an Error or

• New understanding of
1,000 the difficulties of an
implementation approach
• Measured performance
does not meet required
100
performance

10

1
Requirements Design Fabrication IV & V Operations &
Analysis Maintenance
Project Phase
 Requirements Development


Requirements are distributed from the broad mission
scope into the architecture that defines the project

Requirements bound the scope of the problems to be
solved so we know when we have done well enough

A hierarchy of traceable requirements ensures that the
project is building only what is required, i.e., no frivolous
activities

A hierarchy of negotiated requirements ensures a
balanced system design

Requirements are the basis for the project’s verification
and validation efforts
 Poorly written or unverifiable requirements maybe
fatal !
Requirements are Decomposed
Following the Functional Architecture

Requirements are decomposed via three methods — flow-

down, allocation and derivation.

Requirement flow-down is a direct transfer since a
subsystem provides the capability.
 E.g., The requirements for spacecraft communications may be entirely
flowed-down from the spacecraft system requirements to the spacecraft
communications subsystem requirements.

Allocation is a quantitative apportionment from a higher
level to a lower level and for which the unit of measure
remains the same. Examples include mass, power, or
pointing.
 A 1,000 kg spacecraft may allocate 200 kg, 500 kg and 300 kg to its
three subsystems.
 Not always a linear combination - e.g., system pointing performance is
typically combined via Root-Summed-Squared (RSS).
Requirements are Decomposed
Following the Functional Architecture


Requirement derivation is an apportionment that depends
on the specific implementation.
 E.g., A car may have a 0-100 kph performance requirement that
is used to establish a requirement for a maximum mass and a
minimum horsepower.
 Or a launch vehicle’s performance might establish a maximum
satellite mass for a given altitude and orbital inclination.
 Requirements Traceability and Hierarchy


Once mission level requirements have been decomposed to lower
levels, traceability identifies the relationship between requirements.

Knowing the source and dependencies between requirements is
valuable since if a requirement changes, traceability can be used to
determine the implications of that change.

Level 1 Level 2… Level 3

Total
Solution
Reqt 1.0 Level 1

Reqt 2.1 Level 2

Reqt 2.0 Reqt 2.2
Reqt 2.3.1
Reqt 2.3 …
Reqt 2.3.2
Level 3
Reqt 3.1.1
Reqt 3.1.2
Reqt 3.0 Reqt 3.1 …
Reqt 3.1.3
…
Reqt 3.1.4
 Types of Requirements

Functional - Requirements which define what an item must do.
 The system shall provide communications between the ground and the
spacecraft.

Performance - Requirements which define and quantify how well an item
must accomplish a particular function.
 Provide communications over what range, with what data rate and how often

Constraints - Requirements that capture operational, environmental, safety
or regulatory constraints.
 The communications system shall use X-band frequencies.
 The communications system shall operate with a base plate temperature of at
least -30 C and at most 40 C.
 The maximum RF power density shall be less than 10 watts/m 2
 Design standards (e.g., metric units, programming language, etc.)

Verification - Requirements capture how confidence will be established that
the system will perform in its intended environment.
 All performance and functional requirements shall be met while the system is in a
vacuum chamber with 2.5 Kwatts/m2 of visible light illuminating the z-side.
 Types of Requirements

 Stakeholder Expectations

Musts

Wants
 System Requirements

What the system must do

Prioritized “wants”
 Imposed Requirements

Environmental Requirements

Standards-based Requirements
 Interface Requirements
 Regulation Requirements
 Implementation Requirements
 Verification Requirements
 Requirement Families

System If parent requirements are…

Requirement Parent • INCOMPLETE
• INCORRECT
• AMBIGUOUS
Children • CONFLICTING, or
• UNVERIFIABLE

Subsystem Subsystem
Peers
Requirement Requirement Then…children and
subsequent generation
Requirement Parent
requirements will be
progressively worse.

Element

Requirement Child
 The Decomposition of a System Also
Creates Interface Requirements
System
There can be interfaces
Requirement
between each subsystem
and between each
subsystem and the
system.
Interface Requirements
The functions, performance,
assumptions and
Subsystem Subsystem constraints of these
Requirement Requirement interfaces much be
defined and captured in
Requirement
interface requirements.
Interface ownership must be
Interface Requirements established - since the
responsible individual or
Element organization for an
interface is not always
Requirement obvious.
 Levels of Requirements

Increasing Increasing
Level of Levels of
Detail Management
System

Segment

Element

Subsystem
 Requirements Hierarchy

• Requirements are Product Breakdown Structure

established for every entity
in the system hierarchy –
the Product Breakdown
Structure (PBS).
• The Product Breakdown
Structure reflects the
system architecture.
• A Requirements Document
must be established for
each entity in the PBS.
• There should be an
individual responsible for
each Requirements
Document.
MBSE
What are Model-Based SE and Model-Driven
Engineering?

Structural
Plans

Plumbing
Schematics

Electrical
Schematics
What are Traditional Deep-Dive SE and Layered
MBSE?

(SERIAL SE) (CONCURRENT SE)

What are SysML Diagrams?