Fundamentals of Systems

Engineering and Design

Bringing “Complex” Systems Into Being:
Review: Complex Systems
Requirements Analysis
& Start Conceptual Design Project

ARO 2011L
Week #3 Lecture
Prof. Dobbs
Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 1
 Course Outline

1 Course Overview;
Personality styles;
Systems Engineering:
What and Why?
2 Form new teams and Blanchard- Chapter 1. HW #2-1 Pers. Style &
choose Lead 1 and System Science and Project Management
Deputy 1, System Engineering Score and Improvement
Science and Plan; HW 2-2 Natural
Blanchard - Chapter 2.
Engineering; Ethics in Bringing Systems Into Being WBS & INCOSE
Industry
3 Bringing Systems Into Chapter 3. Needs analysis, HW Week #3-1 My
Being; Requirements Conceptual System Design System Candidate for
Analysis; Start System Engineering Team Design Project, HW
Conceptual Design Processes 3-2, -3, -4
Title, 1.1 – Chart 1.6

Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 2

Review: What is Systems Engineering?
• Systems engineering is
– A concept
– A process
• There are some common threads
– Top-down approach
– Life-cycle orientation
– Definition of system requirements
– Interdisciplinary or team approach
• There is NO
– Recipe
– Roadmap
– Equation
– Right way or wrong way

It is about determining what is important and seizing the initiative.

Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 3

 Today’s Topics

• Complex systems
• The engineered system attributes
• Requirements Analysis and Flow-down
• System life-cycle engineering.
• System design considerations
• Start Conceptual Design Project

Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 4

 Examples of “Complex” Systems

• F/A-18 Fighter
• Wildfires
• Global warming
• Cal Poly Pomona
• Space Station
• Assembly Line
• Autonomous vehicles
• Army Battalion
• Kitchen appliance
“Complex”: Multiple “Lock and Key” interfaces between system components.
Week #3 - 5
 Complex System: Human Protein Processes in the cell with
“lock and key” interfaces (feed-back and control process diagram)
• “Proteins are
the majority of
the workers in
our cells”
• “Thousands
and thousands
of proteins and
processes each
having “Lock
and keys”
following two
programming
languages
(DNA/RNA &
Proteins)”

Dr. Steve Alas,

Biology Prof, CPP,
Jan 2021
 Most complex system in nature?
Human Metabolic Network System Diagram in the Cell

From:
Dr. Steve
Alas,
biology
prof at
Cal Poly

ARO 2011L Week #3 - 7

 The Engineered System:
Attributes (Review)
• Functional purpose (Why does the system need to exist?)
– Identified need
– Operational objective
• Brought into being and operate over a life-cycle (How long will it be in existence?)
– Need
– Phase-out
– Disposal
• Combination of resources (What do I need to create the system?)
– People
– Information
– Facilities
– Money
• Composed of subsystems and related components that interact (What other
components of the system are impacted by other components ?)
• Part of a hierarchy that is influenced by an external environment and external
constraints (What other external systems are impacted by my system and visa-
versa?)
• Embedded in the natural world and interacts within it

Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 8

Real Systems Engineers Focus On

What the entities do

before determining

What the entities are

For a new product, start the design process with a clean
sheet, do not show a bias for a pre-conceived design
solution
Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 9
Think System!

Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 10

 What is a Requirement?
• A statement that defines a capability or attribute or
relationship that the system must perform or have
• Can define a process or specification that must be followed.
• Can define a schedule milestone date.
• Includes design, cost, schedule and certification/approval
constraints from all the stakeholders
• Has a reference number #
• Must be a complete sentence, lack ambiguity, and define a
specific scope.
• The statement that must have a topic, a measureable value
or characteristic, and a constraint where or when it applies!
• Written so that different people all interpret it the same way
• Must be achieved for the design to be approved
If it mandates that something must be accomplished, transformed,
1/16/2021
produced, or provided, it is a requirement – period. Week #4 - 11
 The Requirement Environment
• All projects begin with a statement of requirements, that flow from
the NEEDS ANALYSIS
• Systems Engineers job is to extract the customer requirements from the
RFP (“System Level Requirements), and derive the requirements
from the team’s approved design (“Derived Requirements”)
• Identifying the clear-cut characteristics of a requirement which can be
used by both requirements analyst and design teams.
• Are categorized into multiple classes of requirements (i.e., Performance
or functional requirements, management requirements, reliability
requirements, process requirements, constraints, etc.) according to a
designated specification document structure (“The Spec”).
• All requirements are captured and “locked-down” in a requirements
database management environment (Ex. CORE database)
• Cannot be changed without a Change Control Board (CCB) approval
The customer requirements drive the contractor’s design processes and
technical approach to meet the program objectives to achieve the
1/16/2021
program goal that will meet the customer Needs Week #4 - 12
Aerospace Engineering-Fundamentals of Systems Engineering
 Two Categories of Requirements
