Approach
Every team already has a way of working. My job is to give it a shared structure, one that connects what the mission needs to what each engineer designs and tests, without slowing the work down.
Clarity first: every team should know what matters, why it matters, and how we’ll prove it.
01 · My method
Each step builds on the one before, so the team adopts the process instead of having it imposed.
I start by mapping how the team already works: the tools they use, where their data lives, how decisions get made and where things fall through the cracks. No new process before I understand the existing one.
A process designed around their reality, not a textbook.
Together with leadership and the technical leads, I turn the mission into success criteria, Measures of Effectiveness (MoEs) and Technical Performance Measures (TPMs). They become the reference point for every later decision.
A shared answer to “what does success look like?”
Where the team already has tools in place, such as Jira, Confluence or Jama, I start from those and tailor them to systems engineering good practice instead of directly introducing new ones. The structure only grows as far as the team needs it.
Structure without friction, and no new tool to learn.
Stakeholder needs flow down into system, sub-system and component requirements, and each requirement is linked to the architecture, the design and the test that verifies it.
The impact of a change can be traced, not guessed.
I define how each requirement will be proven (test, analysis, inspection or review) and draft the AIT sequence while the design is still flexible, so test needs can shape it.
No surprises at integration; test hardware and facilities are planned in time.
Teams own their requirements and data; I keep them coherent and easy to reach. Written guidelines, coaching, reviews and TPM tracking keep the process alive, and it grows with the maturity of the programme.
A process the team keeps using because it helps them.
02 · The V-model
This is the backbone I build on every programme, following the V-model. Select a step to see the question it answers.
The whole process is iterative: each step loops back with its neighbours as the system matures. Integration and tests run bottom-up, from component to sub-system to system level; each level is verified against its counterpart on the left, and the results feed back into the TPMs and decisions.
MissionWhat is the mission for, and what counts as success?
MoEs & TPMsHow will the customer judge success (MoEs), and is the design converging on it (TPMs)? Both are set from the mission and tracked continuously, not checked once at the end.
System requirements & architectureWhat must the system do, how well, who owns each requirement, and how does the system work?
The architecture stays design-agnostic; design detail is added at sub-system and component level. Requirements trace to model elements at every level, so gaps show up early, and test cases are derived from the scenarios.
Sub-system requirements & designWhat must each mechanical, hardware and software sub-system do, and how is it designed?
Component developmentWhat exactly does each component need in order to be built, coded or procured?
Implementation & manufacturingBuild the hardware, write the software and manufacture the parts, to the design.
Component integration & testsDoes each component meet its requirements once built and integrated?
Sub-system integration & testsDo the components work together across their interfaces, as each sub-system requires?
System integration & testsDoes the integrated system meet every system requirement and every TPM target?
ValidationDoes the system do what the mission and the customer actually need?
Configuration & traceabilityIs every requirement, model element and test result under configuration control, and traceable from mission to evidence?
03 · Across TRLs
A research team exploring the physics and a team qualifying flight hardware need different things from systems engineering. I adapt the formality to the maturity of the work, not the other way round.
Freedom to experiment and learn fast, with the key unknowns made visible.
Freezing requirements before the physics is understood.
Converging on one design and making the trade-offs explicit.
Evidence, under control, that the system meets every requirement.
04 · Case stories
Low TRL Safran Passenger Innovations
A metasurface antenna promising lower cost, weight and power had proven itself on the ground but had never been taken towards aviation. The question was whether it could become part of an existing airborne SATCOM product.
A clear, evidence-based maturity call: the technology was not yet ready for aviation. The work was paused with requirements, risks and findings captured, ready to resume when the technology matures.
A well-founded “not yet” is a valid outcome of systems engineering.
See the project →
Mid TRL Dcubed · ongoing
A multidisciplinary team building a first-of-its-kind in-space manufacturing mission. As the design matured, the team needed a clear way to connect everyday engineering decisions to what the mission has to achieve.
Requirements now trace back to TPMs and MoEs, so design trade-offs are discussed against what the mission actually needs. Tracking is easier, and engineers have started using SE methods in their everyday work.
High TRL Safran Passenger Innovations
An airborne Ka/Ku-band SATCOM system with 4,000+ requirements across hardware, software and RF, reviewed with customers and external partners. Closing those reviews meant showing, requirement by requirement, how each one was verified. The software team worked in Jira, outside the SE tool chain.
Verification coverage became visible at a glance: for every requirement, the team and the customer could see how it was verified and what was still open. Reviews with customers could be closed on clear evidence, and the software team could confirm its work was complete. External stakeholders gave direct positive feedback, the SE team grew from 3 to 13 people, and management added Polarion to the tool chain.
Clear verification coverage turns a customer review from a discussion into a check.
See the project →Every step above links to real work. Browse the projects and roles behind it, or get in touch.
