The document discusses the development of requirements for a vehicle through model-based systems engineering. It provides examples of models that can be used to capture a vehicle's operational concept, including a design reference mission diagram, a phase model, and an activity model. The models aim to depict how the vehicle and crew interact during different mission activities and phases to achieve objectives. They are used to identify vehicle capabilities and functions needed to implement the operational concept.

1. Streamlining Requirements
Development through
Model-based Systems
Engineering
Robert Bayt,
Ann Christian,
Philip Nerren, and
Rich DeLoof
Altair Project Integration
Used with Permission

2. Role of the System Requirements Document
Objectives
♦ Capture the vehicle-level capabilities in a set of complete,
necessary, clear, attainable, traceable, and verifiable statements
of need (Requirements) If it is not needed by Cx, it is
• Should not be unduly restrictive1 not a vehicle-level capability
• Sets limits that eliminate items outside the boundaries drawn
• Encourage competition (or alternatives)
• Capture source and reason of requirement
♦ Establish the verification methods that will lead to product
acceptance
• These should be reproducible assessment methods
♦ Allocate requirements to the element-level to facilitate vehicle
architecture development and integration
The SRD sets the standards by which the Product will be evaluated
1MIL-STD-961E - Reference 2

3. Where do Requirements Come From?
♦ The Customer
• One should always listen to the Voice of the Customer when establishing
what the End Item should be able to do
• On Altair, we walk through the CARD Allocated Requirements and
Categorize by:
− MOE
− Operational
− Functional/Performance
− Safety/-ilities
♦ Operational Analysis
• Develop deep understanding of Concept of Operations to identify new End
Item Capabilities that are required
• Evaluate operational constraints
♦ Technical Disciplines Best Practices
• Work with discipline experts to establish capabilities required “to do the job”
♦ Design and Construction Standards
• Use industry standards to specify how the product is designed
3

4. Requirements Development Approach
♦ Role of the Project is to validate
requirements DRM
• Necessary
Phase
• Attainable
• Traceable Activity
• Clear and Verifiable
♦ Vehicle Functionality should flow Event
from the Concept of Operations
• How is the vehicle to be Functional
operated? Modes
• What functionality should be
on-board to support these
operations? Requirements
Goal: Ensure Traceability from Missions to Functions to Requirements
and Drive for Completeness
4

5. Requirements Development Approach - 2
♦ Required vehicle functionality flows from the concept of operations and
system of systems architecture.
Prior to Models-Based Systems Engineering (MBSE):
♦ OPSCON articulated our Concept of Operations
• Captures at the phase/activity-level the general roles of the various systems in
executing the mission
• Timeline captures the events that make up these operations with some articulation of
roles
Implementing MBSE:
♦ OPSModels are flow diagrams that depict operations described in
OPSCON with an allocation of responsibility of those events
• Capture discrete events that make up an activity
• Capture dependencies and data flow that make up those activities
• Drive traceability of Operational requirements
• Provide traceability of functionality to vehicle
♦ Traceability comes through linking of data objects, and reports querying
database depicts this traceability
5