• Primary or “Systems Level” Requirement (SLRs)
– Flows down from the Program Objectives and stated by the customer in the RFP (Request for Proposal) to
meet the “Program Goals” to meet the customer’s ”Need”
– Those requirements levied on a contractor/producer under force of contract. The identification is
unambiguous.
– An example would be: “T0.0-1 (0.0= System level in the WBS) The space system shall have a safety loss of
crew of 1 in a minimum of 10,000 missions for ascent, re-entry and landing mission segments, including
populations around the launch site”
– Includes Design Reference Missions (DRMs) as SLRs
• Derived Requirement (DRs)
– Generated from the primary requirements, i.e. based on the contractor’s chosen design approach to achieve
the primary or “System Level” requirement.
– An example would be: “T1.1.7 (1.1.7= Crew Escape element in WBS) The Loss of crew metric requires a
crew escape system that will protect the crew with a separation and survive functional reliability of
99.9999% for ascent, re-entry and landing mission segments”.
– The derived requirement for a crew escape system is derived from the System Level requirement “T0.0-1
The space system shall have a safety loss of crew of 1 loss in a minimum of 10,000 missions for ascent, re-
entry and landing mission segments…”
• How do you change a requirement?
– Why change? Change in the customer needs? Requirement not achievable with physics?
Costs too much? Found a better way to meet the Objectives? Etc….
– Change a Primary or “System Level” requirement: a contract change is required with
approval from the customer (costs $$ and time, AVOID SLR changes if possible!!!).
– Change a Derived requirement: the decision to change rests with program management
• Change must be within the scope of the parent primary requirement, other wise will have to change the
System Level Requirement from which it is derived.

The SLRs come from the customer in the RFP,

the DRs are defined by the contractor to achieve the SLRs
1/16/2021 Week #4 - 13
 Types of Requirements;
used in the Req. Ref. #
• T= Technical Requirement
– Design Ref Mission, Max speed, payload weight capability, crew
safety, maintenance turn-around time, dogfight kill ratio, etc.
• Programmatic Requirement
– M = Management or Schedule
• Conduct tech reviews, Launch window date, Initial Operating
capability, etc.
– C = Cost
• System acquisition cost, development cost, life cycle cost,
operations cost, etc.
– E = Environmental impact
• Pollution parts/million, noise, sonic boom, radiation, etc.

ARO 2011L Week #3 - 14

 The Format of a Requirement
• Ref. # + a complete sentence requirement statement
• Example: Reference #:
• Req. type (T,M,C,E),
• WBS box # (0.0, 1.1.2, etc.) where the requirement applies,
• dash serial number

T0.0-1 The crewed elements of the space system shall have a safety
loss-of-crew ratio of 1 loss in a minimum of 10,000 missions for ascent,
re-entry and landing mission segments for the flight crew and ground
population.
Three elements in a requirements statement:
1. Topic (subject of the requirement)
2. Metric (or way to measure it to verify the requirement is met)
3. Constraint (where or when it applies)

T0.0-1 (1) The crewed elements of the space system (2) shall have a safety loss-of-crew
ratio of 1 loss in a minimum of 10,000 missions (3) for ascent, re-entry and landing
mission segments for the flight crew and ground population.”
A requirement statement has a Reference number and a statement with 3 elements
Week #3 - 15
ARO 2011L
 What is a FOM?
• FOM’s = “Figures of Merit”
– These are the most important System Level Requirements that are key “DESIGN
DRIVERS”, i.e. the requirements that determine your system design key design
variables that will be compared in a trade study of various design concepts.
– FOMs are DISCRIMINATORS in selecting the best design architecture
• Example: FOM 2 - T0.0-2 The total upper-stage payload stack for travel to the asteroid, landing, and sample
return shall not exceed 63,470 pounds.
• Example Design driver: Upper stage structural materials’ strength / weight ratio (if too low will exceed
63,470 pounds to meet strength requirements)
• There are many different materials and architectures design approaches to accomplish this for an
“analysis of alternatives” architecture trade study; a design that is BETTER that the FOM gets extra points
in the evaluation.
– There are usually 6 to 10 FOMS used as the scoring criteria in a trade study
covering technical, cost, schedule and environmental requirements
• Non-FOM’s –
– System Level Requirements that are just “Go-dos”, i.e. not usually a design
variable, like “The spacecraft exterior visible surfaces shall be painted
white”. = same approach for all design candidates.
– Also can be a “KEC” (Key Evaluation Criteria), like T0.0-6 Maximum vehicle
length cannot exceed 360 ft. to accommodate existing launch pads.
• All architectures cannot exceed this length, but being shorter has no advantage.
• Used for early elimination of design architectures that cannot meet the KEC

FOMs are a sub-set of the SLRs that are used as key evaluation criteria in trade studies
ARO 2011L Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 16
and Design
 Requirements Analysis Process example:
Space Launch Initiative Program
1.1 Program Need (problem to be solved): The current fleet of Space Shuttles
are aging which increases the risk of catastrophic failures and refurbishment
cost
1.2 Program Goal (to satisfy the Need) : Replace the Space Shuttle with a safer,
more cost effective system for servicing the International Space Station

Traceable to the next higher level

1.3 Primary Program Objectives (Methods to meet the Goals):
Flow-down

1. Synthesize multiple RLV architecture families into a commercially

