What is “Systems Engineering in Commercial Organizations?”

Since I started implementing systems engineering processes and practices in commercial organizations, one of the standard questions I hear is…

So, what is this “systems engineering” anyway?

While each implementation has its nuances, the fundamental building blocks of commercial systems engineering are as follows:

1. Requirements Development & Management (RD&M)
   
2. Product Architecture
3. Design & Development Management
4. Integration
5. Verification & Validation (V&V)

Now, let’s open up each of these building blocks a bit further.

Requirements Development & Management is where everything starts. Typically delays in commercial and government programs are attributed to poor RD&M. First, not all requirements are created equal and the organization’s product development needs determine the types and levels of requirements that should be part of their processes and practices. The most common types of requirements are:

• User requirements
• System-level technical requirements
• Sub-system level technical requirements
• Product life-cycle requirements

Second, the management of each type of requirement is different from one and other because their purposes are different. Similarly, within each group of requirements, there are differences in priority and importance.

Architecture definition is the highest level solution to the set of requirements. A good architecture definition clearly shows the main components of the solution, identifies primary technologies and clearly states the interfaces (both internal and external to the system to be developed). The architecture definition should define the system to designers and developers in an unambiguous way and represent the system in different ways to different disciplines. For example, a hardware designer would be mostly interested in the physical dimensions, volume, weight, so on so forth. On the other hand, the control software developer will look for state definitions, timing diagrams, and so on. The role of the architecture definition is to anchor the system definition while allowing designers and developers freedom to conduct their art and expertise.

Design & Development Management is the act of leading the design & development teams and ensuring that detail designs meet the system-level objectives. It is common for designers and developers to lose sight of the “big picture” when dealing with many challenges of design & development. Moreover, there will be decision points where initial requirements and allocations may need to be modified and re-allocated. These decisions are mainly made according to the impact of the change on the system, which the systems engineer is responsible for.

Integration happens at many levels, from integrating resistors, capacitors and ICs on a circuit board to integrating a new service to a global organization. Regardless, the goal of integration is the same: build something larger than the sum of its components. Each integration step directly links to a V&V step.

Verification & Validation: While many people use these words interchangeably,  they have two very distinct meanings. Using an old definition, “Verification is ensuring that the system is built right. Validation is ensuring that the right system is built.” The former is checking the sub-system and the system against technical requirements to find out whether or not the requirements are met (it is built right). The latter is the ultimate test; check it out with the intended customers and markets. Does it meet their needs? Are they willing to buy it? Did we build the right system?

Done right, systems engineering processes and practices drastically improve the effectiveness of product development organizations. Done wrongly, they are just another addition to processes, practices and tools, which will be overlooked and slow down the organization.