4. Requirements engineering for CAE automation programs

CAE automation programs fail far more often from misunderstood requirements than from weak scripting. A solver wrapper that runs flawlessly but reports the wrong margin, or a batch mesher that produces models no analyst trusts, is a requirements defect — not a coding defect. Requirements engineering for CAE automation is therefore the discipline of converting vague stakeholder expectations ("make the crash workflow faster") into verifiable statements that a script, a pipeline, and a regression suite can actually satisfy.

4.1 The Three Stakeholder Classes and What Each Actually Needs

CAE automation has three distinct stakeholder classes, and they rarely want the same thing. Treating them as one voice is the most common source of scope creep.

• Analysts / simulation engineers care about fidelity, traceability, and the ability to override automation. Their real requirement is usually "the automated deck must be equivalent to my manual deck within tolerance X," not "the tool must be fast."
• Program / project management cares about cycle time, cost per load case, and auditability. Their requirement is typically expressed as a metric: "reduce model build-to-first-result from 6 hours to under 90 minutes for a standard 12-load-case durability set."
• IT / platform owners care about licensing, compute scheduling, data retention, and security. Their requirement is often a constraint rather than a feature: "no solver license may be held idle for more than 5 minutes," or "all intermediate files must reside on the managed NAS, not local scratch."

A useful technique is to record each requirement with an explicit source and rationale. When a conflict appears later — for example, analysts want interactive override while IT wants fully headless execution — the rationale field makes the trade-off negotiable instead of personal.

4.2 From Needs to Use Cases

Raw needs are statements of pain; use cases are statements of behavior. A CAE automation use case should name the actor, the trigger, the preconditions, the nominal flow, and the postconditions in terms of artifacts on disk or in the PLM/simulation data management system.

Consider a representative use case for a structural durability pipeline:

Two properties distinguish a good CAE use case from a generic software use case. First, the postconditions are artifacts, not states of mind — a file path, a manifest, a report. Second, the alternate flow is where the engineering value lives: automation that silently solves a bad mesh is worse than no automation.

4.3 Acceptance Criteria That Can Be Executed

Acceptance criteria must be testable by a script or a reviewer without renegotiating intent. For CAE automation, three families of criteria cover most cases:

1. Numerical equivalence. "For the reference model BRKT-014, the automated pipeline shall produce a peak von Mises stress within ±2% of the manually built baseline, and fatigue life within ±5%." The tolerance is stated, the reference is named, and the comparison metric is defined.
2. Performance and throughput. "A 12-load-case durability set shall complete within 90 minutes wall-clock on the standard 32-core node, with no more than one solver license checked out at a time."
3. Robustness and failure behavior. "Given a CAD input with a non-manifold edge, the pipeline shall abort before meshing, write a defect report naming the offending edge ID, and exit with a non-zero status code."

Note that criterion 3 is as important as criterion 1. Automation is judged by how it fails, because a silent wrong answer propagates into design decisions.

4.4 A Worked Example: Turning a Vague Request into a Spec

Suppose a program manager says: "The crash team spends too long setting up frontal impact models. Automate it." The requirements engineer's job is to decompose this into verifiable statements. A reasonable first pass:

REQ-CRASH-001  The pipeline shall accept a CAD assembly and a
               load-case identifier (e.g., FRONTAL_50KPH_ODB)
               and produce a solver-ready LS-DYNA deck.

REQ-CRASH-002  The deck shall reproduce the baseline model
               BRKT-014 within these tolerances:
                 - total mass:            ±1.0%
                 - peak intrusion:        ±3.0 mm
                 - HIC (where applicable): ±5.0%

REQ-CRASH-003  The pipeline shall run headless on the Linux
               compute cluster and shall not require a GUI
               session.

REQ-CRASH-004  On any meshing or connectivity failure, the
               pipeline shall emit a defect report and exit
               non-zero; it shall not submit a partial deck
               to the solver.

REQ-CRASH-005  Every run shall write a manifest containing
               the CAD revision hash, material library
               revision, solver version, and input deck hash.

Each of these is checkable. REQ-CRASH-002 is the fidelity contract; REQ-CRASH-004 is the safety contract; REQ-CRASH-005 is the traceability contract. Together they define what "done" means for the first release.

4.5 Traceability and Change Control

Requirements do not stay fixed. When the material library is revised, REQ-CRASH-002's tolerances may need re-baselining. When the solver is upgraded, REQ-CRASH-005's manifest schema may change. A lightweight traceability matrix — requirement ID, source, use case, test case, status — keeps these changes visible. In practice, a spreadsheet or a YAML file checked into the same repository as the automation code is sufficient; heavyweight requirements management tools are rarely justified for a single program.

The critical discipline is that every acceptance test in the regression suite must trace back to at least one requirement, and every requirement must have at least one test. Orphan tests waste compute; orphan requirements ship untested behavior.

4.6 Common Failure Modes in CAE Requirements

Three patterns recur across programs. First, tolerance-free fidelity claims: "the automated model should match the manual model" without a number. This is untestable and will be argued about at every review. Second, missing failure criteria: the spec describes the happy path only, so the pipeline solves garbage meshes and the team discovers it three revisions later. Third, unowned constraints: IT's licensing limit is discovered during integration rather than during requirements, forcing a redesign of the job scheduler.

Done well, requirements engineering is the cheapest phase of a CAE automation program and the one that most determines whether the delivered pipeline is trusted. A one-page spec with named references, numeric tolerances, explicit failure behavior, and a traceability matrix will outperform a hundred-page document of aspirations every time.