viable architecture meeting NASA requirements and addressing DoD
needs
2. Perform technology R&D tasks to mature technologies in support of a
development decision in 2006
1.4 Design Reference Missions (DRMs)
1.5a Primary or “System Level” Requirements (to meet the DRM’s)
1.5b Derived Requirements (to meet the SLR’s)

1/16/2021 Week #4 - 17

Week 4 – 11-b
Space Launch Initiative 10 Primary System Level Requirements that are also FOMs
Customer ‘s Primary (or System Level ) Requirements flow down from the Program Objectives and
Flow Down to the Contractors’ Design Drivers leading to Derived Requirements

T0.0-1 Safety = T0.0-2 Reliability C0.0-1.Cost

1/10,000 LOC = 1/1000 LOM (Launch Price )
For the flight crew and Design-driver ->
ground population
=$1000/Lb. to
Derived Requirements:
Design Drivers-> • Engine cluster reliability LEO
Derived = xx.xxx% ;
Requirements: is a key design and
•Loss of crew requires a decision driver
crew escape approach • One engine out is a key Design-driver ->
• Any Critical 1 failure must driver Derived
be eliminated or prevented • Significant impacts from Requirements:
• Engine fleet size and turn around •Maximize #
safety, time launches/year
reliability • X # Multiple payload
and hazard manifest/ launch
reduction can only be
achieved with a new
engine
1/16/2021 Week #4 - 18

Week 3 -24b
Derived Requirements Flow from 10 Primary Program System Level Requirements
C0.0-2 C0.0-3
Commercial C0.0-4 Legal
Business Case = available & fixed
Convergence =
= Company IRR & cost liability
100% of
Gov. NPV insurance
commercial
thresholds met
elements also Design-driver-> Derived
support NASA Requirements: Design-driver-> Derived
missions to reduce • Capture NASA, Requirements:
Commercial, • 3rd party
cost DoD, and liability insurance
Design-driver long term • Government property
-> Derived growth markets insurance
Requirements: • Technology risk at an •Vehicle loss insurance
• Common designs for acceptable level at 2006 • Payload insurance
commercial, NASA, DoD FSD decision • Mission abort (re-launch)
requirements • NASA/DoD FSD insurance
•Off-the-shelf component investments in
reliability is adequate for Government unique
crewed missions or funded requirements Week #3 - 19
by NASA or DoD
 Derived Requirements Flow from 10 Primary Program System Level Requirements

M0.0-1 M0.0-2 T0.0-3

Programmatic Regulatory Assured
= Meet first-flight = Meet requirements Access =
target dates at of all regulatory Crewed and cargo
budgeted cost agencies access to ISS with
Design-driver-> Design-driver-> 2nd Gen RLV
Derived Derived grounded
Requirements: Requirements: Design-driver->
•Technology readiness • FAA 6XX RLV FAR Derived
dates must align with defined by 2003
Requirements
architecture development • Identify and address all
need dates relevant regulations from • Rapid response with all
• Use lessons learned from 16 other Federal critical 1 elements
previous programs agencies, and also State different than
agencies •SLI design
• Identify any regulatory
issues from International
1/16/2021 agreements and law Week #4 - 20
 Derived Requirements Flow from 10 Primary Program System Level Requirements
M0.0-3
Evolvability
= Capability for
long-term SLI
payload growth &
apply SLI designs
to heavy lift for
future HEDS
missions
Design-driver->
Derived
Requirements:
• Apply RLV elements to
other future space
programs
• Need fairly accurate
estimations of long term
1/16/2021 Week #4 - 21
mission needs
Week 3 -24e
 Start Your System Design Project
Team Leader – announce to the class
• what is your teams chosen System to
“Design”?
• Why you chose this system?

ARO 2011L Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 22

and Design
 Conceptual Design Review Presentation # 1 SCORE CARD Score: Tech
Content
Score:
Chart Clarity 2.5,
Team # _____ , Date _____________ 0- 5 ** Oral Pres.2.5
Team Lead #1 _______________________, Title _______________________________ 0-5 ##

0. Title page + Table of Contents, Score x 2

1.1 Needs analysis, 1.2 Goals, 1.3 Objectives; 1.4 DRM’s; 1.5a System Level Requirements
, 1.5b Derived Requirements, 1.6 System Life Cycle
Score x 7
2. Organization Chart – 2.0 Conceptual design, 2.1 – Org. Charters. Score x 2
3. Trade Study: 3.1 Candidate Architectures, 3.2 Sys.Level FOMs 3.3 Feasib. Ana.: Step 4;
3.4a Trade Matrix; 3.4b Quantif. & Down Select (Bar chart) ; 3.5 Select Best Arch. &
Rationale statement. Score x 6
4. Work Breakdown Structure – 4a. Functional, 4b. Product, 4c. Product + Functional
Allocations. Score x 3
5. Operational requirements: 5.1 DRMs, 5,2 Perf & Phy Param, 5.3a Ops Deploym, 5.3b
Ops Deploy Diagram, 5.4 Operational Life Cycle, 5.5 Utilit. Reqmts, 5.6 Effect. Facts., 5.7
Environment. Score X 8
6. Maintenance & support concept diagram
7. Five Tech Performance Measures 7a – Table, 7b – Plot. Score x 2
8. Functional block diagrams 8a- Operations, 8b-Maint. & Support Score x 2
9. System spec
10. Compliance Matrix.
11. Summary
Sub-Total (175,175 max)
Total (350 max)

