SVC-01 · Service
Systems Engineering consulting for aerospace, space and defence programs
Goujon Systems provides independent, senior systems engineering support to space, aerospace and defence programs across Europe. The work covers the full technical chain: operational concept, requirements definition and management, functional and physical architecture, trade-off analysis, and system-level integration, verification, validation and qualification (IVVQ), carried out inside your own processes and toolchain rather than alongside them.
Engagements are led personally by Clément Goujon, an INCOSE CSEP-certified systems architect with close to ten years on European flagship space and defence programs, including the system architecture of ESA’s Argonaut lunar lander. Deliverables are produced against ISO/IEC/IEEE 15288:2023 and, for space programs, ECSS-E-ST-10C Rev.1, tailored to the size of the program rather than applied wholesale.
What the work covers
From a blank page to a verified system. Each item below is a deliverable, not a topic heading: you end the engagement holding the artifact.
- Operational concept (ConOps): mission and operational scenarios, stakeholder needs, and the use cases the system must satisfy, written so that engineering decisions can actually be traced back to them.
- Requirements definition & management: stakeholder, system and sub-system requirement sets that are verifiable, traceable and defensible under customer challenge, with the traceability structure maintained in your requirements tool.
- Functional architecture: functional breakdown, functional chains and interface definition, expressed in ARCADIA/Capella or SysML according to what your program already uses.
- Physical architecture: product tree, allocation of functions to components, and the technical budgets (mass, power, link, pointing, data) with margins that are stated rather than implied.
- Trade-off analysis: structured alternatives, weighted criteria, sensitivity checks and documented rationale, built to survive the moment a customer asks why the other option was rejected.
- System-level IVVQ: verification strategy, verification control document, test and analysis matrices, and the evidence chain that closes each requirement at qualification.
- Technical risk management: a risk register that is actually used: mitigation plans, and explicit links between risks, margins and the design decisions they drive.
- Review preparation: SRR, PDR and CDR data packs assembled so the review is spent arguing about engineering rather than hunting for missing documents.
When teams bring in outside systems engineering
Almost every engagement starts with one of a small number of sentences. If you recognise yours here, the problem is well understood and has a known shape.
- “The requirements baseline will not survive the next review, and we know it.”
- “We have an architecture, but nobody can explain why it is the right one.”
- “Our technical budgets live in three spreadsheets that disagree with each other.”
- “We passed SRR and the system boundary is still being argued about.”
- “The team is excellent on the product and thin on the system.”
- “We would like an independent pair of eyes before the customer provides one.”
- “We are a start-up, and our first institutional customer expects an engineering process we do not yet have.”
How it runs
Three phases, and an honest answer at the end of the first
Read, interview, scope
Go through the existing material, interview the team, and come back with a written statement of what is genuinely missing and what closing the gap would take. If the answer is “less than you feared”, that is what you are told.
Do the work in your environment
The substantive engineering, in your tools, with your engineers, producing artifacts your organisation owns outright and can maintain after the engagement ends.
Leave the reasoning behind
Deliverables come with the rationale that produced them, plus working sessions where useful, so the team can carry the work forward without needing me again for the same problem.
Standards, methods and tools
Process rigour is sized to the program. A €300k feasibility study and a major naval program need the same discipline and emphatically not the same paperwork; deciding where on that scale you sit is part of the work.
| Framework | What it governs |
|---|---|
| ISO/IEC/IEEE 15288:2023 | The system life-cycle process backbone: agreement, organisational, technical management and technical processes, and how they are tailored to a given program. |
| ECSS-E-ST-10C Rev.1 (15 February 2017) | System engineering general requirements for European space programs. The reference standard on ESA and national-agency work, and the one your customer will audit against. |
| INCOSE Systems Engineering Handbook, 5th edition (2023) | Practice-level guidance and the body of knowledge behind the INCOSE CSEP certification. |
| ARCADIA / Capella | Method-and-tool pairing for functional and physical architecture, widely adopted across European aerospace and defence. |
| OMG SysML (v1.x and v2) | Modelling language for system architecture. SysML v2 reached final adoption at the Object Management Group in July 2025. |
Toolchain
Who this is for
Primes, large enterprises and system integrators
Independent senior expertise plugged into a critical phase or review: a defensible requirements baseline, an architecture that holds up under peer scrutiny, or a system-level verification strategy that closes cleanly. In your tools, inside your processes, and ready to be challenged by your own experts.
Space start-ups and scale-ups
Right-sized systems engineering before complexity bites. Enough process to satisfy an institutional customer and reassure an investor, and not one document more. The failure mode for young companies is not too little rigour: it is importing a prime’s process wholesale and drowning in it.
Frequently asked
Questions people ask before getting in touch
What does an independent systems engineering consultant actually deliver?
Engineering artifacts your program owns and can defend at a review: a requirements baseline, an architecture description, trade-off dossiers with documented rationale, technical budgets and their margins, a verification strategy, and the review data packs that go with them. Not a report recommending what you should do: the work itself.
Do you work in our tools and processes, or bring your own?
Yours. The toolchain is already fluent territory: DOORS, Jazz ELM, Polarion and Valispace for requirements; Capella, Cameo, COMET/CDP4 and IDM-CIC for modelling and concurrent design; MATLAB and Simulink for analysis. Introducing a new tool into a running program is usually the most expensive way to solve a problem that is rarely a tool problem in the first place.
How large does a program need to be?
The experience spans programs of every scale, from R&D and feasibility studies through to major multi-year contracts. Scale matters less than scope clarity: a short, sharply defined assignment on a small program frequently returns more than an open-ended one on a large program.
Do you work on site or remotely?
Both. The practice is based in Cherbourg-en-Cotentin, France, and works across Europe. Architecture, requirements and analysis work runs well remotely; reviews, architecture workshops and team coaching are markedly better on site.
Which languages do you work in?
English, French and Italian, including written deliverables and customer-facing reviews.
How is this different from hiring a contract engineer?
A contract engineer fills a seat on your organisation chart and inherits its assumptions. An independent consultant is senior expertise pointed at one defined problem, for as long as that problem lasts, with the independence to tell you something the organisation may not want to hear. That independence is usually the point.
Related services
Book a free intro call.
Thirty minutes, no commitment, in English, French or Italian. Tell me about the program and I will tell you honestly whether I am the right person for it.
Last updated: