Requirements-Driven System Design Process

After managing the development of two electric racecars over the past two years, I have noticed that the number of students who graduate with solid understanding of the system engineering design process is far and few between. This process is at the core of every engineering project and ultimately drives development forward. All engineers should know how the system design process works, not just project managers.

When you work in a fast-paced environment with short project timelines, it’s crucial to follow a process-driven methodology in order to optimize workflow efficiency. As systems become complex, this methodology becomes increasingly important for minimizing design errors and satisfying customer needs.

The graphic below outlines the system engineering design process. See V-model for an alternative representation.

System design process

System Engineering Design Process.png


Comprehensively defining your system and subsystem requirements is an extremely important step that I often see overlooked. Requirements can be thought of as pieces to a map. You need all the pieces in order to take the most efficient route to your destination. Without clearly defining all requirements, you’ll be trying to solve a problem without having all the variables. It doesn’t really work. The challenge is that customers often don’t know exactly what they want. They have a general notion of the final result, but, in terms of engineering requirements, they usually don’t know. That’s not their fault! It’s up to you to ask the right questions! Don’t let requirements get mired down because of poor communication.

All design elements and validation tests should be traceable to a system requirement and every requirement should be addressed by a design element and validation test. This ensures that everything necessary is accomplished and there is no excess in the design. There's no justification for designing something anything better than what the requirements dictate. One set of requirements is defined by whatever the device interfaces with.  Really think these through! This is the prime location for screwing up. Systems integration is almost always the toughest part of any project.  The next set of requirements is defined by the resources you have available - time, expertise, equipment, funding, etc. Capabilities ultimately drive project requirements. 

Five Takeaways

  • Process driven development is crucial to driving projects forward in the most efficient and thorough way possible. Don’t cut corners. The problems will only compound later and will likely results in missed deadlines and wasted resources.

  • Every design element and verification test should be traceable back to a requirement.

  • Your design should meet the requirements. Anything more is a waste of resources. Anything less and you’ll have a unhappy customer.

  • Systems integration is typically where the most design flaws emerge. This stems from poor requirements definitions.

  • Capabilities ultimately drive requirements.