An explanation of the scope and implementation conditions of systems engineering; SE is a methodology, not an answer.

Last time, in an article titled "An Introduction to Systems Engineering," I introduced a general overview, usefulness, and history of systems engineering.

I want to read it together

A Guide to Systems Engineering (SE) Do you know about Systems Engineering (SE)? As far as I remember, it became a hot topic in Japan in the following way: Systems Engineering…

From this point forward, we will be explaining the contents of the NASA Systems Engineering Handbook (Rev2, revised in 2016, which is the latest version as of 2026).

Since "NASA Systems Engineering Handbook" is quite long, I will refer to it as "NASA SE Handbook" from now on.

Let's start by looking at the preface and introduction.

The preface and introduction contain prerequisites for effectively and efficiently applying SE, and are often skipped over, but they are extremely important, so I will explain them thoroughly. Thank you for your attention.

Preface to the Revised NASA SE Handbook rev2

The NASA SE Handbook, originally written in 1995 as NASA/SP-6105 and subsequently revised in 2007 (Rev 1), reflects the rapid and continuous evolution of systems engineering as a frontline field within the National Aeronautics and Space Administration (NASA).

*NASA/SP-61065 refers to the NASA SE Handbook and is a number assigned to it in NASA's document management system.

Ongoing changes include the use of Model-Based Systems Engineering (MBSE) to improve product development and delivery, and compliance with updates to NASA Procedure Requirements (NPR) 7123.1.

Lessons learned regarding systems engineering were presented by NASA's Integrated Action Team (NIAT), the Space Shuttle Columbia Accident Investigation Board (CAIB), and subsequent...Diaz ReportThis was recorded in reports by, among others.

*NIAT is a special team that determines the future direction of NASA.
*The Diaz Report is a crucial report created by NASA in response to the 2003 Space Shuttle Columbia disaster, aimed at improving the organization's overall engineering capabilities and management culture.

Further lessons can be learned from robotic missions such as Genesis and the Mars Reconnaissance Orbiter, as well as from the ground-based and commercial spaceflight industries.

These reports have led to the NASA Office of Chief Engineers (OCE) taking the lead in improving the infrastructure and capabilities of NASA's systems engineering across the board, in order to efficiently and effectively engineer NASA systems, manufacture high-quality products, and ensure mission success.

This handbook update is part of OCE's overall efforts to improve systems engineering capabilities across NASA.

In 1995, SP-6105 was first published to disseminate fundamental concepts and methods of systems engineering to NASA personnel, taking into full consideration the characteristics of the systems and development environment that NASA handles.

The revised version (Rev2) of NASA/SP-6105 maintains the original philosophy,To update NASA's systems engineering body of knowledge and provide guidance for understanding current NASA best practices.Offer.

The Rev2 revision of NASA/SP-6105 inherits the methodology from the previous revision.NASASuperiorLevelTop-down alignment of policies and bottom-up injection of knowledge from NASA practitioners on the ground..
*The previous revision refers to the 2007 revision to Rev1, which integrated top-level organizational policies with on-the-ground practices.

This approach offers an opportunity to extract best practices from across NASA and bridge them into established SE processes, rather than prescribing how to perform specific tasks.An opportunity to present excellent practical principles and alternative approaches.It gives.

The results that have been compiled into this handbook are:Regarding NASA's unique systems engineering practices,HomeLevel implementation approachThis is a manifestation of that idea.

The materials used to update this book are drawn from a wide range of sources, including NPR (NASA Policy Requests), SE handbooks and processes specific to each center, best practices from other agencies, and external SE textbooks and guides.

This handbook consists of six chapters.

Each chapter is comprised of an outline, examples, and detailed appendices that complement the content. In addition, columns and diagrams placed throughout the book play a significant role in providing definitions of terms, in-depth explanations, visual images, and even advanced concepts.

Finally, this handbook is intended to provide top-level guidance for good systems engineering practices and is not intended to be a directive in any sense.

Acknowledgments: Acknowledgments (written with respect to each party)

In revising the NASA Handbook Rev2, we would like to acknowledge and commend the practitioners who made significant contributions to its content.

1. Introduction

1.1. Purpose

This handbook aims to provide general guidance and information on systems engineering that will be useful to the NASA community.

This handbook provides a general description of systems engineering (SE) that should be applied across NASA, and its goal is to increase awareness and consistency within NASA and advance SE practices.

We also provide NASA-related perspectives and NASA-specific data.

This handbook isNPR 7123.1 “Processes and Requirements for Systems Engineering”We strongly recommend using this as a practical guide to ensure the steady implementation of the specific handbooks and regulations established by each NASA organization in the field.

Furthermore, we recommend using this as a supplementary text for various systems engineering training programs provided with the support of NASA.

1.2 Scope and Depth

This handbook outlines best practices for systems engineering that should be applied to the development and implementation of NASA programs and projects, both large and small.

A systematic and disciplined set of processes is essential for the practice of systems engineering at NASA.

