Stop Treating Requirements as Obstacles, They're the Best Design Tool You Have

Every engineering project has constraints. Regulatory standards, safety codes, customer requirements, weight budgets. The instinct in a lot of engineering cultures, especially student engineering cultures, is to treat these as obstacles to work around. Boxes to check at the end. Paperwork that gets in the way of the real design work.

The Formula SAE Structural Equivalency Spreadsheet, the rules document that governs whether your chassis is at a bare minimum safe enough to pass technical inspection, taught me why that instinct is exactly backward.

What the SES Is

The SES is the competition's mechanism for verifying that a frame design provides equivalent occupant protection to a standard steel tube specification. It requires detailed documentation of tube sizes, wall thicknesses, material properties, and how load travels through every primary structural member, the roll hoops, the front bulkhead, the side impact structure, and their connections.

It is, depending on who you ask, one of the most demanding documents in collegiate engineering competition. Teams treat it as a nightmare. It changes year to year. Judges can reject submissions for details that weren't flagged in prior reviews.

We passed it on essentially our first substantive attempt. Here's why.

The Wrong Way vs. The Right Way

Most teams design their frame for months and then open the SES to check whether it passes. This almost guarantees problems. You'll find tubes that don't meet minimum requirements. Load paths that weren't considered during design because nobody was looking for them. Geometry that technically violates a rule that got forgotten.

Then you're either modifying a locked design, expensive, or making the argument to the rules committee that your non-compliant design is equivalent, which is a difficult conversation to have under deadline pressure.

We opened the SES at the start of the design process and kept it open throughout. Early on, before geometry was finalized, we were already asking: does this tube size meet equivalency for this member? Does this node location create a compliant load path to the hoop? Every simulation iteration we ran was tested against a frame that was already nominally rules-compliant. We weren't designing toward a target and then checking rules. We were designing inside the rules-compliant space from the beginning.

The IC team submitted SES five times before mid-November, not because we were failing, but because we started early enough that we had room to iterate and resubmit without pressure. Submit so far ahead of the deadline that you feel silly for doing it that early. The relief is worth it.

Rules as a Design Guide, Not Just a Filter

There's a deeper point beyond compliance strategy. The FSAE rules specify minimum tube sizes, required triangulation patterns, and rollover protection geometry. These rules exist because they encode decades of hard-won knowledge about what makes a steel space frame safe under real crash loading.

Designing within them from the start forces you to think carefully about load paths, triangulation, and structural redundancy, exactly the things that make a frame sound regardless of rules. A frame designed to satisfy the SES from the beginning tends to be a better-engineered frame, not just a more compliant one.

The rules aren't fighting against good design. In most cases they're pointing toward it.

The Seven Most Dangerous Words in FSAE

I put this line verbatim in the engineering manual we wrote for future teams: the seven most dangerous words in FSAE are "that's how we did it last year."

The equivalent in commercial product development might be "compliance is legal's problem" or "we'll deal with certification after the design is done." In all of these cases, the attitude substitutes assumption for understanding. You've decided that someone else's requirements don't apply to your situation, without actually checking. The bill comes due eventually, usually at the worst possible time.

Whether it's FSAE rules, FDA design controls, FCC certification, or a customer's interface specification, requirements documents represent accumulated knowledge about failure modes and performance minimums that someone learned the hard way. The engineers who treat those documents as design inputs, rather than final checkboxes, use them to structure their work, catch problems early, and produce designs that are simultaneously more compliant and more robust.

Build the requirements into your process from day one. They're not obstacles. They're the clearest signal you have about what the design actually needs to do.