About Systems Engineering - Tom Python's Website

Introduction

Common Experiences in Projects

Components built separately by each department somehow don't work when combined
You built exactly what the specification said, but the client says "This isn't what we wanted"
When requirements change mid-project, you panic because you can't tell how far the impact reaches
No one has a grasp of the overall project picture
When problems occur, you can't explain where the root cause lies

These issues occur in projects of all sizes. Systematic approaches exist to address them, and one such approach is Systems Engineering (SE).

This article explains what SE is, why it's needed today, and how you can apply it in your workplace—using accessible language throughout.

What is Systems Engineering?

In One Sentence: "A Methodology for Making the Whole Succeed"

Systems Engineering is a systematic approach that integrates knowledge across multiple disciplines to achieve objectives optimally at the system level.

The term "system" here isn't limited to IT systems. It refers to the "whole" where various elements—hardware, software, people, organizations, and processes—interact and function together.

Consider an automobile. The engine, electronic controls, sensors, driver, maintenance infrastructure, road infrastructure—all of these must work together for it to function as "transportation." SE is a way of thinking that views such complex collections of elements as a "system" and designs for the success of the whole.

The Core of SE: Creating Value Greater Than "The Sum of Its Parts"

A crucial concept for understanding SE is "Emergent Properties."

Systems possess properties that only appear when viewed as a whole—properties that don't exist when examining individual components in isolation. For example, extracting a single neuron from the brain reveals no "consciousness." Yet when billions of neurons interact, consciousness emerges as an emergent property.

Product development works the same way. Even if excellent engineers create superior components, if the "connections" and "interactions" between them aren't appropriate, the system as a whole won't function. SE is distinctive in its focus on "relationships" and "overall behavior" rather than just "parts."

Why is Systems Engineering Needed Now?

The Explosion of Complexity

Modern products and services are more complex than ever before.

Automobiles: Once purely mechanical products, modern vehicles are "computers on wheels" with over 100 million lines of software code
Smartphones: Countless elements intertwine—hardware, software, communications, cloud services, payments, security, and more
IoT Products: Rather than standalone products, they're evolving into "systems of systems" where multiple systems collaborate

In such complexity, it's impossible for a single "genius engineer" to understand everything.

The Failure of "Telephone Game"

As projects grow larger, information passes through many hands. This is when "telephone game failures" occur.

For example:

Translation Loss: A requirement states "The system shall respond quickly." What does "quickly" mean—100 milliseconds? 1 second? Interpretations vary by person. When documentation only contains such abstract language, those who inherit the project face nightmares
Context Stripping: "What to do" gets communicated, but "why to do it"—the intent and background—gets lost
Silent Misses: Without understanding the scope of impact, problems emerge in unexpected places

Real-World Tragic Examples

Let's look at actual cases showing how devastating the lack of SE can be.

Mars Climate Orbiter Accident (1999)

NASA's Mars probe burned up in the Martian atmosphere. The cause was a "unit mix-up." Ground station software output thrust data in "pound-force," while the spacecraft interpreted it as "Newtons."

The data transfer itself was successful. However, the semantic information of "units" that should have accompanied those numbers was lost during handoffs between development teams.

Hyatt Regency Walkway Collapse (1981)

A hotel walkway collapsed, killing 114 people. The original design supported the 2nd and 4th floor walkways with a single long suspension rod. However, the contractor proposed changing to two rods because "manufacturing is difficult," and the structural engineer approved without detailed recalculation.

This change doubled the load on the 4th floor beam. A change made in the local context of "ease of construction" was approved without being evaluated against the global context of "structural load capacity."

Differences from Traditional Development Methods

The Strengths and Limits of Japanese "Adjustment" Culture

Japanese manufacturing has a strength called "suriawase" (mutual adjustment). Representatives from each component and module communicate closely, making fine adjustments through craftsmanship and experience to create high-quality products.

This method worked for many years. Even when specifications only stated "50kg," representatives would verbally supplement: "Oh, that's because of the assembly line robot arm limitations—we actually need to keep it under 48kg." Tacit knowledge was shared to compensate for documentation gaps.

However, this approach has limitations:

Software Invisibility: You cannot visually "adjust" dependencies among millions of lines of code
Globalization: "Unspoken understanding" doesn't work with overseas suppliers
Scale Expansion: As stakeholders increase, synchronizing everyone's "tacit knowledge" becomes impossible
Workforce Mobility: When veterans retire, the knowledge in their heads disappears with them

SE's Innovative Points

Compared to traditional methods, SE is innovative in these ways:

