What software helps compare engineering design options while documenting trade-offs and uncertainty?

Compare complete alternatives.

Start by defining what each option actually includes. A design option is usually a package: a battery size with a thermal strategy and a control approach, or a structure with a material and a joining method. Compare complete packages, not individual components, unless the components really can be chosen independently. Include a credible baseline, and a staged or “defer” option when waiting is a real choice.

Screen requirements before comparing preferences.

There are two different questions in any comparison. Does this option meet the mandatory requirements? And among the options that do, which best serves the priorities? Answer them in that order. A weighted score cannot make up for a failed requirement: an option with the best overall score that misses a mandatory limit is still infeasible. Keep pass and fail visible for every requirement, with the margin, so reviewers can see how close each option came.

Keep the engineering measures next to the scores.

Scores and weights compress information. Reviewers also need the underlying measures in their units: range in miles or kilometres, mass in kilograms, cost per unit, weeks to production readiness. When a score and a measure tell different stories, the measure is usually the better guide to what is happening.

Make uncertainty explicit.

Every comparison rests on estimates. Show that uncertainty instead of hiding it in a single number:

• Define scenarios. Identify the operating conditions that matter, such as extreme cold, heavy towing or high duty cycles, and evaluate each option in each one.
• State the percentile used for acceptance. Judging a requirement at a conservative percentile, rather than the median, is a choice. Record it.
• Run sensitivity checks. Vary the key assumptions and the stakeholder weights. Find where the preferred option changes, and how far the inputs must move before it does.

A recommendation that holds across reasonable changes is stable. One that flips with a small change in a single assumption tells you where to collect more evidence.

Separate disputed evidence from different preferences.

When stakeholders disagree, find out why. Sometimes they dispute the evidence: one team believes a test result, another does not. Sometimes they accept the evidence but weigh it differently. The two call for different responses, more evidence in one case and an explicit decision about priorities in the other, so record which disagreement you have.

Record why options were rejected.

Six months later, the most common question is not “why this option?” but “why not that one?” Record the reason each serious alternative was rejected: a failed requirement, a weaker result under the priorities, or a risk the team was not willing to carry.

What to ask of any software.

• Does it treat mandatory requirements separately from weighted criteria?
• Does it show the engineering measures, with units, alongside any scores?
• Can it evaluate options across scenarios and report the percentile used?
• Does it show sensitivity to assumptions and stakeholder priorities?
• Does it link each result to the evidence and model version that produced it?
• Can it produce a review package with the rejected options and their reasons?
• When evidence changes, can the earlier comparison still be inspected?

Specialist simulations and engineering models should remain in their own tools. The comparison should use their outputs as evidence rather than replace them.