** 5=1/16/2021
Showed Complete key content, 4= most , 3 = about
Aerospace half, 2= less than 50% , 1=
Engineering-Fundamentals little content,
of Systems 0= missing chart
Engineeering Week #4 - 23
## 5= All charts clear and readable + oral clear and good volume, 4 = Most charts + most oral, 3= about half charts half oral, 2= less than half, 1= little,
0= missing chart
 Templates for Conceptual
Design Presentation #1
• FOLLOW the formats
on the TEMPLATEs,
including headers and
questions!!
• Just fill-in the blanks!
ARO 2011L Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 24
and Design
Company Customer
Logo Logo

Title of your Project

Conceptual Design Review
ARO 2011L Section __ Team # ___, Company Name
Date Submitted _______
Prof. Dobbs

Date Submitted _______

Team lead 1: ________________ Picture or graphic
Team Deputy 1 ______________ illustrating your topic
(NOT a photo, your system
Members: _______________ does not exist yet at CoDR/SDR!)
_______________ “etc.

1/16/2021
ARO 2011L-X
Aerospace Engineering-Fundamentals of Systems Engineeering Week #4 - 25
Cal Poly Pomona Aerospace engineering Department
 0.2 Conceptual Design Review Presentation # 1, Page # Author
Table of Contents Team #____ Initials

0. Title page + Table of Contents

1.1 Needs analysis, 1.2 Goals, 1.3 Objectives; 1.4 DRM’s; 1.5a System Level Requirements , 1.5b
Derived Requirements, 1.6 System Life Cycle

2. Organization Chart – 2.0 Conceptual design, 2.1 – Org. Charters.

3. Trade Study: 3.1 Candidate Architectures, 3.2 Sys.Level FOMs 3.3 Feasib. Ana.: Step 4; 3.4a
Trade Matrix; 3.4b Quantif. & Down Select (Bar chart) ; 3.5 Select Best Arch. & Rationale statement.

4. Work Breakdown Structure – 4a. Functional, 4b. Product, 4c. Product + Functional Allocations.

5. Operational requirements: 5.1 DRMs, 5,2 Perf & Phy Param, 5.3a Ops Deploym, 5.3b Ops Deploy
Diagram, 5.4 Operational Life Cycle, 5.5 Utilit. Reqmts, 5.6 Effect. Facts., 5.7 Environment.

6. Maintenance & support concept diagram

7. Five Tech Performance Measures 7a – Table, 7b – Plot.

8. Functional block diagrams 8a- Operations, 8b-Maint. & Support

9. System spec
10. Compliance Matrix.
11. Summary

1/16/2021 Aerospace Engineering-Fundamentals of Systems Engineering Week #4 - 26

Company
Logo
X.X-y Title of Chart Customer
Logo

• Header or template question 1

– Your answer
– Your answer
• Header or template question 2
– Your answer
• Header or template question 3
– Your answer

Pictures, plots, tables

Yellow Box: The main message “Take-away” of the chart in a concise sentence
with 3 elements: Claim, value, proof to back your claim if you can, Week #5 - 27
NO “Motherhood” (“Our design is the best”) or “Fluff wording” (“This chart clearly shows”….)
 Requirements Analysis Process
1.1 Needs Analysis
Define what problem are you trying to solve and the deficiency of the current systems (the “Need” is not the
solution!) When does it need to be solved?
1.2 Program Goals
What is your customer’s and your company's overall approach to meet the Needs (i.e. for solving the problem
or filling the deficiency)? Mission? Over-all Tech Approach? Over-all schedule?
1.3 Objectives

Traceable to the next higher level

What specifically do we want to accomplish on the project to meet the customer and company Goals (business, technical,
programmatic target values)? The objectives can become the Key Figures of Merit” (most important requirements with
Flow-down

measurable values!)
1.4 Design Reference Missions - what will the system accomplish in operation? Mission profile or Concept of operations?
1.5a Primary System Level Requirements - Requirements from the customer’s RFP; a sentence with the topic and
measurable value. The company’s system design must meet these requirements.
• FOM’s (Figures of Merit) : These are the System Level requirements that are key “DESIGN DRIVERS”,
i.e. the requirements that determine your system design key design variables that will be compared in
a trade study of various design concepts, like Example: FOM 2 - T0.0-2 The total upper-stage payload stack
for travel to the asteroid, landing, and sample return shall not exceed 63,470 pounds.
• Example Design driver: Upper stage structural materials’ strength / weight ratio (if too low will exceed 63,470
pounds to meet strength requirements)
• There are many different materials and architectures design approaches to accomplish this for an “analysis
of alternatives” trade study.
– Non-FOM’s – System Level Requirements that are just “Go-dos”, i.e. not usually a design variable, like “The
aircraft exterior visible surfaces shall be painted white”. = same approach for all design candidates.
1.5b Derived requirements – a. Requirements the company defines, based on their chosen design approach architecture
design, that will contribute to meeting the System Requirements, and/or b. Your clarification of a customers System Level
Requirement that was missing a key value or constraint.
b. Example: Customer System Level Requirement= “Req. C0.0-3 The F-35 aircraft acquisition cost must be more
affordable compared to the F-15E aircraft”. Can you design for “…more affordable…” ?? No!
Derived requirement to clarify the SLR “ Req. 1.0-1 The aircraft acquisition cost must be 10% lower compared to the F-
15E aircraft acquisition cost of $56M in 2015 dollars”. Can you design to the added metrics? Yes.

