Recently, I was involved in a discussion about when it is that a project transitions from systems engineering to detailed engineering. My answer was, “It depends.” One of my mentors suggested that a specific design level encompasses between three and five levels of decomposition. From experience, I tend to agree, but this is just a rule of thumb, and a specific design can cause us to decompose more or less than 3-5 levels. Additionally, when we know a design area well or if we’ve done the engineering tasks before and view a concept as low risk, then we are more likely to model less detail—and that’s OK. We need to and should focus on high risk areas.
One consideration that affects how soon you can go from big picture thinking to the more granular level of design is: number of stakeholders. When we design systems of systems, it’s important to remember that systems engineering tasks include all of the project’s stakeholders. The stakeholders are customers, program managers, electrical engineers, mechanical engineers, software engineers, test engineers, logisticians, manufacturers, and yes, systems engineers. No project is designed in a vacuum by a person with the title of systems engineer. A system of systems decomposition can result in the design of major subsystems which in another systems engineering effort could be a system unto itself, continuing for multiple levels.
Many years ago, I worked on the Strategic Defense Initiative. On that program, the primary system decomposed into a series of sensors and interceptors. These subsystems were major developments and would be systems unto themselves. So the decomposition had a full systems engineering effort, and the decomposition of that effort involved another round of systems engineering design.
On a small system or component design, the systems engineering effort may also and should have a multidisciplinary group of engineers similar to what was stated above. But here, the first level of decomposition may transition directly to detailed design in the form of a circuit board design, a chassis design, and software development. The engineering stakeholders may offer opinions on better ways to organize the project and architecture in order to reduce risks based on their experiences. In this paradigm, the systems engineer, most likely the technical director or chief engineer, weighs one thing against another—always trying to find a balance between low and high risks, low and high capability, and cost. The ultimate outcome, the systems engineer hopes, will be a design that reduces risk, maximizes capability, and minimizes costs, resulting in something that someone wants to buy.
Systems engineers should consider being done when there is enough detail for the next level designer to begin their work, enabling the greatest degree of design freedom for the next level designer. The challenge for the systems engineer is in finding the Goldilocks balance between providing too much detail and too little. Too much, and the design may be unnecessarily constrained, too little and the system doesn’t accomplish the desired effect.
(Read another of my blog posts that speaks to this issue: The Law of Conservation of Systems Engineering.)
I have personally seen the effects of insufficient detail on a number of projects. Once, a product was going to be used on an aircraft. The systems engineer did a good job of defining the breadth of functionality the subsystem needed to perform, but omitted some rather critical constraining requirements. What later was revealed in a design review was that the device could potentially be broken if struck by an external object, but when broken, the device couldn’t cause secondary damage to the aircraft.
In this situation, the device could break but not tear the skin of the aircraft. It could break but couldn’t be drawn into the engine’s intake. The mechanical engineer’s initial design, in the absence of guidance, provided for the device to withstand normal flight forces like air pressure, and even for it to withstand a considerable strike from a solid object. However, when struck, the devices would put a fairly large hole in the fuselage of the aircraft, tearing the flight surface. If during the systems engineering phase these requirements had been identified, the mechanical engineer would have chosen a different material and would have fastened the device to the fuselage differently. The mechanical engineer had not been given enough detail.
So when are we done, as system engineers? My opinion is we’re done when we’ve given the next design team the right amount of information so that they can effectively and efficiently execute designs. I use the three to five levels of decomposition as a guide, and I make it a habit to ask myself: “Is this too shallow? Too deep? Why? Is this the right level of detail?” What I have found is that when I do this on a consistent basis, the team, my boss, the client, the stakeholders—they all gain confidence that we’re moving in the right direction.
Happy engineering!
