How to Write an Engineering Requirements Document

Originally published on fastradius.com on July 12, 2021

An engineering requirements document (ERD) is a statement describing the goal and purpose of a new component. Unlike a product requirements document (PRD), which tells engineers what they need to build, an ERD specifies why a part is being built and how its design fuels its purpose. By following the engineering requirements outlined in an ERD, engineers can ensure that the part they build will satisfy customer needs. Using an ERD also helps streamline production in various ways:

• ERDs use defined and consistent communication to promote collaboration, reduce miscommunication, and keep everyone on the same page.
• ERDs help break down large projects into smaller tasks, making them easier to delegate or outsource.
• ERDs can be checked against PRDs to ensure all design intentions are correctly implemented and all product goals are achieved.

A well-written ERD allows engineers and manufacturers to answer critical questions about part design and purpose without going back and forth. This results in a faster, more efficient building process that saves you time and money. Here’s everything you need to know to write a clear and effective engineering requirements document.

Standard criteria for an engineering requirements document

To start, all effective engineering requirements documents have the following six elements in common:

Clarity

All engineering requirements should be clear, short, and unambiguous in order to avoid confusion. Less is more — often, a one-sentence description will suffice.

Necessity

To avoid confusion or contradictions, only put the absolutely essential requirements in your ERD. Determine the worst case scenario for each requirement and if there aren’t any consequences, there’s no need for it to be in your ERD.

Coordination

Engineering requirements should be correct throughout product design. An ERD should describe all product requirements, goals, conditions, and capabilities. Whenever possible, explain what the product does in a numerical manner for the most precision.

Testability

Whenever you write a new engineering requirement, you must be able to verify a successful implementation. There are many different kinds of testing methods to ensure verifiability, including inspection, user testing, software testing, and system integration testing. Choose the testing method that makes the most sense for your project.

Feasibility

Stay within the limits of what can be achieved technically, as well as what is legally, organizationally, and financially possible. Be reasonable and honest, since creating non-feasible requirements will cause complications down the line. If feasibility can’t be reached, you can state a design detail as a goal rather than a requirement.

Traceability

Any engineer looking at your ERD should be able to trace each requirement back to the original product’s purpose. Linking implementations back to product goals helps explain why an element is important, where it’s coming from, and how it makes sense with the overall part design.

Tips for writing a good engineering requirements document

Once you’ve made sure that the standard criteria have been accounted for, you can implement best practices that will take your engineering requirements document to the next level. Here are five tips for writing a top-notch engineering requirements document.

Use an engineering requirements template

You can save time and energy at the beginning of a new project by using an engineering requirements document template. An ERD template ensures your ERD is always properly structured. At a minimum, an engineering requirements document template should have a cover page, section headings, and other standardized sections known as “boilerplates.” Use boilerplates to cover ERD topics like verb use, abbreviations, keywords, formatting standards, and other guidelines necessary for understanding your ERD.

Avoid writing operations and implementations

Your engineering requirements should state a goal, not how the goal will be achieved. If you explain the steps towards completing a purpose instead of the purpose itself, you’re not really writing an ERD — you’re writing an operations and implementation guide. If you write an operations and implementations guide by mistake, a manufacturer might misunderstand your intentions and your project goals might not be met.

To ensure your requirements are indeed requirements, ask yourself why this requirement is a necessary part of your engineering requirements document. Trust that the system designers and manufacturers will determine how the goal will be achieved and that they’ll do so in the most efficient way possible.

Evaluate your ERD

This will help verify that all engineering requirements meet your stated goals and company aspirations. For a well-rounded evaluation, it’s best to put together a diverse team. This includes bringing people of all races, ethnicities, and genders together to evaluate your engineering requirements document, but also includes bringing a diversity of roles to the evaluation. Include as many roles as you can — designers, developers, testers, end-user representatives, those in charge of maintenance and management, and of course the client team — to bring plenty of valuable insights to your ERD evaluation.

Use the right language

There are some language rules you should always follow when writing an engineering requirements document. The big three ERD-specific terms are shall, will, and should. “Shall” represents requirements, “will” represents facts, and “should” represents goals.

A specific ERD term that is often misused is support. In ERD terms, “support” references a structure’s ability to hold or take weight, not that it will support or accomplish certain capabilities.

In general, stay away from terms like are, is, and was in the engineering requirements themselves. You can use them in a descriptive section or leading into a requirement, but avoid them in your requirement itself to promote specificity. You should also avoid vague terms like:

• But not limited to or etc. — These terms cover the unknown and there should be nothing unknown or unpredictable about your ERD.
• And/or — This leaves too many options for interpretation and room for error because a contractor will be right in two different scenarios (if they choose AND or if they choose OR).
• Weak words that don’t have quantitative meanings. This includes adjectives like “powerful” and “efficient” as well as verbs like “enhance” or “strengthen.” Also, try to avoid comparisons (for example, quickly or slowly, most or few) and other non-quantitative language.

When writing ERDs, you should also avoid negative statements and focus on the existence of a requirement’s element or capability. The only time it’s acceptable to use negative specifications is when emphasizing a potentially dangerous situation. Even in these instances, make sure to state the safety case as well.

Don’t be overly specific

Although there are a lot of language rules to follow when writing your engineering requirements document, keep it simple. Clarity is key for ERDs, so only focus on the necessary goals, objectives, and constraints of your requirement. Always have a reason for putting in a requirement — too many requirements will muddle your ERD and confuse readers. If you feel your requirements becoming too long and complicated, use bullet points to split up its elements.
Having a well-written engineering requirements document (ERD) will help engineers, product teams, and other collaborators better understand your design intentions. By clearly connecting a component’s design to its specific goals and overall part purpose, an ERD ensures a product is built in a way to satisfy customer needs.

Most importantly, a great ERD promotes collaboration, communication, and clarity throughout the design and manufacturing process. This will ensure each and every part is fully functional and will complete its desired objectives. Along with ensuring part-to-part consistency, an ERD also promotes faster production runs and lower costs.

Whether you’re writing your first engineering requirements document or well practiced, SyBridge Technologies is here to help at every stage of the development and production process. Our team of expert designers, engineers, and manufacturers are here to ensure your part accomplishes all of its goals. Contact us today.