All derived requirements in 1.5b must trace back up to the System Level Requirements in 1.5a, which must trace up to the
28
Objectives which must trace up to the Goals which must trace up to meet the Needs! Otherwise, get rid of that requirement!
 Requirements Analysis Process Step 1.1
Chart #:
applied to your Team Design Project
- Team in-class break-out activity
1.1 Needs Analysis – define a summary statement
(“Elevator speech”) that states:

Traceable to the next higher level

a. The problem that needs to be solved,
Flow-down

b. The key deficiencies of the current systems that

cannot solve the problem.
1.2 Goals – list desired key program accomplishments that help meet a need (“Design a system to ..,” “Perform a feasibility study to
determine…”, “Flight demonstrate a technology that will….,” etc.
1.3 Customer objectives & Company’s objectives
1.4 Design Reference Missions – Mission profile also called the “Concept of Operations” or “Con-ops”
1.5a System Level Requirements (RFP) – one example that relates to an objective
1.5b Key System Level Requirements FOM’s & Resulting Attributes – a FOM that will drive what the system needs to look like
1.5c Derived requirements (based on architecture) – one example that meets a System Requirement above

A clear, concise and compelling NEEDS statement will often

determine if your program gets funded or not! 29
 1.1 Needs Analysis - Program Name
• Summarize the overall external stakeholder need in a clear, concise and compelling
“elevator speech” in one or two sentence(s) and put in your yellow message box at
the Top of the chart … examples:
NEED: “Near Earth Objects (Asteroids and Comets) may threaten life on earth due to impacts. The NEO
material and mass properties need to be adequately defined to enable the design of methods to prevent
NEO impacts on the Earth”

NEED: “The US commercial air transportation’s system economic health is vulnerable to foreign control
due to a significant dependence on foreign petroleum supplies and fuel emission environmental
regulations. Emerging non-fossil, renewable domestic produced fuels need to be demonstrated to be
technically and economically feasible for next generation commercial aircraft.”

NEED: “New foreign fighter aircraft designs may have superior combat kill ratio’s against current US
fighters due to revolutionary stealth and long range radar/IR sensing capabilities. Advanced technologies
30
are needed for use in US fighter upgrades or for new designs to ensure tactical air dominance.

• The key external stakeholders and their needs are:

– Who is (are) the customer and why do they need this system?
– What part of the public sector needs or is impacted by this system and how are they impacted?
– Which government agency needs or is impacted by or impacts this system?
– Identify other external stakeholders and why/impacted by this system?
• The key internal stakeholders and their needs are:
– Why does your company or agency need to design and produce this system?
– Why do the company employees need to participate in creating this system?
– Identify other internal stakeholders and why they need/impacted by this system
 1.2 Program Goals
• The primary Customer goals of the program are:
– Start with 1 sentence overall goal. Identify the type of program i.e. a design study,
a technology demonstrator, a production system, a operations support program,
etc. Should relate to what missions it is supposed to perform.
Example: “1.Perform a conceptual design level study to determine the technical and cost
feasibility of a soil sample return from a NEO asteroid under the NASA cost constraints
and available technology maturity in 2021, to enable adequate definition of the NEO
material and mass properties for future NEO impact prevention missions.”
Example: “ 1. Conduct a commercial flight demonstration of an un-modified Boeing 747-
400 to validate the performance, emissions and commercial economics of sustainable
biofuel mixed with kerosene.”
Example: “1. Design, develop, test and manufacture a new fighter aircraft system for the
US Air Force that is superior to emerging foreign systems in air to air combat kill ratios at a
unit acquisition cost not to exceed $60M with IOC in 7 years.”
2. Add other key customer goals… etc.goal

• The Primary Company goals are:

1. Win the Conceptual aircraft design competition in May 2015, 2. Break into a new
market, 3. Develop advanced technologies to win future systems contracts, 4. Make a
12% profit, 5. etc..
31
Summary key Message….
 1.3 Program Objectives
Customer Objectives My Company’s Objectives
1. 1.

2. 2.

3. 3.

4. 4.

5. etc….. 5. etc….

Message…. 32
 1.3 Program Objectives (Example)
Customer Objectives Our Company’s Objectives
1. Identify a list of NEO Potential 1. Win a NEO-PHA study contract with zero
Hazardous Asteroids (PHA), their Earth profit to break into the NASA exploration
impact probability with date, and market
potential Earth damage
2. Select a NEO/PHA asteroid for a 2. Use the contract to further develop our
sample-return mission for sample return mission simulation, systems design, and cost
to Earth by 2027 estimating tools and experience
3. Design up to 3 NEO/PHA conceptual 3. Apply evolving Model Based Systems
design sample-return mission for a Engineering methods to minimize the risks,
architecture concepts, their development and time needed for planning and status
times, and life cycle costs tracking during the SD and PD design phases
4. Down-select a NEO sample-return 4. Leverage this successful contract into
mission architecture that fits within NASA winning the NEO/PHA next phase follow-on
NEO total $2B Program cost and
perform a preliminary system design and
development for Detail Design go/no go
design decision in 2021
5. Identify advanced technologies
needed for further development
The NEO/PHA concept design study will define the most cost and schedule effective Mission Architecture for a33
PHA sample-return mission at least 5 years before the first potential NEO fly-by
 1.4-1 Design Reference Missions
(one chart for each mission# 1.4-2, etc)
• What are the key missions that your system must
perform?) (Take astronauts to the moon; ground support
by air to ground attack; etc.)
• Sketches of the mission trajectory segments

Mission #1: Air to Ground Attack Mission segments:

Supersonic dash Climb to 30,000 ft, subsonic cruise

Climb to 30,000 ft

Dive to 15,000 ft
Take-off from
Land on carrier
Aircraft Carrier
Drop guided weapon

1/16/2021 Message of this chart with key take-away; including values or dates etc. Week #4 - 34
 Example: Design Reference Missions based on a DoD
Reusable Launch System (RLS) Missions of Interest
Mission #1: Rapid Global Strike (ASC/FB)
Functional Need: Rapid (few hours) ground ops turn around from landing to re-launch
Functional deficiency: Engines & Thermal Protection System require no refurbishment;
between missions
~2020+ IOC
SOS FSS ACC
(Sub-Orbital Strike) (Future Strike System) $20B+ Dev Acq
Mission #2: Routine, Flexible Mil. Space Trans. (SMC/XR)
Functional Need: Rapid configuration of satellite payload for mission
Functional deficiency: Rapid integration of satellite into launch vehicle ~2015 TAD
RLS
SOV
(Space Op. Veh.)
MSP
(Mil Space Plane)
AFSPC
Customers: Mission#3: Low Cost Space Transportation (NASA MSFC)
VA Functional Need: Dual use of military launch system for civil use to reduce ops cost
PR Functional deficiency: Small Military vs. heavy NASA max payload lift capability needs
ML ~2015+ IOC
ASC STS
(Space Trans Sys)
2&3 Gen NASA
SMC
AFSPC $20B+ Dev Acq
NASA Multiple Missions are needed to justify
1/16/2021 AerospaceReusable Launch
Engineering-Fundamentals of SystemsSystems
Engineeering Week #4 - 35
 What is a FOM?
• FOM’s (Figures of Merit)
– These are the System Level Requirements that are key “DESIGN
DRIVERS”, i.e. the requirements that determine your system design
key design variables that will be compared in a trade study of
various design concepts,
• Example: FOM 2 - T0.0-2 The total upper-stage payload stack for travel to the asteroid,
landing, and sample return shall not exceed 63,470 pounds.
• Example Design driver: Upper stage structural materials’ strength / weight ratio (if
too low will exceed 63,470 pounds to meet strength requirements)
• There are many different materials and architectures design approaches to
accomplish this for an “analysis of alternatives” trade study.

• Non-FOM’s –
– System Level Requirements that are just “Go-dos”, i.e. not
usually a design variable, like “The spacecraft exterior visible
surfaces shall be painted white”. = same approach for all
design candidates.
ARO 2011L Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 36
and Design
 1.5a System Level Requirements
(Must be a sentence with a topic, a number or way to measure it, and constraints. Derived from the program RFP and objectives )
Req. type: TR = Technical Requirement ; Programmatic requirement: M= management or schedule, C = cost type
Validation Method by CoDR/SDR: Parametric Analysis, Engineering Analysis, Simulation, Similarity, Wind tunnel test, Ground test, Flight Demo,
etc.
RFP Req. # WBS FOM Requirement statement Validation Met at
para # # # (a complete sentence; topic and measurable Method at SDR CoDR/
that is
affected
? metric/value, and a constraint)) SDR ?
by the
requmt.

