The opening article of this series introduced the Systems Engineering Engine from a distance: seventeen processes, three groups, applied down and back up the system structure. This one walks through the engine properly — what each process actually produces, how the recursion works in practice, and where teams misapply it.
The source remains NPR 7123.1 and NASA's Systems Engineering Handbook (SP-2016-6105 Rev 2), both public domain. The engine is NASA's formulation, but what it formalises is not NASA-specific: it is the anatomy of any disciplined development, made explicit enough to teach, audit and tailor.
The engine, again — now with the flows
Read the engine as a machine with two ports. Requirements enter from the level above; realized, verified products leave toward the level above. Between those ports, the design processes convert expectations into a buildable definition, and the realization processes convert that definition into a proven product. The eight technical management processes are not a phase — they are the machine's control system, running whenever the machine runs.
System design: processes 1–4
| Process | What it does | The output that matters |
| 1 · Stakeholder Expectations Definition | Establishes who the stakeholders are and what they actually need — captured as expectations, concept of operations, and measures of effectiveness | A baselined statement of what success means, before anyone writes a requirement |
| 2 · Technical Requirements Definition | Converts expectations into complete, verifiable technical requirements | The requirements baseline — the contract everything downstream answers to |
| 3 · Logical Decomposition | Breaks requirements into logical models and derived requirements for the level below | The structure: which functions exist, how they relate, what flows between them |
| 4 · Design Solution Definition | Selects and defines the design that satisfies the requirements — including the make/buy/reuse decision per element | A definition complete enough to build, buy or reuse — or to hand down a level |
The discipline hiding in this group is the refusal to skip levels. Expectations are not requirements; requirements are not a design. Each conversion is a place where error is caught cheaply — and each skipped conversion is a place where error survives until integration. Readers of our DO-178C series will recognise the same three-step ladder the software standard enforces between system requirements, high-level requirements and design.
Product realization: processes 5–9
| Process | What it does | The distinction it protects |
| 5 · Product Implementation | Builds, buys or reuses the lowest-level products | Where the design finally becomes hardware and code |
| 6 · Product Integration | Assembles lower-level products into the next level up | Integration is a process with its own planning and evidence — not a calendar event |
| 7 · Product Verification | Proves the product meets its requirements | "Did we build it right?" — against requirements |
| 8 · Product Validation | Proves the product meets stakeholder expectations in its intended environment | "Did we build the right thing?" — against intent |
| 9 · Product Transition | Delivers the product to the next level, or to the user, with its evidence | The product and its proof travel together |
Technical management: processes 10–17
The eight crosscutting processes — technical planning, requirements management, interface management, technical risk management, configuration management, technical data management, technical assessment, and decision analysis — are the ones most likely to be dismissed as overhead, and the ones whose absence is most expensive. Three deserve special mention for how often they are underweighted:
- Interface management is the seams made explicit — the register of agreements about what crosses each boundary. Most integration surprises are interface agreements that existed only in two people's heads, one of whom has left.
- Technical assessment is how the programme knows where it actually is — reviews and measures against the plan, not against optimism. It is the internal version of what an authority's staged reviews do externally.
- Decision analysis is the trade study discipline: alternatives, criteria, data, recommendation, record. Its output is the answer to the auditor's favourite question, years later: why is it designed this way?
Recursion: the idea that makes it an engine
What makes this an engine rather than a checklist is that the whole machine is applied at every level of the system structure. The system level runs processes 1–4 and hands requirements down; each subsystem runs the same processes on what it received; components likewise, until every element is defined well enough to build, buy or reuse. Then realization runs the ladder in reverse — implement at the bottom, integrate, verify, validate and transition upward, level by level, until the system that emerges at the top is the one the stakeholders asked for.
NPR 7123.1 pairs recursion with iteration — re-running a process on the same product when a discrepancy is found — and the two together answer the question every new team asks: no, you do not run the engine once. It cycles through every phase of the life cycle, at increasing fidelity, and the handbook is explicit that the engine runs in every phase from concept studies through late development.
How teams misapply it
- Running it once, at the top. A beautiful system-level requirements set, then a free-for-all below. The engine's value is precisely that subsystems and components get the same treatment.
- Treating the management processes as a documentation phase. Configuration management that starts at delivery, risk management that starts at the first crisis — the crosscutting processes only work run continuously.
- Letting decomposition become dictation. Logical decomposition hands down requirements, not designs. When the level above specifies the level below's design, the people with the most knowledge of that level are cut out of the decision.
- Confusing recursion with bureaucracy. At a component level the engine's pass might be an afternoon and two pages. The method scales; the ceremony should too. That tailoring discipline gets its own article later in this series.
- Skipping validation because verification passed. See the callout above — the most common and most expensive collapse.
The certification connection
For the certification-bound reader: the engine is where the artifact set an authority samples actually comes from. Baselined stakeholder expectations and technical requirements become the system requirements ARP4754A allocates; decomposition produces the item requirements DO-178C traces to; verification and validation records become the evidence a staged review pulls threads through; and the technical management processes are, almost name for name, DO-178C's integral processes. Running the engine well does not merely resemble preparing for certification — it is the preparation, organised by a different table of contents.
Frequently asked questions
Do all seventeen processes apply to every project?
The processes apply; their depth is tailored. NPR 7123.1 is a NASA procedural requirement, and NASA itself tailors it per project. What does not survive honest tailoring is deleting a process outright — a project with no interface management does not have a lighter process, it has an unmanaged risk.
In what order do the processes run?
The numbering is anatomy, not a schedule. Design processes run top-down, realization bottom-up, and the management processes continuously — with iteration whenever a discrepancy sends work back. On a real programme, several levels are at different points of the engine simultaneously.
How does the engine relate to the V-model?
They are the same idea drawn differently. The V's left leg is the design processes applied down the structure; its right leg is realization coming back up; the engine adds what the V leaves implicit — the management processes running across the whole, and the explicit recursion at every level.
What is the difference between logical decomposition and design?
Decomposition establishes what functions must exist and how they relate — a model of the problem's structure. Design solution definition chooses how those functions will be realised. Keeping them separate is what preserves the trade space: decompose first and you can still compare designs; design first and the decomposition merely justifies it.
Where should a small supplier start?
With processes 1, 2 and 11 — knowing your stakeholders, baselining verifiable requirements, and managing changes to them. Those three, done honestly, drag most of the rest of the engine in behind them; and they are exactly the three whose absence a customer's diligence, or an SOI-style review, detects fastest.
If your organisation is being asked for systems engineering evidence at this level of rigour for the first time — or your engine exists on paper and not in practice — this is the work we do, in both official languages. Get in touch.