When I was hired as an aerospace engineer intern, the satellite company I had just joined was in the process of building their systems engineering department from a few engineers to triple digits. I was curious as to what was driving that huge hiring ramp up… so I started to dive into systems engineering.

Now let’s take 3 steps back. What do you mean by V? If you are new to systems engineering, let me introduce you to the V!

Source: “The Systems Engineering V Diagram,” ResearchGate, 2017.

The systems engineering V is a known concept in the industry which illustrates the workflow of a systems engineering department. It starts from requirement definition and decomposition from system level to subsystem and component, all the way to integration and test of those requirements.

You’ll see arrows going back and forth from one side of the V to the other… because that’s quite literally how it works in the real world. The engineers working in design, interfacing with the client and defining and decomposing the requirements work hand in hand with the engineers implementing those requirements and testing them both in software and hardware.

As you might expect, if a requirement isn’t met, we have to go back to the drawing board and figure out ways to make it work. Does the requirement need to change? Or can we find a different part, different supplier, implement the software differently, flex the requirement bounds, etc. This happens until all teams are satisfied with what we know as the “good enough” in engineering. Is it safe and can it do the thing well enough?

The company was going from legacy designs, which they had nailed for decades, to new mission types driven by contracts with NASA. That meant new designs, hence new requirements, and taking it all the way from one side of the V to the other… and then cycling back. And for that, the company was going to need an entire department to handle that and make sure the new designs were going to meet those requirements.

Is systems engineering for you?

If you like design, high level thinking and project management then I would say systems could be a good place for you.

Now here is the thing… and this is coming from a friend of mine who has worked as a systems engineering manager for years now:

“To be a good systems engineer, you first must go do the dirty work. Get a few years working with hardware, software, understand how things are built and tested, and then go become a systems engineer. Because then you will know what the thing is supposed to do so you can actually write requirements and work with clients effectively.”

I cannot agree more with him.

Working in systems engineering as an intern, I got to see how many new hires without any prior knowledge in systems engineering got thrown into projects where they didn’t even understand the hardware or software of the satellite, and yet somehow they had to design, write requirements and decompose them to the best of their ability. It was painful to watch.

If your goal is to build your skillset starting from college…

The first thing I would recommend doing is understanding the basics of requirement writing and decomposition.

What is a good requirement vs a bad one?
How do you test, verify or validate a requirement?
What is a trade study and how do you effectively weigh different designs to come up with a good option?

Example:

Bad requirement:
“The system should be fast.”

Good requirement:
“The system shall respond within 200 ms under nominal operating conditions.”

This is one of those questions hiring managers love to ask!

Where I fit in this space

Lastly, there are several types of systems engineers as you can imagine. Look at the V… every section within that V is a systems engineering role. Some are dealing with requirements at system level, some at subsystem level, others are working directly with the hardware or the software, implementing those requirements and testing them… just to name a few.

That is the space I live in as a modeling and simulation systems engineer. Sometimes I help define the requirements for the software I am developing, and other times requirements are flowed down to me to implement, test, and get ready for release.

So depending on the role, you might interact with the same system at different points in the V.

Now here are some of the resources you can use to get familiar with systems engineering and start building your skillset: 

• Fundamentals of Systems Engineering
• Systems Engineering Fundamentals PDF Book
• What Is Systems Engineering? – Brian Douglas MATLAB Tech Talk
• NASA Systems Engineering Fundamentals