6. Design Reference Mission: Lunar Sortie Crew
Design Reference Mission: Lunar Sortie Crew
EDS LOI Burn LOI Burn Undock ATP for Ascent
Jettison Procedures Sequence Complete Lunar Stay Preparation
Complete Begun Complete Start
Pre-Surface Lunar
TLI Trans-Lunar LOI Operations Altair Surface Ascent &
Operations Cruise Operations (Docked) Descent AND Operations AND RPOD
Operations
LSC.9 LSC.10 LSC.11 LSC.12 LSC.13 LSC.14
LSC.16
TLI Burn Docking
Prep Start complete
Earth
Orbit Lunar
Operations Orbit
Maintenance Post-Surface
LSC.8 Operations
LSC.15
Docking LSC.17
complete
Altair/LIDS
LEO RPOD Jettison
Operations
LSC.7
ATP for Trans-Earth
Orbit Ops Cruise
LEO LSC.18 Final
Configuration Entry
(Post-Insertion) Prep
<EI-12>
LSC.6
Orbit
Insertion
Burn
Earth
Arrival
Operational
Operations
Complete
Ascent LSC.19 Hierarchy
SM
LSC.5 Separation
Terminology
Liftoff
Phase
Re-entry/Entry
Launch (Operation) LSC.20
Fwd Bay
DRM
LSC.4
Cover
Jettison
LCD CTS
Pad
Operations
Integrated
Operations
Stand
Alone Post-Flight
Processing Recovery
Descent
and
Phase
Operations Landing
LSC.3 LSC.2 LSC.23 LSC.22
LSC.1 LSC.21
Activity
MLP Hard
Transport
to Arrival
Arrival
at Sub-
Integration DD250 at Refurb Post-Flight Touchdown
Down Facility
Complete
Site Processing
Facility
Activity
Trigger Event
(Data Item) Authoritative Source: CxP 70007, DRMOCD 6

7. Phase Model – LSC.13 Lunar Descent
The phase is decomposed into activities that are generally serial.
Phase
Transition
Activity
Plane Plane
Undock Change Post DOI
- ATP for
Change DOI Burn Burn Touchdown
Complete PDI Burn Lunar Stay
Procedures Maneuver Initiation Procedures Initiation
Initiation Complete Complete
Free Perform Perform Perform
Plane Prep for Perform Lunar Perform Post
Flight Powered
Change DOI DOI Descent Landing
Operations Descent
Maneuver Coast Checkout
*LSC.13.1* *LSC.13.3* *LSC.13.4*
LSC.13.2 *LSC.13.5* *LSC.13.6* *LSC.13.7*
Abort Required Abort Required
LSC.100.12.7
Abort Required Abort Required Abort Required G
LSC.100.12.4
G DRM
Phase
Activity
Event
7

8. Activity Model – LSC.13.3 Prep for DOI
* Crew
Activities are
the DOI Burn Event Diagram can be simulated
Prep Procedure
*
Concur
Check
with
Crew Altair
Execute
AND AND Nav State AND AND
Burn
LSC.13.3.1
State LSC.13.3.2
Vector
Accepted Crew Burn
Altair Nav. Concurrence
State Crew Burn
Plane Request
Concurrence
Change
Maneuver Compute Maneuver DOI Burn
Update
Complete Altair DOI Burn to Burn Initiation
Nav. State
Solution AND Attitude AND
LSC.13.3.7
LSC.13.3.3 LSC.13.3.4
Go for DOI
Burn Start Burn
Time and
Final dV
Execute Perform
Altair Nav. DOI Final DOI
State Update Auto-Sequence Countdown
LSC.13.3.5 LSC.13.3.6
Send
Mission Altair Send Go
Systems Nav. for DOI
State Burn
Update
LSC.13.3.9
LSC.13.3.8 DRM
Goal:
-Capture how the vehicle is operated by the crew Phase
- Show Crew or Other System actions and vehicle response
- Boxes should be Actions that are triggered by: Activity
- Completion of prior task (only solid arrow entering)
- A signal from another system (dashed arrow w/ data item) Event
8
- Reaching a fixed start time (not shown in diagram, only shown in timeline)

9. Activity Model – LSC.13.3 Prep for DOI
* Crew
Activities are
the DOI Burn
Prep Procedure
*
Concur
Check
with
Crew Altair
Execute
AND AND Nav State AND AND
Burn
LSC.13.3.1
State LSC.13.3.2
Vector
Accepted Crew Burn
Altair Nav. Concurrence
State Crew Burn
Plane Request
Concurrence
Change
Maneuver Compute Maneuver DOI Burn
Update
Complete Altair DOI Burn to Burn Initiation
Nav. State
Solution AND Attitude AND
LSC.13.3.7
LSC.13.3.3 LSC.13.3.4
Go for DOI
Burn Start Burn
Time and
Final dV
Execute Perform
Altair Nav. DOI Final DOI
State Update Auto-Sequence Countdown
LSC.13.3.5 LSC.13.3.6
Send
Mission Altair Send Go
Systems Nav. for DOI
State Burn
Update
LSC.13.3.9
LSC.13.3.8
Questions:
- Is the operational concept complete? Is it Valid?
- Are there any actions the crew or vehicle need to take to support your
subsystem or vehicle objectives?
- What capabilities from your subsystem or other systems are required to
implement this operational concept?
9