1.0 T0.0-1 0.0 N/A The primary mission will land on an NEO asteroid, Trajectory analysis Yes
collect regolith samples, and return the sample to
earth by 2025
2.0 T0.0-2 0.0 1 Example: The NEO/PHA system architecture will Rover system Yes
return an adequate amount of regolith sample simulation
excavated from at least 4 locations orthogonally
separated by a distance of at least 5 % of the mean
asteroid diameter within 8 hours time.
3.0 T0.0-2 0.0 N/A Example: The total system stack will be launched by a Verified rocket Yes
Delta IV heavy rocket operated by ULA from Kennedy availability from ULA
Space Center.
T0.0-3 0.0 2 Example: The total upper-stage payload stack for Parametric weight No, 5%
travel to the asteroid, landing, and sample return shall analysis over
weight,
not exceed 63,470 pounds. but will be
reduced
by PDR

1.1 C0.0-1 0.0 3 Example: The selected mission architecture total Cost analysis using Yes
system life cycle cost estimate cannot exceed $2B in CER’s
projected 2021 dollars.
Etc. T0.0 0.0 Etc…

1.2 M0.0-1 0.0 N/A Example: The mission launch window is December 23 Manuf & logistics Yes
to Jan 9, 2021 from Cape Kennedy similarity with MRO
program Week #4 - 37
The key system level requirements are defining a system architecture that can achieve an asteroid
sample return for the NASA $2B budget with a sample returned to earth by 2025
 1.5b Derived Requirements
