3.6.28 · D5Spacecraft Structures & Systems Engineering

Question bank — Verification methods — analysis, test, inspection, demonstration

1,594 words7 min readBack to topic

This bank hunts the conceptual mistakes people make when choosing between analysis, test, inspection, and demonstration. Every answer gives you the reasoning, not just a verdict. Cover the reveal, commit to an answer out loud, then check.


True or false — justify

TRUE/FALSE: A mass requirement ("mass shall be under 12 kg") is best verified by test.
False — you just put it on a scale, which observes a static property with no environment or operation involved; that is inspection, not test. Test is for behaviour under conditions.
TRUE/FALSE: If a requirement is verified by analysis, no hardware ever needs to be built for that requirement.
True in principle for that specific requirement, but the analysis model itself usually needs validation against some test data elsewhere, or its predictions are untrusted.
TRUE/FALSE: Testing at qualification level (1.25× flight) proves the design is sound.
True — qualification stresses one unit beyond flight to prove the design has margin; acceptance testing at 1.0× then screens each individual flight unit for workmanship without over-stressing it.
TRUE/FALSE: Demonstration is just a less-rigorous version of test.
False — they answer different questions. Test measures a physical quantity against a threshold; demonstration confirms an operational capability actually happens (e.g. "the antenna deploys on command") often without precise measurement.
TRUE/FALSE: Analysis is always cheaper than test, so you should analyse whenever possible.
False as a blanket rule — analysis is cheap only if a validated model exists; building and validating a high-fidelity model for a novel structure can cost more than one shake-table run.
TRUE/FALSE: A margin of safety of exactly 0 means the requirement is verified.
Barely — means applied stress equals yield with zero remaining margin; most programs require strictly, because model and material uncertainty can push a "just-passing" part into failure. See Margin Philosophy.
TRUE/FALSE: If a spacecraft survives an 8g test, it is verified for a 10g flight environment.
False — you only have evidence up to the level you tested to. Verification claims cannot exceed the demonstrated level; you would need to test to 10g (or qualify at 1.25× above it).
TRUE/FALSE: Inspection can verify a dynamic launch-load requirement.
False — the loads only exist during launch, so there is nothing static to observe; that requirement needs test (measure it) or analysis (predict it).

Spot the error

Statement: "Our thermal battery requirement passed analysis, so we deleted the thermal-vacuum test to save money."
The error is treating analysis and test as interchangeable; you may still run the test for model validation, because an unvalidated thermal model gives an unverified answer, not a verified one.
Statement: "The FEA showed positive margin, so the structure is verified — no need for material data."
FEA output is only as good as its inputs; a stress result compared against an unverified material yield strength verifies nothing. Inputs (material properties, boundary conditions) must themselves be trusted.
Statement: "We ran acceptance test at 1.25× flight level to be safe."
Wrong level — 1.25× is the qualification level meant for a dedicated qual unit; running flight hardware at 1.25× needlessly over-stresses the parts you intend to fly and consumes fatigue life. Acceptance is 1.0×.
Statement: "Natural frequency shifted 3% after vibration, but that failed the < 5% criterion so we scrapped the unit."
A 3% shift is below the 5% limit, so it passes; the criterion flags shifts that are too large (evidence of stiffness loss / cracking), and 3% is within the allowed band.
Statement: "We verified the deployment requirement by analysing the hinge torque margin."
Analysis of torque margin is necessary but does not by itself verify the operational requirement that the appendage actually deploys; that needs a demonstration of the deployment event.
Statement: "The requirement is untraceable to a verification method, but the hardware works, so we're done."
Every requirement must map to a method through the traceability matrix; an unlinked requirement is unverified by definition, regardless of how the hardware appears to behave.
Statement: "We qualified with an old build, then changed the bracket, and kept the qualification valid."
A design change breaks the qualification pedigree; configuration management must flag that the tested article no longer matches flight, so re-verification (delta-qual) is required.

Why questions

Why can't you meaningfully "test" a mass requirement?
Because mass is a static property that exists with no environment or operation applied; subjecting it to conditions adds nothing, so weighing it (inspection) is the complete verification.
Why does qualification test above the flight limit rather than at it?
Manufacturing and environment both vary unit-to-unit; testing one article above the mean gives statistical confidence that the whole population of flight units stays within limits.
Why is analysis preferred for launch-load and long-duration space-environment requirements?
Those scenarios are expensive, destructive, or impossible to reproduce fully on the ground, so a validated physics model is the only practical way to cover them across the full requirement space.
Why must an analysis model be validated before its results verify anything?
An unvalidated model can silently mispredict reality (wrong boundary conditions, missing physics); validation against measured data is what turns a prediction into trustworthy evidence.
Why do we still test even after successful analysis in many programs?
To validate the model and to catch things analysis cannot capture — weld quality, assembly tolerances, contact nonlinearities — which are exactly the workmanship issues test is designed to expose.
Why does the combined uncertainty of two ±10% sources come out to ~14% and not 20%?
The two variations are independent, so they add in quadrature (), not linearly; independent errors partly cancel, so the total grows slower than a straight sum.
Why is a requirement's link in the traceability matrix considered part of verification, not just paperwork?
Without the link you cannot prove which evidence closes which requirement; verification is a claim about coverage, and untraceable evidence proves nothing about a specific requirement.

Edge cases

Edge case: The applied stress in an analysis comes out exactly equal to yield strength. What is the margin of safety and is it verified?
; this is a knife-edge pass at best and typically fails, because uncertainty can push the real part over yield — most programs demand strictly positive margin.
Edge case: A requirement has zero associated environment (e.g. "harness shall be color-coded per standard"). Which method applies?
Inspection — it is a static, visually observable property with no behaviour to analyse or test and no operation to demonstrate.
Edge case: Internal heat generation is zero and the spacecraft is in eclipse (no solar). What does the battery thermal balance reduce to?
With , the node only loses heat by radiation and conduction, so until it reaches the cold-case floor — this is exactly the worst-case cold scenario to check against the 0°C limit.
Edge case: The qualification factor is set to 1.0×. What has been lost?
All statistical margin — you are qualifying the design at the same level flight units see, so unit-to-unit variation can push some flight articles beyond what was ever demonstrated; qualification collapses into acceptance.
Edge case: An acceptance test finds no defect but the unit's frequency shifts 6%. Is it acceptable?
No — a 6% shift exceeds the 5% criterion and signals stiffness degradation (a possible crack or loosened joint), so the unit fails regardless of "surviving," because the pass criterion is about detecting hidden damage.
Edge case: A model predicts perfect compliance but was never compared to any measured data. What is the true verification state?
Unverified — the requirement is analysed but not verified, because an unvalidated prediction carries unknown error; the correct status is "open pending validation."
Edge case: A requirement can be closed by either analysis or test, and both are affordable. Which do you choose?
Prefer the one whose dominant uncertainty is smallest — if the physics is well modelled, analysis suffices; if workmanship or hard-to-model dynamics dominate, test, because the goal is minimizing the risk of a wrong "pass," not minimizing cost alone.

Recall Fast self-check

Which method for a mass limit? ::: Inspection. Which method for "antenna deploys on command"? ::: Demonstration. Qual level vs acceptance level factor? ::: 1.25× vs 1.0× of flight limit. Does surviving 8g verify a 10g requirement? ::: No — evidence stops at the tested level. What turns an analysis prediction into verification evidence? ::: A validated model.