systems-engineering

Systems Engineering

Systems engineering is the interdisciplinary approach to designing, integrating, and managing complex engineered systems over their life cycles. When an engineering problem grows beyond a single component -- when multiple subsystems must work together, when requirements span disciplines, when interfaces between parts are as critical as the parts themselves -- systems engineering provides the framework for managing that complexity. This skill covers the V-model, requirements management, integration, verification, validation, and the NASA SE Handbook approach.

Agent affinity: johnson-k (aerospace systems, trajectory and mission analysis), brunel (integrated design oversight)

Concept IDs: engr-design-cycle, engr-control-systems, engr-testing-methodology, engr-codes-of-ethics

The Systems Engineering Landscape

| # | Topic | Key question | |---|---|---| | 1 | The V-model | What is the lifecycle structure? | | 2 | Requirements management | What must the system do? | | 3 | Architecture and decomposition | How is the system organized? | | 4 | Interface control | How do subsystems connect? | | 5 | Integration | How are pieces assembled? | | 6 | Verification | Does the system meet its specs? | | 7 | Validation | Does the system meet the user's need? | | 8 | Configuration management | How is change controlled? | | 9 | Technical performance measures | Is the design on track? |

Topic 1 -- The V-Model

The V-model is the canonical systems engineering lifecycle. The left side decomposes (top-down): system requirements flow down to subsystem requirements to component requirements. The bottom is implementation (build/code/fabricate). The right side integrates and verifies (bottom-up): components are tested, then integrated and tested at subsystem level, then at system level.

Stakeholder Needs ←——————————————————————→ Validation
    ↓                                           ↑
System Requirements ←————————————————→ System Verification
    ↓                                       ↑
Subsystem Requirements ←——————→ Subsystem Verification
    ↓                               ↑
Component Requirements ←→ Component Verification
    ↓                       ↑
    └→ Implementation →→→→→→┘

The horizontal arrows represent traceability: each level on the right verifies the requirements written at the corresponding level on the left. This is the defining feature of the V-model -- every requirement has a corresponding verification activity, planned at the same time the requirement is written.

Why the V-model. It forces early planning of verification. Writing a requirement without planning how to verify it is writing a wish, not a requirement. The V-model makes this impossible by pairing the two sides of the V.

Topic 2 -- Requirements Management

Requirements management is the continuous process of eliciting, documenting, analyzing, tracing, prioritizing, and controlling requirements throughout the system lifecycle.

Requirements Hierarchy

| Level | Scope | Owner | Example | |---|---|---|---| | Stakeholder requirements | What the user needs | Customer/sponsor | "The spacecraft shall reach lunar orbit" | | System requirements | What the system must do | Systems engineer | "The propulsion system shall deliver 3,200 m/s delta-v" | | Subsystem requirements | What each subsystem must do | Subsystem lead | "The main engine shall produce 100 kN thrust at Isp 450s" | | Component requirements | What each component must do | Component engineer | "The turbopump shall deliver 50 kg/s at 20 MPa" |

Good Requirements

A well-written requirement is:

• Necessary: It traces to a stakeholder need. If no stakeholder needs it, delete it.
• Verifiable: A test, analysis, inspection, or demonstration can confirm it.
• Unambiguous: One reader, one interpretation. "Adequate" is ambiguous. "Greater than 100 kN" is not.
• Complete: No TBDs at CDR. Placeholder requirements are acceptable in early phases but must be resolved before design commitment.
• Consistent: No two requirements contradict each other.
• Achievable: The requirement is technically and economically feasible.
• Traceable: Upward to the need, downward to the design, and laterally to the verification method.

Requirements Traceability Matrix (RTM)

| Req ID | Requirement | Source | Allocated to | Verification method | Status | |---|---|---|---|---|---| | SYS-001 | System shall deliver 3,200 m/s delta-v | Mission requirements doc | Propulsion subsystem | Analysis + test | Verified | | SUB-P-001 | Main engine thrust >= 100 kN | SYS-001 | Engine assembly | Test | Verified | | SUB-P-002 | Engine Isp >= 450 s | SYS-001 | Engine assembly | Test | Open |

The RTM is the backbone of systems engineering. It ensures no requirement is orphaned (unallocated), no verification is missing, and every stakeholder need is addressed.

Topic 3 -- Architecture and Decomposition

System architecture defines how the system is partitioned into subsystems and how those subsystems interact. Decomposition follows the function-to-form mapping: identify what functions the system must perform, then allocate those functions to physical subsystems.

Functional Decomposition

Break the system's mission into functions, sub-functions, and so on until each function can be assigned to a single subsystem or component.

Physical Architecture

Map functions to physical elements. Multiple functions may map to one physical element (integration). One function may map to multiple elements (distribution). The mapping is documented in the N-squared diagram or architecture block diagram.

Architecture Trade Study

Evaluate alternative architectures using the same trade study methods as the design process skill (Pugh matrix, weighted scoring). Architecture decisions are among the most consequential in a program because they are difficult and expensive to change later.

Topic 4 -- Interface Control

Interfaces between subsystems are where most integration problems occur. Interface control documents (ICDs) define the physical, functional, and data interfaces between subsystems.

Interface Types

| Type | What it defines | Example | |---|---|---| | Physical | Geometry, mounting, connectors | Bolt pattern, connector pinout | | Functional | Signals, power, data | Voltage levels, data rates, protocols | | Thermal | Heat transfer across boundaries | Maximum heat flux at interface | | Structural | Loads transmitted across boundaries | Maximum force and moment at mounting plane |

The interface rule. If two teams do not agree on the interface definition in writing before they start building, they will discover the disagreement during integration -- the most expensive possible time.

Topic 5 -- Integration

Integration is the process of assembling subsystems into the complete system. It proceeds bottom-up (the right side of the V): components into subsystems, subsystems into the system.

Integration Strategy

| Strategy | Description | Risk | |---|---|---| | Big bang | Integrate everything at once | High -- failures are hard to isolate | | Incremental | Add one subsystem at a time, test after each addition | Lower -- failures can be attributed to the latest addition | | Thread-based | Integrate along functional threads (e.g., a single end-to-end signal path) | Moderate -- verifies cross-cutting functionality early |

Incremental integration is preferred for most systems because it localizes problems. Big bang integration is only justified when schedule pressure is extreme and risk is accepted.

Topic 6 -- Verification

Verification answers: "Did we build the system right?" It confirms that the system meets its specified requirements.

Verification Methods (TIAD)

| Method | How it works | When used | |---|---|---| | Test | Operate the system and measure performance | When physical measurement is required | | Inspection | Visual or dimensional examination