A Common Language for Systems Engineers: Mapping the “Why Do I Care?” with the “How Do I Build It?”

To design and field a complex system, teams have to get the software on the chip, the chip on the board, the board in the box, and the box on the vehicle.

This takes collaboration at all levels. Engineers that specialize in a wide variety of disciplines must come together, solve hard problems, and communicate effectively. 

Systems engineers are the cross-functional experts that drive it all. They make sure all of the teams work together so that all of the components of the system work together. Systems engineers are cross-functional experts that help to coordinate interdisciplinary work within engineering teams, and disseminate information to other stakeholders, including teams who oversee other parts of a project, and customers. The systems engineer must be knowledgeable and have visibility into multiple disciplines, working across teams and tools.

This takes coordination and communication. A key building block to make this successful are a set of requirements that lay out the key criteria and specifications for the project. Like engineering teams, these requirements are not all uniform. For success, systems engineers must map requirements that describe the “Why do I care about what I am building?” with those that describe the, “How do I build it?”

In order to understand why this matters, let’s explore each of these categories.

First, let’s take the “Why do I care about what I am building?”

These are the high-level requirements that dictate what is needed for the system to meet an end user’s needs.

Let’s take the example of building an aircraft. You have to lay out how far you want it to fly, how many people you want inside of it — if any — how much fuel it will require. Systems engineers are responsible for keeping a repository of data on all of these, and communicating with the engineering teams designing each component.

These internal teams are responsible for the, “How do I build it?”

These requirements are determined and guided by engineers who are experts in specific disciplines.

Let’s take the example of a team that is working on the wing of an aircraft. The mechanical engineer that is designing the wing must determine the proper wing load stress. The electrical engineer that is responsible for control services inside of the wing must pick the right wire gauge that fits inside the wire harnessing to operate them. The fluids engineer is responsible for the fluid flow process from the fuel tank inside of that wing.

The systems engineer coordinates all of the work across each expert.

‍This is how we ensure that the fuel tank will fit within the available volume of the wing, while leaving enough room for the wire harnessing. The systems engineer is also the person that communicates to the team building the fuselage, which will eventually be attached to the wing.

The challenge comes in mapping the requirements to each other. Change is constant in an engineering project, so when one of the “Why do I care?” requirements changes, it impacts the “How do I build it?”

Let’s say a customer is seeing promise in an aircraft to fly far enough to complete a single mission, so they ask to expand the range.

In order to make this work, engineers have to find more margin. One potential solution is, If you adjust the engine and add more fuel, does it work with the size of the wing? 

To answer this question, systems engineers must gain an initial insight into whether a solution will work, complete cost calculations to determine the value of a change, test and validate the solution across engineering teams, and continuously communicate with the customer.

Typically, systems engineers have relied upon a model-based representation of the systems.

‍This requires a series of meetings to update, and it does not disseminate information to customers in a format that they can read.

But there is a disconnect between how they communicate with the customer and the engineering teams. Ultimately, they need a tool that maps the “Why do I care” with the “How do I build it?” 

It’s not a requirements management problem. It’s a data fabric problem.‍

That’s why Prewitt Ridge is taking a different approach.

Built by systems engineers with experience at SpaceX and Slingshot Aerospace, Verve by Prewitt Ridge applies DevOps principles developed to rapidly build and scale software to the design of complex hardware systems. Verve offers:

• A single source of truth that stores requirements in one centralized machine-readable location.
• Digital threads that trace the journey of requirements across teams and tools, throughout an entire engineering lifecycle.
• Automation features to streamline compliance.