4. Model requirements capture

Every CAE model exists to answer a question. In a release-audited workflow, that question must be written down before the mesh is generated, and it must be phrased in a form that a simulation result can actually confirm or refute. Requirements capture is the discipline of converting a stakeholder's design or certification question — often vague, qualitative, or buried in a standard — into a set of measurable acceptance criteria that the model, the solver setup, and the post-processing are all built to satisfy. If this step is skipped or done loosely, the audit trail collapses: nobody can demonstrate that the model was fit for the purpose it was used for, and "the results look reasonable" becomes the only defence.

The core failure mode is question–model mismatch. A design team asks "is the bracket strong enough?" A certification body asks "does the structure survive the 9 g forward load case without permanent deformation?" These are not the same question, and only the second one can be turned into a pass/fail criterion. Requirements capture forces that translation to happen explicitly, early, and in writing.

From stakeholder question to acceptance criterion

A useful way to structure the translation is to decompose each question into four linked elements: the quantity of interest (QoI), the load/environment case, the acceptance threshold, and the evidence requirement (what result artifact proves the criterion is met). Consider a worked example from a satellite equipment bracket, where the certification question is: "The bracket must not yield under quasi-static launch loads, and the first natural frequency must stay above 90 Hz to avoid coupling with the spacecraft bus."

Decomposing this gives two criteria. Criterion A: maximum von Mises stress in the bracket under the 9 g forward and 6 g lateral limit load cases must not exceed the material yield strength divided by a factor of safety of 1.25. Criterion B: the first eigenfrequency of the bracket-plus-representative-mass assembly must be ≥ 90 Hz. Each criterion now names a QoI (stress, frequency), a case (specific load directions and magnitudes), a threshold (yield/1.25, 90 Hz), and evidence (stress contour plus peak-location table, modal frequency table with mode shape plots).

Note what has been gained. The mesh must now be refined enough to resolve the stress peak at the bracket fillet — a coarse mesh that "looks fine" is no longer acceptable, because the criterion is tied to a specific location. The boundary conditions must represent the bolted interface to the bus, because the frequency criterion depends on it. The material card must carry a defensible yield value with a traceable source. All of these are model requirements that flow directly from the acceptance criteria.

Making criteria measurable: the four attributes

For a criterion to survive an audit, it should carry four attributes. First, quantification: a numeric threshold with units, not "sufficiently stiff" or "within acceptable limits." Second, location or scope: where in the model the QoI is evaluated (a named region, a node set, a component), because a global maximum and a local peak can differ by a large margin. Third, case definition: the exact load case, boundary condition set, and solver settings under which the QoI is computed, since stress and frequency are meaningless without them. Fourth, tolerance and rounding: how the comparison is made (e.g., stress rounded to three significant figures, frequency to 0.1 Hz) so that a result sitting exactly on the threshold is adjudicated consistently.

A common certification trap is the unstated reference frame. "9 g forward" is ambiguous until the forward axis is defined relative to the spacecraft coordinate system and the bracket's mounting orientation. Requirements capture must fix the sign and axis convention in the criterion itself, and the same convention must be carried into the load-case definition and the post-processing. If the convention changes between documents, the audit will flag it — and rightly so.

Structuring the requirements set

Real programs rarely have a single criterion. A bracket might carry a dozen: yield under limit load, no failure under ultimate load (1.4× limit), frequency separation, random-vibration response, and fatigue life. These interact. A mesh refined for the stress peak may be unnecessarily fine for the modal run, and a frequency criterion may drive the boundary-condition fidelity more than the stress criterion does. Requirements capture should therefore record, for each criterion, the model fidelity driver — the aspect of the model that most strongly affects that QoI — so that the modelling effort is allocated where it matters and the audit can check that the fidelity was actually delivered.

The table below shows a compact requirements register for the bracket example. It is deliberately terse: each row is a criterion that a reviewer can check against a result artifact.

The register is the contract between the analyst and the reviewer. It is also the seed of the audit checklist: every row must eventually be traceable to a model file version, a solver deck, and a result file, and the fidelity driver column tells the auditor exactly which modelling decision to scrutinise.

Where requirements capture goes wrong

Three failure patterns recur. The first is threshold drift: the criterion is set loosely at kickoff ("stress below yield") and then quietly tightened or relaxed during the project as results come in. The register must be version-controlled, and any change to a threshold must be recorded with its justification and the date — otherwise the audit cannot distinguish a legitimate requirement change from a result being massaged to pass.

The second is orphan criteria: a criterion exists in the register but no result artifact is ever produced for it, or the artifact is produced but never compared against the threshold. This is caught by requiring, at release, a one-to-one mapping between register rows and evidence artifacts. A criterion with no evidence is an open action, not a pass.

The third is over-specification: the register grows to include quantities that no stakeholder asked for and that do not affect any decision. Over-specified requirements inflate modelling cost and dilute the audit. The test is simple — if a criterion could be removed without changing any design, certification, or release decision, it does not belong in the register.

The requirements-to-model trace

The figure below shows how a stakeholder question flows into criteria, then into the model decisions that each criterion drives, and finally into the evidence that closes the loop at release. The key structural point is that the fidelity drivers are not generic — they are specific to each criterion, and they are what the auditor checks first.

The trace is deliberately narrow: each criterion drives a small number of modelling decisions, and each decision produces a specific artifact. When the auditor opens the release package, the register row, the model version, and the evidence file should line up without interpretation. That alignment is the whole point of requirements capture — it converts a judgement call at release time into a check that anyone can perform.

Practical guidance for the analyst

Start the register on day one, before any geometry is imported. Write each criterion in the form "QoI [units] under [case] shall be [comparison] [threshold] [tolerance], evidenced by [artifact]." If a stakeholder cannot supply a threshold, record it as an open item with an owner and a due date — do not invent one silently. When the model is built, walk the register and confirm that each fidelity driver has actually been addressed; a criterion whose driver was ignored is a latent audit finding. At release, produce the one-to-one mapping and treat any gap as a blocker, not a note.

Finally, keep the register alive through the project. Requirements do change — a load case is revised, a material is substituted, a certification authority issues new guidance. The register is the single place where those changes are recorded, justified, and re-baselined. A model released against a stale register is, from an audit perspective, a model released against no requirements at all.