(Derived from System Level Requirements in Chart 1.5a & answers to questions on Charts 5.1-5.7 & Chart
6.0. Must be a sentence with a topic, a number or way to measure it, and constraints)
Req. type: TR = Technical Requirement ; Programmatic requirement: M= management or schedule, C = cost type
Req#: Req.Type-+WBS#-series #, Ex: TR1.1-1 = Tech req+WBS1.1(lander) -1 first requirement for the lander.
Validation Method by CoDR/SDR: Obsevation, Parametric Analysis, Engineering Analysis, Simulation, Similarity,
Wind tunnel test, Ground test, Flight Demo , etc.
Deriv Derived WBS # Derived Requirement statement Validation Met at
ed from that is
affected
(derived from Attributes in chart 1.5b, which are method by CoDR CoDR
Req. System by the
requirement
derived from a system level requirement ) /
# Level SDR?
Req.#
C1.1-1 C0.0-1 1.1 lander Examples: The lander vehicle total acquisition cost shall not Parametric based Yes
vehicle exceed $15M in 2020 dollars. Cost analysis
TR1.1-1 T0.0-3 1.1 Lander The total weight of the lander including maneuver fuel and all Parametric based Yes
vehicle surface ops equipment shall not exceed 15% of the total upper- Structural Weight
stage payload stack estimation
TR2.1-1 T0.0-1 6.0 The “adequate” regolith sample material shall weigh 4 Kg (on- Observation of the No, but
Asteroid Earth weight) assuming a material density of 1/ 1.6g/cm^3, sample return container
volume will
Regolith excavated from at least 4 locations orthogonally separated by a container volume be enlarged
Sample distance of at least 5 % of the mean asteroid diameter within 8 drawing 15% during
PDR
hours time.
M0.7-3- M0.0-1 7.3 The manufacturing assembly facility with all required Similarity with MRO Yes
2 Manuf. manufacturing equipment shall be ready for the all spacecraft program start-up time
and manufacturing time
manufacture by June 1, 2018.
to support launch date

Etc.

Etc,

1/16/2021 Week #4 - 38
Message of this chart with key take-away; including values or dates etc.
 Example of a Derived Requirement that did NOT
derive from a System Level requirement
• B-1A bomber- Derived Requirement:
B-1A – 4 were built
– “T1.3.2 Each of the nacelle inlets will have
actively controlled deformable walls (AICS) to B-1B – 100 were
built
control the A2/A1 area ratio to enable the F101-
GE-102 engines to produce 30,000 pounds of
thrust from Mach 0 to 2.2”.
– AICS added $M cost, significant weight, reliability
issues, and maintenance complexity
• However, there was no System Level Mission Area 1
requirement that needed Mach >1.2 AICS
– Mach 2.2 was an added “desired“ speed to out-run Automatic
Soviet fighters, but the mission was Mach 0.95 at 500 Area 2 Inlet Control
ft. AGL where fighters could not fly Mach 2.2 (choke pt.) System
(deformable
• B-1B aircraft deleted AICS and saved $$, inlet walls)
complexity, and weight!
Max Mach for B-1B = 1.2 due to deletion of AICS, but it Engines
meets all mission requirements
Week #3 - 39
Image: https://lh3.googleusercontent.com/proxy/pqvnqZj-Bg_pZ9Tr3XEIS6F_WVwWXkOi3Iu1onQRHeAKrdiXTKvmPMOxRaB0PtgAuA8q0RhK-
NBMAAYFreBPqiqJvJ8
 1.6 Life Cycle Schedule for ____ (notional space system example)
Objective - Example: Deliver Crew and Cargo to Orbiting Space Station & Emergency Crew Return

Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7 Year 8 Year 9 Year 10 Year 10 Year 11 Year 12 Year 13 Year 14 Year 15-30

Program Announcement SDR/CoDR PDR CDR Crew Crew & Cargo

Emergency
Needs/Mission Feasibility Approach & landing Return Transfer
Tech Demo RFP
SDR/CoD flight control data bases Un-crewed space
reentry, descent, and landing demo
Capability at Capability
RFP Space Station
Tech Demos Ground and Flight Technology Demos
Proposals Aero/Heating
wind tunnel, Concept System
component Proposal Conceptual Design
sub-systems Math Model
SDR/CoDR Verification
SRR

PD level Tech Demo Flight Test

Prelim Prelim.
Design Design Prototype
Proposal Flight Test
PDR

Production
Detail Design Detail Vehicle Flt
Proposal Design
Test
CDR
System Production

PRR System Operations