Aspect	Traditional Methods	Systems Engineering
Optimization Target	Local optimization (each department optimizes itself)	Global optimization (prioritizes achieving system-wide objectives)
Knowledge Form	Tacit knowledge (in veterans' heads)	Explicit knowledge (documented in models and documents)
Scope	Design to production	Entire lifecycle from planning to operation and disposal
Verification Timing	Verified collectively in later phases	Corresponding verification at each stage
Change Impact Assessment	Depends on human memory and experience	Traceable through traceability

Key Concepts of SE

The V-Model: A Symmetrical Development Process

The iconic process model of SE is the "V-Model."

    Requirements Definition ─────────────── System Verification
              ＼                                    ／
               System Design ─────────── Integration Testing
                    ＼                        ／
                     Detailed Design ─── Unit Testing
                           ＼          ／
                          Implementation

Left Side (downward flow): Decomposes from high-level requirements to system design to detailed design, becoming increasingly granular.

Right Side (upward flow): Integrates and verifies implementations progressively—unit testing → integration testing → system verification.

The key point is that each stage on the left has a corresponding verification on the right. What's decided in requirements definition is confirmed in system verification; what's decided in detailed design is confirmed in unit testing. This correspondence clarifies "what needs to be verified" and prevents oversights.

Traceability: Tracking the "Why"

Extremely important in SE is traceability.

This means explicitly recording and enabling tracking of connections between "requirements" ⇔ "design" ⇔ "implementation" ⇔ "testing."

For example, when trying to change a component specification:

Which requirement does this specification originate from?
What other designs does this change affect?
Which test cases need to be re-executed?

If these can be answered immediately, "unintended side effects" like Hyatt Regency can be prevented.

Verification and Validation: Two Distinct Types of Checking

SE clearly distinguishes two types of "verification":

Verification: "Did we build it right?" (Are we building the product right?)
- Confirms whether it was built according to specifications
Validation: "Did we build the right thing?" (Are we building the right product?)
- Confirms whether what was built meets the customer's actual needs

Even if something is built perfectly according to specifications, it's meaningless if those specifications don't reflect customer needs. SE manages both distinctions.

A Familiar Comparison: Smartphone Development vs. Space Development

Let's compare the degree of SE application across two different industries.

Smartphone Development

Development Cycle: Short cycles of about 1 year for new model releases
Handling Defects: Can be improved through post-release software updates or next models
Process: Speed-focused. "Build while fixing quickly" culture
SE Application Level: Formal SE processes are not necessarily applied

Space Systems Development (Rockets & Satellites)

Development Cycle: Long-term projects spanning 5-10 years
Handling Defects: Post-launch corrections are extremely difficult. "One shot"
Process: Formal reviews at each phase. Design, manufacturing, and testing proceed cautiously
SE Application Level: Rigorous SE processes following the V-Model are applied

The major difference between the two stems from "whether you can redo." (Well, if you have SpaceX's budget, redos might be possible.) Space development requires near-perfect completion from the first unit, making SE indispensable.

But how many projects really allow for redos? Perhaps more projects than we think don't allow for redos:

Loss of trust due to post-launch defects
Costs of large-scale recalls
Legal risks from security issues

The cost of "we'll fix it later" may actually be higher than we think.

How to Apply SE in Your Workplace

You Don't Need "Full-Spec SE"

When thinking about SE adoption, you might imagine buying expensive tools, conducting large-scale training, and completely overhauling processes.

However, the essence of SE is not "tools" or "processes" but "a way of thinking that surveys the whole (Systems Thinking)."

Even in small workplaces, you can incorporate these "lightweight SE" essentials.

Things You Can Start Today

1. Make a Habit of Recording "Why"

When deciding requirements or designs, record not just "what was decided" but also "why it was decided." When someone tries to change that decision in the future, understanding the background enables appropriate judgment.

[Decision] Response time shall be within 500ms
[Reason] User testing showed dissatisfaction with responsiveness when exceeding 500ms
[Related Requirement] REQ-023

2. Make a Habit of Confirming Impact Scope When Making Changes

When changing something, also confirm "if we change this, what else is affected?" Even using Excel, recording dependencies between elements makes understanding impact scope easier.

3. Distinguish "Verification" from "Validation"

Don't just confirm in testing that "it works according to specifications"
Also confirm from the user's or customer's perspective: "Does this really achieve the goal?"

Just consciously separating these two can reduce situations where "it meets specifications but isn't usable."

4. Create a "Common Language" That Even Non-Specialists Can Understand

Use diagrams and models to represent the system in a form that members from different specialties can understand. Words alone lead to interpretation gaps, but diagrams make differences in understanding visible.

5. Create Regular Time to Look at "The Whole"

Daily work tends to focus on your own area of responsibility. Establish regular opportunities (even weekly or monthly) to confirm "how things are going overall," so everyone can see the bigger picture.

Expected Benefits from SE Adoption

When SE is properly adopted, the following benefits can be expected (based on research data):

Reduction of Rework: If defect correction cost at the design stage is 1, it can balloon to several times or even hundreds of times at the operation stage. Early detection enables significant cost savings
Improved Project Success Rate: Data shows projects with high SE capability have significantly higher achievement rates for cost, schedule, and technical requirements
Fulfillment of Accountability: You can explain "why we chose this design" and "how far we tested"
Elimination of Key-Person Dependencies: Knowledge accumulates as organizational assets rather than remaining in individuals' heads

Steps to Get Started with SE

Beginner Level

Be Conscious of "Systems Thinking": In daily work, be aware of not just "parts" but "the whole" and "relationships"
Understand Basic Terminology: Grasp fundamental concepts like requirements, functions, architecture, verification, and validation
Understand the V-Model: Comprehend the basic flow of the development process

Intermediate Level

Learn SysML (Systems Modeling Language): The standard method for expressing systems in diagrams
Read ISO/IEC 15288: The international standard for system lifecycle processes
Practice on Small Projects: Try SE on a small project first

Advanced Level

Practice MBSE (Model-Based SE): Development centered on models rather than documents
Utilize Specialized Tools: Introduce SysML tools, requirements management tools, etc.
Build Organizational SE Capability: Process reform, talent development

Conclusion

Modern projects, whether we like it or not, are becoming increasingly complex.

Traditional approaches relying solely on "individual excellence" or "workplace tacit knowledge" can no longer cope with this complexity. This isn't a matter of ability—it's simply the fact that human cognitive capacity has limits.

Systems Engineering is a body of wisdom to compensate for these limits.

Reference Information

INCOSE (International Council on Systems Engineering): The international society for Systems Engineering
JCOSE (Japan Council on Systems Engineering): Organization promoting SE adoption in Japan
ISO/IEC 15288: International standard for system lifecycle processes
SysML (Systems Modeling Language): Standard language for system modeling