10. WHAT Do We Want to Specify?
Treat the Vehicle Sustain
Environment Perform
as a Black Box Communications
(Inside and Out) Can the crew live
in it? Can it interact with
Provide the outside world?
Transportation
Can it carry and
Accept and
service Payload? Execute
Can it take
Commands
Provide action upon
Habitability
Command?
Can the crew work
out of it?
Perform Altair Manage Vehicle
Can it move Maneuvers Performance
Functional
and follow a Architecture
trajectory? Can it assess
its own status?
Establish the purpose of the System; Define Functions and Measures that
Implement and Quantify achieving the Purpose
10

11. The Functional Architecture
♦ A function is a process that takes inputs in and transforms these
inputs into outputs1
♦ The functional architecture of a system contains a hierarchical
model of the functions performed by the system1
♦ Functional Architecture
• Capture required system behavior
• When someone asks, “What should the Altair be able to do?”, we should be
able to point to the functional architecture as the sum total of its capabilities
(independent of the mission)
• Highest-Level of the architecture developed by grouping Customer
Functional Requirements
− Walk through all the Cx requirements and categorize them (CARD, HSIR, C3I)
− Group those in the category of functional or performance
♦ Functions are need based not discipline based
• Don’t need a Command and Data Handling System C&DH meets
• Do need to be able to Accept and Execute Commands functional need
1Source Buede, D. , Engineering Design 11

12. Example Functions
Cabin Lander State
Pressure =
12 psi
Generate
Health Request Health and
Cabin Pressure Control (multiplexer) Status Lander Status
Set-point = 10 psi Pressure Cabin (Crew Display
Pressure = or Downlink)
10 psi
Functional Thread – Perform Rendezvous
Relative
Navigation
Manage Perform
Trajectory
Vehicle Translational
Design
Inertial Events Maneuver
Navigation
12

13. Define Subsystem Modes
A system mode is defined to be a distinct operating capability of the system
during which some or all of the system's functions may be performed to a full or
limited degree1
• Examples: On/Off/Standby or High Data Rate/Low Data Rate
• Both are an expression of capability
♦ Mode Matrix
• Should be as concise a representation as possible of total vehicle capability for any
activity in the mission
♦ Mode Characterizations
• Mode Names should clearly articulate the level of capability and of what function
− Status – Active – Capabilities in use; Stndby – Capabilities available but not used; Inactive– No
capability
Control Pressure  Automatic Pressure Control  R.EA0703
 Emergency Pressure Control  R.EA3107/3181
• Use Mode definitions can tie this to our current understanding of the vehicle
Passive Cabin Pressure Relief Active  Mechanical positive pressure relief valves (PPRVs) are active, but
do not require power. They are probably venting in this phase.
1Source Buede, D. , Engineering Design 13