These processes are applied recursively and iteratively throughout the entire program or project lifecycle, from design and development to operation, maintenance, and finally to end-of-life (closeout).
*The word "recursive" is difficult to understand in Japanese.Separate articleI will explain this in more detail later. I want you to understand it step by step, so for now, just remember that it's a repetition of the same points.

This handbook applies to all aspects of systems engineering practices, regardless of whether the implementer is a manager or an engineer, or whether they are an internal or external (supplier) member of the organization.

For detailed practical guidance, please refer to the numerous department-specific handbooks, directives, and textbooks (this handbook is recommended to be used as supplementary reading).

NASA systems engineers,on NASA's websiteYou can also join the NASA Engineering Network (NEN) Systems Engineering Community of Practice (CoP) located at [location].
*You can view the content even if you are not affiliated with NASA, but you cannot participate in the community.

This website contains many resources useful for systems engineering, including numerous work products required in NASA's SE process and document templates for milestone review presentations.

This handbook is applicable to NASA spaceflight projects and research and development (R&D) programs and projects of all sizes.

While all 17 processes apply to all projects, the format, level of detail in documentation, and time scale will vary appropriately depending on the type, size, and complexity of the project.
*The 17 processes refer to the core of the SE process, which will be explained in detail later.

In terms of the level of detail required for documentation, this includes not only paper and digital files, but also models, graphics, drawings, or other appropriate formats that capture the intended information.

For a more detailed explanation of the principles provided in this handbook, see:NASA LibraryPlease refer to the NASA Expanded Guidance for SE located at [link/reference]. This handbook is a summary of that reference.

This page contains important insights and experiences from the author's practical work.

From here on, I will conclude by extracting and explaining the parts of the preface and introduction that I consider particularly important.

Point 1: Systems engineering is not about answers, but about guidance.

What this statement means is that systems engineering is not a solution that gives you the answer to a problem, but rather a methodology, or best practice.

To complement this sentence:Rather than defining how to perform a specific task,An opportunity to present excellent practical principles and alternative approaches.It says "..."

This is a major difference between this field and many other academic disciplines, technologies, and business tools.

In many academic fields and tools (apps and software), when you input something, it often presents something resembling an answer, or at least some kind of number. Unfortunately, systems engineering doesn't present anything resembling an answer, nor does it provide any kind of number at all.

Systems engineering rarely yields results unless the process is executed consistently (sampling it only yields partial effects, making it a poor investment).

From this, you can understand that simply trying out or partially using Systems Engineering will yield little to no results (this is my opinion based on my own experience).

If you decide to implement it and want to see some degree of results, I think you need to be prepared and tackle it drastically; otherwise, it will be difficult to see any effect.
*If you're hesitant about implementing it, or if you've implemented it but are having trouble getting it to work, please feel free to consult me! (lol)

Point 2: The importance of consistency across organizations and even suppliers

This sentence suggests that systems engineering is not effective when applied only partially, but rather when applied to the entire organization, and even to affiliated companies, unless the same systems engineering framework is applied to them as well.

I believe this is a major reason why many Japanese companies find it difficult to implement systems engineering and realize its true potential (I understand that it's difficult to judge overall compliance without partial success).

I agree that a sudden company-wide or all-group-company implementation would be difficult, so my recommendation is to apply it to an entire project; that seems like the minimum approach that would yield sufficient results.

Based on my personal experience, I believe that regardless of the size of the project, applying the principles thoroughly and without compromise throughout the entire project often yields positive results.
*If you're curious about how to apply this, feel free to ask me! (lol)

Point 3: The importance of differentiating between uses in detailed practical work and integrating with systems engineering.

The important point that can be gleaned from this sentence is that, paradoxically, applying systems engineering directly to detailed, practical tasks is not very effective.

In my experience, for detailed, practical tasks, sticking to traditional methods is often overwhelmingly more efficient (and poorly implemented systems can even be a hindrance).

As explained previously, the true potential of systems engineering lies in optimizing the whole rather than optimizing parts. Therefore, it's important to note that to use it at a detailed, practical level, you need to integrate elements of systems engineering with conventional methods.
*If you're curious about the details, feel free to ask me! (lol)

These three points are what I consider to be the most important.

Next time, we'll finally be discussing systems, which are the foundation of systems engineering, so please stay tuned.

I want to read it together

What is a system? – Understanding the fundamentals of "systems thinking" through abstraction and MECE (Mutually Exclusive, Collectively Exhaustive) Last time, under the title "Explanation of the Scope and Implementation Conditions of Systems Engineering: SE is a Methodology, Not an Answer," I explained the preface and introduction of the NASA SE Handbook...

• NASA Systems Engineering Handbook Rev2
  This book is the basis for this explanation. It is in the public domain, so you can get it for free.

• Systems Engineering Handbook, Keio University Press, supervised by Hidekazu Nishimura
  We'll be working hard to supervise the NASA handbook on this site, but it will take time, so if you want to learn the whole thing right away, I recommend this book. I own a copy myself.

Systems Engineering Handbook, 5th Edition

created by Rinker

Keio University Press

• Amazon
• Rakuten
• Yahoo Shopping