FRR Add. Verf. flights
1st System Disposal
Operation
s Flight
Week #3 - 40
Message of this chart with key take-away; including values or dates etc. Week 3 – 18b
 Individual HW # 4-1
ARO 2011L Prof. Dobbs
Name _______________ Section ___ Date _______
• Read the Aviation Week Article below: “Mending Fences – Overly
complex requirements add to problems buying weapon systems
at the Pentagon”, Aug. 4, 2008
• Write an analysis (WORD, 12 pt. Times New Roman, 1.5 line
spacing) of the article using the following questions (include
Question # and Question Statements!):
1. What is the key problem relating to requirements definition that
helped cause “missteps” in recent Air Force procurements?
2. What are the key three or four proposed changes in the new
approach for requirements definition?
3. What are some of the expected requirements and attributes of the
upcoming “Next Generation Bomber” (NGB or B-21) system?
4. What are some of the proposed key approaches for evaluating the
NGB contractor designs and improving the requirements definition
process?
5. What is a politically driven reason for creating the NGB program and
what are the technical reasons for the program?

Aerospace Engineering-Fundamentals of Systems Engineering Week #2 - 41

090507 Aerospace Engineering-Fundamentals of Systems Engineeering Week #2 - 42
090507 Aerospace Engineering-Fundamentals of Systems Engineeering Week #2 - 43
 Assignment
• Read and study Chapter 3 (Conceptual System
Design)
• Understand
– Technical performance measures
– Functional analysis and allocation
– System specification
• Team Assignment: DRAFT Design project Charts:
Team HW 4-1:Title chart, 1.1 through 1.6
– Team lead Submit .PDF to Bb>Course Content> Week 4>Assignments>Team
HW# 4-1

• Individual HW #4-1 Mending Fences Analysis – submit

.PDF to Bb >>> Individual HW#4-1

Week #3 - 44
 Backup

ARO 2011L Aerospace Engineering-Fundamentals of Systems Engineering Week #3 - 45

and Design
 The Format of a Requirement
• Requirement Ref # + requirement statement (in a complete sentence)
• Reference #: Req. type (T,M,C,E), and WBS box # (0.0, 1.1.2, etc.)
where the requirement applies, and dash serial number
– Example: T0.0-1 ... “requirement statement”
• Three elements in a requirements statement:
1. Topic (subject of the requirement)
2. Metric (or way to measure it to verify the requirement is met)
3. Constraint (where or when it applies)
• Example:
• T0.0-1 The crewed elements of the space system shall have a safety loss-of-crew
ratio of 1 loss in a minimum of 10,000 missions for ascent, re-entry and landing
mission segments for the flight crew and ground population.
• T0.0-1 (1) The crewed elements of the space system (2) shall have a safety loss-of-
crew ratio of 1 loss in a minimum of 10,000 missions (3) for ascent, re-entry and
landing mission segments”

Week #3 - 46
ARO 2011L
1.5b.1 Key System Level Requirements FOM’s & Resulting
Attributes
What are the key FOM Requirements and attributes of your system that also relate to your Primary System level
requirements and Figures of Merit? (Choose the most important FOM’s from the winning HW # 2-1 Essay with
updates). You will use these FOM’s in your architecture trade studies; examples.:
• Design Mission(s) = Service Space Station with Crew and Cargo, (or Multi-role Fighter Bomber for
Navy, Air Force and Marine Corps, or Large Commercial passenger transport for 450 city pairs)
• FOM 1= Safety is 1/10,000 Loss of Crew (SLI)
– Attribute: Loss of crew requires a crew escape component approach
• FOM 2= Reliability is 1/1000 Loss of Mission
– Attribute: Engine cluster reliability redundancy is a key design and decision driver
• FOM 3= Operations Cost is $1000/pound of payload:
– Attribute: Multiple payloads with different orbits accomplished in one launch
• FOM 4 = $35M per aircraft max acquisition cost (F-35):
– Attribute: Navy, Air Force, and Marine Corp aircraft variants utilize maximum common design features
– Attribute: Replace expensive manufacturing jigs and fixtures with “virtual tooling” (3-D CAD based laser positioning) and
precision indexed double fuselage keel beams that all major sub-components are connected.
• FOM 5= Increase commercial passenger revenues by 30% (vs. B767) and satisfaction index by +
30% - Design Approach: increase aircraft mission availability and reduce need for plane changes
– Attribute: Triple current aircraft mean time between maintenance inspections thus reducing the frequency of landing at
airline maintenance “hubs” for scheduled maintenance, thus reducing the need for passenger plane changes
– Attribute: Reduce frequency of structural inspections by increasing structural fatigue life by use of all composite material
fuselage, wing, and empennage to replace aluminum
– Attribute: Reduce need for engine inspections by using a new fan jet engine with higher reliability compared to current
available engines
– Attribute: Reduce the frequency of hydraulic sub-system inspections by using new -technology electric flight control
actuators with higher reliability

The key system level FOM requirements

1/16/2021 system architecture
Aerospace Engineering-Fundamentals of Systemsattributes
Engineeering that can achieve an
Week #3 - 47
asteroid sample return for the NASA $1B budget with a rendezvous in 2023