14. Functional Architecture Modes Matrix
♦ Cross Correlation of sub- LSC.13 : Altair Descent :
Altair Functional Relationship
mode for each scenario to Operations via Modes
LSC.13.2 : Perform
LSC.13.1 : Free Flight Plane Change
• How much capability in
Operations : Maneuver : LSC.13.3 : Prep for
000/01:03:27 000/00:00:00 DOI : 000/01:34:51
Transportation
each subsystem is required LNDR.1.3 : Transport Crew
LNDR.1 :
Crew On-board Crew On-board Crew On-board
Provide
execute an activity
♦ Definition of each sub-
LNDR.1.5 : Transport EVA
Suits EVA Suits Donned EVA Suits Donned EVA Suits Donned
Habitabilit
LNDR.2.1 : Provide exterior
LNDR.2 :
mode is captured
Provide
viewing Exterior Viewing Available Exterior Viewing Available Exterior Viewing Available
y
Reading + Panel Lighting Reading + Panel Lighting Reading + Panel Lighting
♦ Capabilities should be met LNDR.2.2 : Provide Lighting On On On
LNDR.3 : Perform
in total by requirements LNDR.3.1.1 : Estimate
Maneuvers
Inertial State Inertial Navigation Active Inertial Navigation Active Inertial Navigation Active
♦ In some cases, functions LNDR.3.2 : Perform
Translational Maneuvers Main Engine Burn
are provided by other LNDR.3.5 : Perform
Trajectory Design Target Computation Active Target Computation Active
systems, mode should
Environmen
LNDR.4 :
LNDR.4.1 : Control Cabin Cabin Pressure Control Cabin Pressure Control Cabin Pressure Control
Sustain
Altair
Pressure
reflect other system is LNDR.4.2 : Control
Active
Temperature Control
Active
Temperature Control
Active
Temperature Control
Temperature
providing (i.e. Altair on Active Active Active
LNDR.5 : Accept
LNDR.5.1 : Receive
and Execute
Commands
Orion Power) Commands from Cx Receive Commands Active Receive Commands Active Receive Commands Active
LNDR.5.2 : Receive
Commands from Crew Receive Commands Active Receive Commands Active Receive Commands Active
cations Performan
LNDR.7 : LNDR.6 :
Perform Manage
Communi Vehicle
LNDR.6.2 : Perform FDIR Perform FDIR Active Perform FDIR Active Perform FDIR Active
LNDR.6.4.1: Manage Power
Load Altair On Internal Power Altair On Internal Power Altair On Internal Power
LNDR.7.1 : Communicate RF-High Data Rate RF-High Data Rate RF-High Data Rate
with Cx Systems RF-Low Data Rate RF-Low Data Rate RF-Low Data Rate
14

15. Requirements linked to Sustain Environment
LNDR.2 Sustain Altair LNDR.2.1 Control Pressure R.EA0703 LSAM Cabin The LSAM shall control cabin pressure to a This is to facilitate pressure operation from the
Environment Pressure selectable setpoint between 79 (TBR-001-907) LSAM to Orion operational pressure to the
kPa (11.4 psia) to 52 (TBR-001-908) kPa (7.5 minimum nominal limit with a 34% oxygen
psia) with 0.7 (TBR-001-147) kPa (0.1 psia) materials limit and 17 kPa (2.5 psia) ppO2 crew
increments for Lunar Sortie and Lunar Outpost limit. This is to have common approach to cabin
crew missions. pressure management across Constellation
Architecture.
LNDR.2.2 Control Temperature R.LNDR.024 Cabin The Altair shall control cabin temperature per LNDR.2. Control Cabin
Temperature HSIR 3054 while inhabited except during suited 2.1 Temperature
Control operations.
LNDR.2.3 Manage O2 and N2 R.EA3062 LSAM Cabin The LSAM shall limit the maximum oxygen This is to keep the oxygen concentration from LNDR.2. Control
Pressure Oxygen concentration within the pressurized cabin to 34% exceeding the materials certification limit. This is 2.2 Component
Concentration (TBR-001-038) by volume for Lunar Sortie and to have common approach to cabin pressure Temperature
Limits Lunar Outpost crew missions. management across Constellation Architecture.
LNDR.2.4 Control Humidity
LNDR.2.5 Provide Ventilation
LNDR.2.6 Control Contamination R.LNDR.023 Lunar Dust The Altair shall limit the levels of lunar dust
Control contaminants of less than 10 and equal to or
greater than 0.1 micron (TBR-006-004) size in
the internal atmosphere below 0.05 mg/m^3.
LNDR.2.7 Provide Fire Detection and R.EA3139 LSAM Fire The LSAM shall provide fire detection and This is to provide cabin fire detection,
Surpression Detection and suppression for the LSAM pressurized volume for notification, and suppression. The type of fire
Suppression Lunar Sortie and Lunar Outpost crew missions. detection and suppression required in the avionics
bays will be a function of materials selection,
proximity to ignition sources and oxidizers.
LNDR.2.8 Provide Potable Water
LNDR.2.9 Remove CO2
LNDR.2.10 Provide Waste Collection
LNDR.2.11 Provide Galley Service
LNDR.2.12 Provide Suit Loop Services
LNDR.2.13 Pressurize Docking Vesitbule R.EA3137 LSAM The LSAM shall provide not less than two The responsibility for vestibule pressurization
Vestibule vestibule pressurization cycles per mission for must be allocated between Orion and LSAM. This
Pressurization Lunar Sortie and Lunar Outpost crew missions. requirement allocates responsibility for two
Cycles pressurization cycles to LSAM. Primary and
contingency vestibule pressurization should
account for each docking in which the crewed
LSAM is the active vehicle. The LSAM will
perform the vestibule pressurization when the
crewed LSAM docks with the Orion.
Linking requirement enforces function
15

