The Systems Engineering Landscape

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

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)

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

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

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)

Each requirement in the RTM must be assigned at least one verification method. The choice depends on cost, fidelity, and feasibility.

Topic 7 -- Validation

Validation answers: "Did we build the right system?" It confirms that the system meets the stakeholder's actual need -- not just the written requirements, but the underlying intent.

The distinction matters. A system can pass every verification test and still fail validation if the requirements were wrong. Verification checks requirements; validation checks intent.

Worked example. Katherine Johnson's trajectory calculations for Mercury and Apollo missions were verified by comparing hand calculations to computer output (verification: do the calculations match?). But the real validation was: does the capsule reach orbit, and does it come home safely? The calculations were verified; the mission validated them.

Validation Methods

• Operational testing: Use the system in its intended environment with real users.
• Mission simulation: End-to-end simulation of the operational scenario.
• User acceptance testing: Stakeholders confirm the system meets their needs.
• Pilot deployment: Limited deployment to a subset of users before full rollout.

Topic 8 -- Configuration Management

Configuration management (CM) controls changes to the system baseline -- the approved set of requirements, designs, and documents at each lifecycle phase.

CM Activities

Change control boards (CCBs) review proposed changes and assess their impact on requirements, schedule, cost, and risk before approving or rejecting them. Uncontrolled changes -- like the Hyatt Regency connection detail change -- are a primary cause of engineering failures.

Topic 9 -- Technical Performance Measures (TPMs)

TPMs track how well the design is meeting its most critical requirements throughout development. They provide early warning when a design is drifting off-target.

Example TPMs for a spacecraft:

A yellow or red TPM triggers a trade study or design change before the problem becomes a showstopper at integration.

The NASA Systems Engineering Handbook

NASA SP-2016-6105 Rev 2 is the gold standard reference for systems engineering practice. Its key contributions:

• 17 SE processes organized into system design, product realization, and technical management
• Life cycle phases (Pre-A through F) with reviews at each transition
• Technical authority model separating engineering judgment from program management pressure
• Lessons learned from decades of spaceflight programs

The handbook is freely available and applicable far beyond aerospace. Any complex system development benefits from its structured approach.

Cross-References

• johnson-k agent: Primary agent for systems engineering, especially aerospace applications and computational verification.
• brunel agent: Integrated design oversight that spans the full V-model.
• tesla agent: Electrical and systems-level thinking, especially for feedback and control systems.
• design-process skill: The design cycle is the inner loop; systems engineering is the outer framework.
• engineering-ethics skill: Professional responsibility in systems decisions, especially change control and safety.
• technical-communication skill: Documentation standards for requirements, ICDs, and verification reports.

References

• NASA. (2020). NASA Systems Engineering Handbook. SP-2016-6105 Rev 2. National Aeronautics and Space Administration.
• INCOSE. (2023). Systems Engineering Handbook. 5th edition. Wiley.
• Blanchard, B. S., & Fabrycky, W. J. (2011). Systems Engineering and Analysis. 5th edition. Prentice Hall.
• Kossiakoff, A., Sweet, W. N., Seymour, S. J., & Biemer, S. M. (2011). Systems Engineering Principles and Practice. 2nd edition. Wiley.
• Crawley, E. F., Cameron, B., & Selva, D. (2016). System Architecture: Strategy and Product Development for Complex Systems. Pearson.