16. Requirements Achievability Assessments
I.D Name
R.EA0062 LSAM Return Cargo Capability
Requirement
The LSAM shall return at least 100 kg (TBR-EARD-037) (220 lbm) of Payload from the lunar surface to the Lunar Rendezvous Orbit (LRO)
during each crewed lunar mission.
Rationale
The LSAM returned mass must include the 100 kg (220 lbm) of Payload specified by ESMD in addition to the crew and Flight Crew
Equipment. This requirement applies to each crewed lunar mission and is needed to size the LSAM ascent stage.
Comments
Quality: Add the following to the rationale "This payload is to be stored in the pressurized environment, with no power / data / thermal
services provided. The payload may include rocks, ISRU product samples, crew biological samples, failed components, crew personal
effects. Anything which leaves the lunar surface to be returned to Earth, excluding crew and crew equipment, can be considered payload.
This allocation is a total return mass allocation that includes containment and interface hardware masses required for transport. Note the
objective in R.EA6304 is 250 kg."
This requirement should be a KDR (as listed on the Lunar KDRs for Altair at LCCR).
KDR Verification Reqt. Reqt. Group SRD POC Req Status Reqt. Criticality VI Involved
Method Type Compliance Organization
Analysis MOE Provide Dave McKissock Agreed green - High C1 Altair Flight
Transportation Likelihood of Systems
Compliance
♦ Validation (Why a requirement on us?)
• Is this philosophically the right requirement to set? r – Low Likelihood of
• Is the value achievable/affordable per the results of an analysis task Compliance (<50% chance)
♦ Verification (How do we apply it?) y – Medium Likelihood of
• Is it clear how the customer wants you to measure the value? Compliance (50-80% chance)
• How will you know when this requirement is implemented?
g – High Likelihood of
♦ Achievability (How are we doing against it?) Compliance (>80% chance)
• Is the likelihood of compliance in the final design high/medium/low?
grey - Unassessed
• Choose from: Inherent in current design, captured in T/O, not assessed
− If not assessed, tied to future task or risk?
Close the Requirements Development Loop by Assessing
Achievability in a Design Concept 16

17. Enablers for MBSE and Streamlining
Requirements Development
♦ A relational database for requirements and models
• Cx Program uses CRADLE to store both requirements and models to
enable traceability between objects through links
♦ Clear understanding of SRR products
• Establish upfront how all of the SRR Criteria will be met and how traceability
will be demonstrated and use these products to drive the process
• Get comfortable reviewing the raw products within the native environment to
accelerate development by eliminating post-processing into chart packages
♦ Detailed process definition to eliminate development bottlenecks
• Develop criteria for generating every product to minimize variability
• Organize the team for greatest distribution of effort
• Utilize requirement development metrics and database reports measure
progress and reinforce lagging areas
Establishing these business processes as a NASA institutional core
competency can greatly reduce project start-up resources
17