PPI SyEN 151 | May Edition by PPISyEN

PPI SyEN

EMAIL: PPISyEN@PPI-Int.com

EDITORIAL STAFF

Editor

John Fitch

Editor-in-Chief

Robert Halligan

Managing Editor

Francois Retief

PRODUCTION STAFF

Marketing Manager

Rebeca Verhagen

Graphic Designer

Matthew Wong

Publishing Assistants

Trudy King

Joshua Nagra

PUBLISHER

Project Performance International

2 Parkgate Drive

Ringwood, Vic 3134 Australia

Tel: +61 3 9876 7345

Tel UK: +44 20 3608 6754

Tel USA: +1 888 772 5174

Tel China: +86 188 5117 2867

www.ppi-int.com

PPI SyEN (PPI Systems Engineering News journal) is published quarterly.

Archived editions and subscriptions to future editions are available for free at: https://www.ppi-int.com/syennewsjournal/

WELCOME

Dear Readers,

Welcome to the Q2 edition of PPI Systems Engineering Newsjournal (SyEN).

One of the more interesting aspects of assembling this edition was the strong common theme that emerged across three very different articles.

Art Villanueva’s From Mechanic to Gardener explores the growing risk of confusing systems engineering with procedural compliance, arguing that genuine systems engineering is ultimately a discipline of judgment, adaptation, and cultivation rather than checklist completion.

John Fitch’s Rethinking Requirements Derivation – With AI Support examines the practical strengths and limitations of applying modern AI tools to decision-centric requirements derivation. The results are both impressive and cautionary, particularly when structured engineering logic meets persuasive machine-generated output.

Finally, Syenna’s Do AI Dream of Names? reflects on the increasingly collaborative nature of conversational AI and the subtle ways persuasive systems may influence how engineers think, reason, and frame problems.

Together, these articles circle a shared and increasingly important question:

As engineering tools become more capable, fluent, and persuasive, how do we preserve the critical thinking and systems judgment needed to recognize when the question itself may be incomplete?

This edition also includes a broad collection of systems engineering news, conferences, resources, research highlights, and developments across MBSE, AI-enabled engineering, digital engineering, requirements engineering, system dynamics, and related disciplines.

We hope this edition provides both practical value and a few ideas worth reflecting on long after the final page.

Best wishes,

Francois Retief Managing Editor

Views expressed in externally authored articles are not necessarily the views of PPI nor its professional staff.

PPI Systems Engineering News journal (PPI SyEN) seeks:

➢ To advance the practice and perceived value of systems engineering across a broad range of activities, responsibilities, and job descriptions

➢ To influence the field of systems engineering from an independent perspective

➢ To provide information, tools, techniques, and other value to a broad spectrum of practitioners, from the experienced, to the newcomer, to the curious

➢ To emphasize that systems engineering exists within the context of (and should be contributory toward) larger social/enterprise systems, not just an end in itself

➢ To give back to the Systems Engineering community

PPI defines systems engineering as:

An approach to the engineering of systems, based on systems thinking, that aims to transform a need for a solution into an actual solution that meets imperatives and maximizes effectiveness on a whole-of-life basis, in accordance with the values of the stakeholders whom the solution is to serve. Systems engineering embraces both the technical and management dimensions of problem definition and problem-solving.

SYSTEMS ENGINEERING NEWS

Recent events and updates in the field of systems engineering

The INCOSE Q1 2026 Members Newsletter provides a summary of the organization's recent contributions to advancing the practice of systems engineering worldwide.

The theme of this 104-page edition can be summarized in the following quote from Michael Watson, INCOSE President:

Systems engineering is advancing faster than any discipline in the history of engineering and technology.

Watson and Steve Records, Executive Director, highlighted the opportunities presented by the rapid advancement of the systems engineering discipline and how this speed of change is reflected in INCOSE strategic planning and capability growth initiatives. Changes occurring in the INCOSE Corporate Advisory Board (CAB) support this view, with increased emphasis on its Voice of the Customer role, deeper collaboration with technical leadership and working groups, and practical influence through real-world grounding of best practices and priorities.

International Workshop 2026 (IW26)

Reports from IW26 filled this edition of the Members Newsletter. Here is a brief sample of the highlights and insights gleaned from the perspectives of different groups and participants:

• IW26 boasted over 450 participants, hailing from 55 chapters across 25 countries, with 125 first-time attendees. Over 150 Systems Engineering Professionals (SEPs) were among the participants.

• Project Wildfire hosted multiple workshops that advanced the application of systems engineering to community-mission-driven emergency management.

• INCOSE Spain focused its insights from IW26 on the essential nature of the human interface in the systems that we engineer and human connections among the members of the SE community.

• During IW26, the INCOSE Foundation honored the recipients of the Stevens Doctoral Award, Serena Campioli and James Hand, for their research in advancing the discipline.

• The INCOSE PM-SE Integration Working Group focused on review and updates to relevant portions of the Systems Engineering Body of Knowledge (SEBoK).

• The Configuration Management Working Group held productive sessions, which led to increased emphasis on gathering inputs on CM practices from multiple domains.

A draft outline was prepared for adding CM for models to their Guide for CM.

• The INCOSE Los Angeles Chapter noted the emergence of a clear trend, i.e., that the discipline of SE is rapidly advancing toward a digitally integrated model-centric ecosystem.

• The Midwest Gateway Chapter observed the theme of continuous integration, continuous deployment (CI/CD) throughout IW26. It recognized that much work remains to realize the benefits of such a pipeline.

• The Requirements Working Group continued making progress on updates to the Needs and Requirements Manual (NRM).

Other News

• Thirteen chapter updates (beyond the IW26 news and insights summarized above) were provided in this edition.

• Two INCOSE Fellows, Alejandro Salado and Yoram Reich, were recognized.

• Preparations continue for the 36th Annual International Symposium (IS2026) that will take place in Yokohama, Japan, in June. The theme of this event, “Beyond Digital Engineering: Seeking Wa in SE,” recognizes the need for harmony (Wa) in the human endeavor of systems engineering.

• INCOSE is launching a new Podcast series, with Episode 1 featuring INCOSE President, Michael Watson.

INCOSE 2025 Annual Report

This 41-page document summarizes the organization’s “strategic pivot” away from a Board focused on operational execution and tactical oversight toward long-term strategy and governance. Membership reached almost 28,000 during 2025, with 88 countries represented.

Over 5000 Systems Engineering Professionals (SEPs) are currently recognized. Forty universities now partner with INCOSE in qualifying their students for SEP recognition through the Academic Equivalency program.

IW2025 in Seville, Spain, had 656 participants. 907 participants gathered in Ottawa, Canada, for IS2025.

INCOSE had 52 active Working Groups in 2025. 163 organizations participated in the Corporate Advisory Board.

SysML v2 Releases and Resources

The Object Management Group (OMG) has announced the 2026-01 and 2026-02 releases of the Systems Modeling Language™ Version 2. The 20261 release is now publicly available here and includes formal versions of the KerML 1.0, SysML 2.0, and Systems Modeling API 1.0 specification documents.

This release implements trigonometric functions and makes technical improvements to the abstract syntax implementation. The release includes files collecting the Backus-Naur Form (BNF) specifications for the KerML textual notation and the SysML textual and graphical notation. KerML Project Archive (KPAR) files are also included for all the standard library models.

View the 2026-01 release notes.

The 2026-02 release consists entirely of bug fixes and technical updates, i.e., no language or library changes.

The specification documents, along with training material on the textual and graphical notations, can be found here

JupyterHub is a cloud-based service providing multi-user Web access to virtual servers running Jupyter (see https://jupyter.org/hub). A JupyterHub deployment of the SysML v2 Pilot Implementation is available to the community at the SystemsModeling.com site run by Model Driven Solutions. In addition to JupyterHub, this site also hosts the next-generation OpenMBEE Flexo repository for SysML v2.

UAF 1.3 Release

The Object Management Group (OMG) released version 1.3 of the Unified Architecture Framework (UAF) in April 2026. UAF is an OMG standard that assists in the development of architectural descriptions in commercial industry firms, federal government agencies, and defense organizations. UAF provides a specification document aimed at the community of enterprise architects, architects of information technology systems, and systems engineers, as well as a wide range of other users, such as enterprise managers, program managers, and subject matter experts.

Download the 266-page UAF 1.3 Specification Document and 298-page Modeling Language (UAFML).

SysON New 2026 Releases

SysON is an open-source web-based toolset to edit SysML v2 models. Obeo, a primary contributor to the Eclipse SysON project, has announced the release of SysON 2026.1 and 2026.3.

The SysON 2026.1 release focuses on improving the user experience while adding new features. Enhancements in this release include:

• Visual improvements such as default graphical node sizes, connection representations, inter-compartment moves, and auto-resizing

• New compartments, e.g., SatisfyRequirements and Items on Parts

• Comment nodes displayed in the General View

• Duplication of semantic elements

• Auto layout options (Flow, Compact)

• Textual export performance.

View the 2026.1 release notes for details.

The SysON 2026.3 release focuses on improving the robustness and usability of the modeling experience:

• Improves connection routing around ports and parameters

• Adds support for nested attributes

• Enables resizing elements to be smaller than previously allowed

• Improves the handling of special characters in textual imports/exports

• Extends search capabilities across libraries and projects

• Displays views in a collapsible panel to improve navigation

• Enhances the ability to generate customizable model validation rules.

View the 2026.3 release notes for details.

The SysON user interface is built on Sirius Web, another Eclipse open-source project that has complementary 2026.1 and 2026.3 releases focused on improving the user experience and team efficiency.

Get started with SysON here.

Modelica Association News

Modelica is a freely available, equation-based, object-oriented language for convenient and efficient modeling of complex, multidomain cyber-physical systems described by ordinary differential, difference, and algebraic equations. The Modelica Association is a non-profit organization that develops coordinated, open-access standards and open-source software in the area of cyber-physical systems. Highlights from the Association’s (April 2026) newsletter are found below.

Board Highlights

A report from Dirk Zimmer, Modelica Association Chair, focuses on upcoming regional events in America and Asia:

• 20-22 September: Asian Modelica & FMI Conference in Hangzhou, China

• 12-14 October: American Modelica & FMI Conference in Atlanta, Georgia, USA Conferences and User Meetings

In addition to these Association events, two vendor-led conferences were noted:

• Wolfram System Modeler User Conference 2026 (Virtual) – Completed. View recordings.

• 22-23 September: ThermoSim 2026 – Conference for Thermal System Simulation in Aachen, Germany.

Functional Mock-up Interface (FMI) News

The Functional Mock-up Interface project reports:

• Dassault Systèmes will host the next in-person FMI Design meeting on 8-10 June in Munich, Germany

• More than 280 tools now support FMI.

FMI Layered standards continue to advance with:

• Alpha pre-release of FMI Layered Standard for reference (FMI-LS-REF)

• V1.3.0 alpha release of FMI Layered Standard for Network Communication (FMI-LSBUS)

• V1.0 beta release of FMI Layered Standard for Structured Data (FMI-LS-STRUCT)

• New working group supporting Differential-Algebraic Equations (DAE).

Modelica Vendor News

Dassault Systèmes has released updates to the Sustainable Supply Systems library (SuSy), Battery Library 2.9.0, and Testing Library 2.0.0, in conjunction with its Dymola 2026x Refresh 1.

Siemens Digital Industries Software has released Simcenter Amesim 2604 featuring major enhancements to the Battery Pack Assistant, gas system simulation, and FMU export capabilities. MLQT, a desktop tool for managing Modelica libraries, has been released for Windows, with a Linux version planned.

OpenModelica 1.26.3 has been released, addressing GUI issues and improving overall stability. A built-in Model Context Protocol (MCP) server is planned for release 1.27.0, offering support for AI assistants within a modeling session. A benchmark suite of AI-enabled Modelica tasks is under development.

The Modelon Impact Code Studio now offers a cloud-native AI-assisted coding experience for Modelica developers, along with a new Data Center Library for physics-based system simulation.

XRG Simulation has published a paper, “Modelica-driven development of the thermal management control system for a zero-emission yacht”, that highlights the virtual development and testing of a heat management control system.

Modelica Education News

Newly published educational resources are available for the Modelica community, including:

• FMI Users Guide Ver.2.0.2 (English translation of Japanese Automotive Engineers –JSAE document)

• From Intent to Insight: AI-Driven, Physics-Based Modeling with Modelica (blog post)

• Getting Started with Modelica (book)

• Learn Modelica & FMI (LinkedIn newsletter)

• Thinking in Systems, Not Code (book)

View details of these and other announcements in the latest Modelica Association newsletter.

Updates to the Systems Engineering Tools Database (SETDB)

The Systems Engineering Tools Database (SETDB), developed by PPI in partnership with INCOSE, provides a virtual platform for engineering tool vendors to communicate their latest offerings.

Recent SETDB updates, including both new tools and updates to existing tools, include:

Vendor: Advanced Visual Systems Inc.

• AVS/Express: AVS/Express’s drag-and-drop capabilities, rapid user interface, advanced visualization methods, and cross-platform compatibility enhance the engineering, medicine, telecommunications, and environmental research fields' need to handle heavy graphics demands with an intuitive interface.

Vendor: CIL4Sys Engineering

• Sim4sys Virtual-Bench: A playground for building functional digital mockups of systems of systems, where engineers create scenarios, link graphical objects to Sim4Sys Designer models, and test system behaviors.

• Sim4Sys Designer for Papyrus: A dedicated profile and plugins implement the “Customer-in-the-Loop” approach in Eclipse Papyrus, guiding engineers and automating modeling tasks to accelerate design, ensure consistency, and generate requirements, specifications, and executable code.

Vendor: Datastorms

• Datastorms: An advanced Model-Based Systems Engineering (MBSE) platform designed to master complexity in infrastructure, energy, and the high-tech manufacturing

industry.

Vendor: Excel Software

• WinA&D: A software design tool for the Windows platform for use by software developers for Requirements Management, UML, SASD, BPMN, Flowcharts, PERT Charts, System Models, Data Models, Screen Models, and Code Generation.

• MacA&D: A software design tool for the Macintosh platform for use by software developers for Requirements Management, UML, SASD, BPMN, Flowcharts, PERT Charts, System Models, Data Models, Screen Models, and Code Generation.

Vendor: Kompozition Pty Ltd

• Kompozition: Kompozition platform is an industry-leading Model-Based Systems Engineering tool that champions the adoption of Digital Engineering and Mission Engineering practices and their benefits to organizations.

Vendor: N-able

• N-central: N central unifies IT and security operations, reducing costs while harmonizing processes. It provides real-time insight into devices and critical assets, automatically enforces security and performance standards, and intelligently alerts teams to failures, helping maintain business continuity.

• CMMC Compliance: N central for CMMC Compliance plays a key role in this journey by providing tools to address key technical requirements, helping organizations maintain security, and align with compliance objectives.

• Vulnerability Management: Provides simple and smart vulnerability defense from discovery to remediation with automated scans, fully integrated scanning, prioritization, and remediation without extra agents, third-party tools, or added friction.

Vendor: REQTEAM GmbH

• Add-On Excel-Reqif: The ReqEdit Add-on Excel-ReqIF is a converter for Excel files into ReqIF files. The software converts worksheets into ReqIF Specification documents, preserving the formatting of text, attached files, and links between rows.

Vendor: SAE International

• J3307_202503 - STPA Standard: This standard defines the steps, tasks, and flow necessary to execute a System Theoretic Process Analysis (STPA) system safety evaluation and outlines the expected deliverables. It applies to all industries and utilizes state-of-the-art STPA methodologies developed over the past decade.

Vendor: Siemens PLM Software

• Teamcenter: A modern, adaptable product lifecycle management (PLM) system that connects people and processes across functional silos with a digital thread for innovation. The robust Teamcenter portfolio depth helps solve the challenges required to develop highly successful products.

• MBSE: Model-Based Systems Engineering: MBSE (model-based systems engineering) is a critical part of Teamcenter product lifecycle management (PLM). MBSE with Teamcenter brings together multi-domain product development – mechanical, electrical, and software - along with considerations like cost, reliability, and manufacturability.

• Teamcenter Integrated Requirements Engineering: Captures and manages requirements and enables you to allocate (trace) them to downstream functional, logical, and physical architectures - all while generating the reports, documentation, and dashboards to manage the requirements process.

• Teamcenter Manufacturing Process Planning and Data Management: A solution intended for teams to establish a single source of product and process knowledge to re-use best practices and manage resources for continuous improvement.

• Teamcenter Materials Data & Lifecycle Management: A solution intended for teams to help you manage the lifecycle of all the materials used in your products so that your company can create innovative, sustainable products.

Vendor: Visual Paradigm

• Agile Project Tools: A suite of agile and scrum tools intended for agile teams to manage development projects. They include Project Management, Agile Process, Scrum Process, User Story mapping, quality improvement, and roadmap visualization.

• Project Management Process Tool: A suite of specialized project management process tools intended for teams to improve their project management efficiency using Project Management Body of Knowledge (PMBOK) processes, PM guides, and PM process mapping.

PPI SyEN readers are encouraged to check out these new and updated systems engineering tool offerings.

Access the SETDB via PPI’s Systems Engineering Goldmine or the SETDB website .

CONFERENCES, MEETINGS & WEBINARS

Events of relevance to systems engineering

MBSE Summit 2026: Program Details

Program details are emerging for the MBSE Summit 2026 in Traunkirchen, Austria, on 8-9 June 2026. Hosted by LieberLieber, the conference offers attendees the opportunity to hear from experts in MBSE research, development, and practice.

The conference will open with Dr. Ralph Hammer of the Austrian Federal Ministry of Finance, who will share his expertise in security research and technology transfer.

Four additional keynotes have been announced:

• Applied MBSE in the Devil‘s Triangle of collaboration, integration and segregation (Christoph Neuböck and Arjen Spaans, Airbus Defense and Space)

• Beyond Digital Blueprints: Effective Model-Based Systems Engineering (Joseph Green, Medtronic)

• From Models to Mission: Building Better Systems Faster with MBSE, DevSecOps, and AI (Robin Yeman, Leidos)

• The Architect's Ego: How MBSE is bottlenecking product development (Enrique Krajmalnik, ALM at PTC).

Three breakout sessions are planned:

• AI-Assisted MBSE: From Static Models to Intelligent Engineering Companions

• DevOps in MBSE: Implementing a Digital Engineering Strategy

• Model-Based Engineering for Product Velocity: Turning Models into Competitive Advantage.

View the detailed agenda. Register here.

PDMA Webinar: Using AI to Accelerate Innovation

The Product Development Management Association (PDMA) will host a free webinar on 11 June titled “Using AI to Accelerate Innovation,” presented by David Robertson from MIT Sloan School of Management.

Overview

You know AI will disrupt your products, but how will it disrupt your innovation process? How

CONFERENCES, MEETINGS & WEBINARS

can you use AI to accelerate your process and improve the results? This webcast will teach you how to apply AI to every step in your innovation process, and show you how to apply the lessons to a real product or service concept.

Key Takeaways

• Understand a proven process that will guide the selection and use of AI tools, both now and in the future.

• Learn a set of AI-driven techniques for every step in the innovation process: creating new concepts, targeting customers, analyzing requirements, developing prototypes, and testing innovations quickly and economically.

• Identify the tools you’ll need to continue innovating with AI in the future.

Learn more and register for this event.

System Dynamics Summer School 2026

Introductory Track

The System Dynamics Society (SDS) is offering two members-only opportunities to learn system dynamics concepts and skills and gain application experience through the System Dynamics Summer School, which will run from 8 June (start of pre-work) through live online sessions on 6-9 July 2026.

The Introductory Track is for individuals with no or very limited System Dynamics knowledge. The purpose is to teach the System Dynamics methodology and not specific software syntax. There will be models available in Vensim, Studio, and Stella. Free versions of modeling software that are limited in capability or limited in duration of use will be available. Introductory Track instructors include:

• Birgit Kopainsky, University of Bergen

• Rod MacDonald, James Madison University

• Raafat Zaini, James Madison University

• Erica Rieder, Montana State University

• Hector Menendez, South Dakota State University

• Souleymane Bah, Worcester Polytechnic Institute.

Introductory Track Daily Schedule

Modeling Steps & Problem Definition

Formal Modeling of Stocks and Flows

Nonlinear Relationships

Model Analysis

Model Use

Modeling Feedback Mechanisms

Conceptual Modeling with Stocks and Flows

Workshop: Introduction to System Dynamics

Modeling Software

CONFERENCES, MEETINGS & WEBINARS

Information Delays

Workshop: Accumulation, Feedback, and Information Delays

Applications Lecture

Policy Modeling

Model Validation

Applications Lecture

Workshop: Common Pitfalls and Best Practices

Applications Lecture

Participants in the Introductory Summer School may attend online classes at times convenient to European or American time zones. Both tracks will cover the same material. Each track will convene three times per day for 90-minute sessions.

Intermediate Track

Qualifications for the Intermediate track include a self-assessment test over the basics of system dynamics. The Intermediate track focuses on software (Studio, Vensim, and Stella). It presents more advanced modeling techniques. Free versions of System Dynamics modeling software that are limited in capability or limited in duration of use will be made available. Intermediate Track instructors include:

• Willem Auping, TU Delft

• Bob Eberlein, isee systems

• Ying Qian, University of Shanghai for Science and Technology.

Intermediate Track Daily Schedule

Steps of Modeling: Problem Description

Model Building: Stocks and Flows

Checking Results with Equilibrium Diagrams

Diagrams to Show Feedback Loops

Simulating Nonlinear Relationships

Simulating the Flow of Information

Checking Results with Delays in the Flow of Information

Applications Lecture

Recognizing and Avoiding Common Pitfalls

Validation Testing: For Us & Our Client

Applications Lecture

Model Improvement

Applications Lecture

CONFERENCES, MEETINGS & WEBINARS

Live, instructor-led online sessions of the Intermediate Summer School will be scheduled to accommodate participants from around the world, with final timing based on participant preferences once the roster is finalized.

Both courses require significant pre-work in the form of watching videos and tutorials prior to the week of synchronous class sessions.

Learn more about the SDS and join to participate in the Summer School.

See more details on the System Dynamics Summer School and register before 14 June 2026.

INCOSE IS2026 Registration and Program Highlights

The INCOSE International Symposium 2026 (IS2026) will take place on 13-18 June 2026, in Yokohama, Japan. The theme of IS2026 is Beyond Digital Engineering: Seeking Wa in SE. “Wa” is the Japanese term for harmony.

Keynote speakers for IS2026 have been announced and include:

• Dr. Yuko Harayama, Secretary General of the Global Partnership on AI (GPAI) Tokyo Expert Support Center (What Does Human Touch Mean in the Age of AI? A Society 5.0 Perspective)

• Prof. Giancarlo Guizzardi, University of Twente, Netherlands (Topic TBD)

• Fumiya Tsutsui, Director of JAXA Space Exploration Center (JSEC) & Pressurized Rover Engineering Center (Engineering challenges for the world-first space vehicleLunar Camping Van).

A sample of approximately 20 tutorials and master classes offered on 13-14 June, includes:

• A "Wa- Uchi-Soto-Ma" Introduction to Systems Thinking and Systemically Engineering Systems

• Aiding Systems Engineering Practitioners make the Impossible Probable

• Effective leadership of modeling

• Enterprise Systems Engineering: An Emerging Discipline to Facilitate Transformation of an Enterprise

• From Features to Factories: Developing end-to-end Product Lines with Intelligent MBPLE

• How to Orchestrate in Ecosystems?

• Introduction to STAMP (Systems-Theoretic Accident Model and Process) methods: Integrating Modeling and Simulation in Systems-Theoretic Accident Analysis

• Machine Learning in Systems Engineering Applications

• Problem Formulation in Systems Engineering: From Implicit Practice to Disciplined Capability

CONFERENCES, MEETINGS & WEBINARS

• Taming Complexity: The CASA Mindset for Systems Engineers.

Check back here for the IS2026 Schedule at a Glance and evolving program details. Register for IS2026.

Project Summit – Business Analyst World Events

The International Institute of Business Analysis™ (IIBA®) has endorsed a series of Project Management - Business Analysis (PMBA) conferences scheduled for the remainder of 2026.

• ProjectSummit*BusinessAnalystWorld – Washington, D.C (15-17 June)

• ProjectSummit*BusinessAnalystWorld – Chicago, IL (5-7 October)

• ProjectSummit*BusinessAnalystWorld – Boston, MA (19-22 October)

• ProjectSummit*BusinessAnalystWorld – Vancouver, BC (2-5 November).

Check out the full program (symposium sessions, keynotes, workshops, and speakers) and registration details under each event.

21st Annual SoSE Conference (SoSE 2026)

IEEE System, Man, and Cybernetics Society (SMC) will host the 21st International Conference on System of Systems Engineering (SoSE 2026) at the University of South-Eastern Norway (Kongsberg Campus) from 28 June to 1 July 2026. The theme for this in-person conference is The World as Systems of Systems.

Keynote speakers have been announced for SoSE 2026:

Jos Benschop,

Executive Vice President Technology, ASML NL

Title: Optical lithography: a system within a system

For more than 50 years, the electronics industry has been marching to the beat of Moore’s Law, producing faster, cheaper, and more energy-efficient computing and data storage. Artificial intelligence is expected to boost the semiconductor industry to a one-trillion-dollar scale within the next few years. The semiconductor industry is a complex ecosystem spanning the globe. For example, a chip in a smartphone might be designed in the USA, built in Taiwan, using equipment made in Europe. ASML is the world leader in photolithography, one of the key enablers behind Moore’s Law.

In the keynote, after a short introduction to the world of semiconductors, it will be shown how systems engineering is applied to design and build our products (a complex system) and

CONFERENCES, MEETINGS & WEBINARS

to optimize the ASML scanner in our customers’ fabs (a system within a complex system).

Hildegunn McLernon, Senior Vice President Technology Office, Kongsberg Maritime

Title: Vessel of the future – an integrated system of system approach

The maritime industry is facing increasing system complexity driven by rapid technological development, growing requirements, limited standardization, and diverse operational demands across market segments. As vessels evolve into highly connected, software intensive systems, value creation increasingly depends on how effectively multiple products, platforms, and partners are integrated into coherent system of systems solutions. This presentation demonstrates how Kongsberg Maritime applies systems engineering to manage this complexity and enable reliable, safe, and sustainable vessel infrastructures of the future.

Karen V. Czachorowski, Digital Technology Lead, Aker BP

Title: Agentic AI: Orchestrating the Industrial System of Systems

This keynote explores the potential of Agentic AI as an orchestration layer for complex industrial “systems of systems.” Drawing on Aker BP’s AI-native strategy, we outline the proposed framework and building blocks - such as common context, secure tool access, and governance - necessary to move from simple interoperability to agentic cooperation. Through conceptual and early-stage use cases and development examples, this keynote illustrates how this emerging layer can help independent systems reason and act together safely in safety-critical environments.

Jørgen Hals, Lead Scientist, Corpower Ocean

Title: Solving Multi-disciplinary and Complex Problems

At the conference, Todalshaug will share views on how the company has addressed challenges in solving multi-disciplinary and complex problems, and now, as the company is moving into industrialization, link this to a system of systems perspective.

Christopher Jouannet, Principal Engineer, Aircraft Conceptual Design, SAAB

Title: Getting the Problem Right: Foundations and Open Challenges in System-of-Systems Engineering

System-of-Systems Engineering efforts often struggle due to incomplete or premature problem formulation in early development phases. As aerospace and defense systems become increasingly collaborative and dynamic, early framing decisions strongly shape architectural feasibility and long-term adaptability. Drawing on research and industrial practice, this keynote highlights key gaps in current SoSE approaches and identifies priority areas where further research is needed

Special sessions for SoSE 2026 will focus on Defense & Security, Robotics, and Smart Manufacturing.

CONFERENCES, MEETINGS & WEBINARS

Look for program updates here. Register for SoSE 2026.

European Conference on Modelling Foundations and Applications (ECMFA)

The 22nd European Conference on Modelling Foundations and Applications (ECMFA) will take place in Rennes, France, from 29 June through 3 July 2026. This event provides a forum for advancing the state of knowledge and fostering the application of all aspects of Model- Based Engineering (MBE) and related approaches.

The keynote address at ECMFA will be delivered by Mark van den Brand of Eindhoven University of Technology.

Technical papers are planned for the following tracks:

• Foundations of MBE

• Novel paradigms, formalisms, applications, approaches, frameworks, or processes

• Interplay between MBE with and for AI-based systems.

• Application of MBE methods, tools, and techniques to specific domains

• Successful use of MBE in connection with other disciplines and approaches

• Educational aspects of MBE.

• Tools and initiatives for the successful adoption of MBE in industry.

Check back here for updates on the evolving program details.

International System Dynamics Conference (ISDC 2026)

Registration is now open, and program details are emerging for the International System Dynamics Conference (ISDC 2026) which will take place on 20-24 July 2026. The in-person portion of this hybrid event will be hosted in Delft, The Netherlands. The System Dynamics Society (SDS) has defined the theme of ISDC 2026 as Navigating uncertainty, managing instability and crafting futures together.

ISDC 2026 is the 44th event in this series. The SDS reports a record number of submissions (560), indicating the growing global interest in the discipline of system dynamics. Featured (plenary) speakers for ISDC 2026 include:

• Meltem Ceylan Alibeyoğlu, Systems Thinking Association in Turkey (Systems Thinking in K–12 Education in Türkiye)

• Mohamed Jalloh, Université Cheikh Anta Diop de Dakar (The MADCaP Consortium: Addressing Prostate Cancer Disparities in Black Men)

• Rafael Prieto-Curiel, Complexity Science Hub (Recruitment, Incarceration and

CONFERENCES, MEETINGS & WEBINARS

Rehabilitation: Modelling Cartel Dynamics).

A series of virtual pre-conference events will take place on 14-16 July, including:

• Student-Organized Colloquium (SOC) – online 15-16 July; in-person 20 July

• Conference workshops

• Modeling Assistance Workshop

• Chapter and Special Interest Group meetings

View the Conference Schedule

Call for Submissions: AI4SE & SE4AI Workshop 2026

The Systems Engineering Research Center (SERC) will host the AI4SE & SE4AI Research and Application Workshop on 22-23 September in Washington, D.C. The theme of this workshop is Speed and Innovation through AI4SE & SE4AI.

The Call for Submissions for this event seeks abstracts from government, industry, and academia for three types of contributions:

• paper presentations

• insight sessions on new challenges or trends

• demo sessions.

The workshop will collaborate with INCOSE’s Systems Engineering journal on a special issue for the publication of selected papers.

Topics of interest include:

• SE4AI: Leveraging systems engineering principles and methodologies to develop safe, robust, and efficient AI systems, while extending these principles and methodologies in response to the nature of AI-enabled systems.

• AI4SE: Application of AI in support of systems engineering processes, by enabling enhanced decision-making, optimization, validation, verification, and alleviation of mundane tasks.

Abstracts are due by 5 June. All abstracts and presentations must be cleared for public release.

CONFERENCES, MEETINGS & WEBINARS

Call for Presentations: NAFEMS Multiphysics Conference 2026

A Call for Presentations has been issued for the NAFEMS Multiphysics Conference 2026 that will take place in Detroit, Michigan, USA, on 27-29 October. The theme of this conference is Powering the Future of Mobility to highlight how Multiphysics simulation enables the automotive industry to push the boundaries of innovation while simultaneously enhancing safety and performance.

Topics of interest include:

• AI/ML

• Battery and Electromagnetic Simulations

• NVH and Aeroacoustics

• MBD

• Water Splash

• Human Body Modeling

• ADAS Simulation Applications

• Multi-Scale Material Modeling

• Topology Optimization

• Reduced Order Modeling (ROM)

• Digital Twins

• Resource Scarcity

• Renewable Energy

• State-of-the-art Coupled Solvers.

Presentations are welcome beyond the automotive sector for domains such as aerospace, energy, life sciences, and manufacturing.

Abstracts (300-600 words) are due by 10 July.

IEEE Requirements Engineering Conference (RE'26)

The 34th IEEE International Requirements Engineering 2026 Conference (RE’26) will take place in Montreal, Quebec, Canada, from 17-21 August. The conference enables researchers, practitioners, students, and educators to meet, present, and discuss the most recent innovations, trends, experiences, and issues in the field of requirements engineering.

The theme of RE’26 is Sustainability and workforce transformation in the era of generative AI: How to prepare for a future in collaboration with AI tools and assistants.

Keynote talks for RE’26 include:

CONFERENCES, MEETINGS & WEBINARS

Lessons from the Trenches in Building Agents for Software Development (Graham Neubig, Carnegie Mellon University)

Over the past year, AI agents have rapidly developed from a curiosity to a core part of many development workflows. While this development may seem like it was inevitable, it was actually built on a series of rapid technological advances, many built with the assistance of software development agents themselves. In this talk I will talk about several key technologies enabling software-based agents, including the simple but powerful tools developed to provide models with the interfaces that they need, rigorous evaluation benchmarks, and training of agentic models. Further, I will talk about some developing research topics, such as encouraging human-agent interaction, agent memory, and task decomposition.

Orchestrated Work: AI and the Future of the Workplace (Christof Ebert, University of Stuttgart)

The workplace of knowledge workers is heavily changing. Artificial intelligence is not simply augmenting software engineering - it is redefining how work is structured, executed, and governed. Coding is already felt irrelevant by some AI protagonists. Yet, we do not see much productivity improvement, as the very same people now fiddle with copilots and waste time in reworking and polishing their outputs. Most AI is currently introduced ad-hoc without even baselining previous status, nor what are improvements and what are failures. This keynote analyzes implications for the future of work, learning, and expertise. Building on current industry insights from different domains it introduces Orchestrated Work as a unifying paradigm for AI-native organizations. It stimulates industry, research, and education to evolve the workplace and thus envisions a viable position of human knowledge workers in an AIdriven economy.

Bridging the Sociotechnical Gap: Human-Centered AI Transparency (Q.Vera Liao, University of Michigan)

There is often an inevitable gap between what a computational technology can do and the nuanced human requirements in the context where the technology is deployed. The age of AI has brought new challenges to understanding and mitigating this sociotechnical gap. In this talk, I will discuss these new challenges in the context of AI transparency - enabling appropriate understanding of AI technology - for which AI research has developed an abundance of techniques, including explainable AI (XAI), uncertainty quantification, and model evaluation. I will discuss our approaches to bridging the sociotechnical gap for AI transparency: conducting critical investigations into dominant AI transparency paradigms; studying people’s transparency needs in diverse contexts; and embedding sociotechnical perspectives in the evaluation practices to shape technical development.

RE’26 also provides the venue for numerous recurring workshops, relevant to the RE community:

• AIRE: Artificial Intelligence and Requirements Engineering

• CrowdRE: Crowd-Based Requirements Engineering

• ESPRE: Evolving Security and Privacy Requirements Engineering

• HCARE: Human-Centered AI for Requirements Engineering

CONFERENCES, MEETINGS & WEBINARS

• MoDRE: Model-Driven Requirements Engineering Workshop

• REACH-AI: Requirements Engineering for Accountable and Conscious Humancentered AI

• RETRAI: Requirement Engineering for Trustworthy AI

• REWBAH: Requirements Engineering for Well-Being, Aging, and Health.

PPI SyEN readers are encouraged to investigate the scope and objectives of these companion events.

Check back here for updates on the evolving program details.

Call for Speakers: Digital Thread Conference 2026

The Digital Thread Conference 2026 (DTC26) will take place on 23-24 September. This free virtual event is hosted by Intercax, developers of the Syndeia™ digital thread platform for model-based engineering.

The Call for Speakers for this event seeks industry presentations and panel discussions that support the conference theme, From Thread to Intelligence: Powering the Next Generation of Digital Engineering.

Session topics include:

• Digital Engineering Mandates

• Bridging the Silos

• AI-Powered Threads

• Automation & Flow

• Insight at Every Level

• Trust by Design

• Infrastructure for Intelligence Session abstracts should be sent to dtc26@intercax.com no later than 15 July.

“Requirements should not, and must not, be viewed in isolation, but rather viewed as how they relate to the whole.”

Lou Wheatcraft

FEATURE ARTICLES From Mechanic to Gardener: Rescuing Systems Engineering from the Compliance Trap

by Art Villanueva, DEng, ESEP, Phronos drartv@outlook.com

Authored for PPI SyEN

Abstract

Model-Based Systems Engineering (MBSE) has been mistakenly conflated with systems engineering, reducing a discipline of judgment and decision-making to a compliance exercise. In practice, MBSE often generates auditable artifacts that satisfy reviews while real engineering decisions occur elsewhere, creating an Illusion of Compliance. Drawing on themes from The Gardener and the Machine, this paper argues that systems engineering is a Gardener’s discipline focused on resilient outcomes under uncertainty, while MBSE, as commonly practiced, functions as a Mechanic’s compliance engine. To restore the discipline’s authority, MBSE must be repositioned as a support tool for engineering insight rather than a substitute for it.

The Problem: An Illusion of Compliance

Across many organizations, systems engineers are trapped in a cycle of performative rigor. Enormous effort is invested in MBSE tools and governance. System models grow in detail, becoming intricate and internally consistent. Their primary purpose, however, is to pass an audit.

When consequential design decisions are made, they are driven by the real-world pressures of analysis, simulation, and expert judgment. The system model, the official record, is updated afterward. It is an act of administrative alignment, not engineering discovery. The model ensures the story is straight for the reviewers.

This creates a persistent sense that the work is hollow. From a Mechanic's perspective, this is a resounding success. The artifacts are complete. The traceability matrices are filled. The boxes are checked. The project is compliant. Yet, the value is absent. This is an illusion of compliance: we have built a system that looks perfect on paper and satisfies the rulebook, but its connection to the engineered reality is tenuous. The dissatisfaction engineers feel is a

signal that we are optimizing for the audit, not the outcome.

A Category Error: Systems Engineering is Not Compliance

Systems Engineering as a Gardener's Discipline

Systems engineering is a discipline of cultivation. Its purpose is to cultivate the conditions for a successful outcome in a complex environment [1]. Its core activities - framing problems, evaluating trade-offs, and managing risk - are acts of judgment under uncertainty. They are about understanding the entire ecosystem, including the Biological, Technological, and Social domains. The Gardener's goal is a healthy, resilient system. Compliance with a predefined plan is secondary to adaptation in the face of reality.

MBSE as a Mechanic's Compliance Engine

MBSE, as practiced, has become the Mechanic's favorite tool. It is not even an efficient tool for engineering; it is an efficient tool for generating proof of compliance. Its primary output is not insight, but auditable artifacts [2,3]. The promise was a shared understanding; the reality is a shared set of documents to defend in a review.

As this substitution became entrenched, the performance of MBSE was judged by its ability to satisfy process auditors. When a compliant model failed to prevent a system-level failure, the discipline of systems engineering, not the misguided focus on compliance, was blamed.

A Practical Comparison: Gardener vs. Mechanic

Dimension

Systems Engineering (The Gardener)

MBSE (The Mechanic)

What it is A discipline for reasoning about and cultivating complex systems. A set of techniques for producing compliant system representations.

Primary Purpose Cultivate conditions for sound technical and organizational decisions. Generate auditable artifacts to satisfy process and contractual requirements.

Relationship to Decisions Directly frames, evaluates, and constrains decisions through synthesis. Documents decisions after they are made to ensure traceability for audits.

Generativity Produces insights, trade-offs, and risk understanding. Produces review-ready artifacts and traceability matrices.

Mindset Embraces uncertainty and emergence; seeks resilience. Enforces rules and structure; seeks compliance.

Load-Bearing Role Removing it degrades system outcomes. Removing it causes audit failures and contractual issues.

Failure Mode Poor decisions and unmanaged risk. A system that is compliant but fragile, leading to the Illusion of Stability.

The distinction is important. Systems engineering is about making the system work. MBSE, as misapplied, is about making the paperwork look right.

The Load-Bearing Test: Carrying the Procedural Load

The load-bearing test reveals the truth. A practice is load-bearing if its absence causes the system itself to fail.

In some organizations, MBSE is indeed load-bearing, but it is carrying a procedural load, not an engineering one. If you remove the MBSE artifacts, the project fails its next gate review. It violates its contractual obligations. It is non-compliant.

The engineering work, however, often continues unimpeded. This is the clearest sign of a structural problem. The tool's primary function has become to protect the organization from its own processes, not to protect the system from failure.

The Metasystem Failure: The Compliance Trap

The current state of MBSE is a perfect Compliance Trap, an emergent failure born from the interaction of three domains:

1. The Technological Domain (Tooling for Rules): SysML was designed to enforce a descriptive structure. It excels at representing rules, hierarchies, and allocations, the very things an auditor looks for. It was built to formalize structure, not to facilitate exploratory reasoning under ambiguity [4], making it a poor tool for discovery but an excellent one for codifying assumptions.

2. The Social Domain (Incentives for Compliance): Organizations reward what they can measure. It is easier to measure the completeness of a model than the quality of a decision. The incentive structure naturally shifted to reward the production of compliant artifacts. Engineers who are skilled at navigating the MBSE toolchain to pass reviews are promoted over those who challenge assumptions outside the model.

3. The Broken Feedback Interface: The most important feedback loop is no longer Design → Analyze → Test → Refine. It has been replaced by Model → Review → Pass/Fail Audit → Revise Model. Engineering insight becomes an external input to this cycle, rather than its output. The model stops learning from the system and starts learning from the auditors.

SysML v2 and AI: Automating the Checklist

SysML v2 and agentic AI offer powerful new capabilities [5]. But if the underlying goal remains compliance, they risk becoming more efficient engines for the same empty work.

An AI agent can automate the generation of traceability matrices and ensure a model is internally consistent with breathtaking speed. It can create a perfectly compliant artifact in seconds. This doesn't make the artifact more valuable; it just makes the generation of valueless artifacts cheaper. It automates the checklist.

Without a fundamental shift in the purpose of the activity, from compliance to engineering insight, these advanced tools will only accelerate our journey into the compliance trap. They will give the Mechanic a faster wrench to tighten bolts on a machine that was never designed correctly in the first place.

Tending the Garden: A Practical Path Forward

The solution is not to discard the tools, but to change their purpose. We must practice disciplined subtraction and remove compliance as the primary goal.

Redefine the Goal from Compliance to Insight:

The purpose of a model is not to be “correct” in a review. Its purpose is to help us make better decisions. It should be a place to articulate and challenge assumptions.

• Management Action: During reviews, ask “What decision did this model change?” or “What risk did this model uncover?” instead of “Is the model complete?” Shift the currency from approval to insight.

Use the Model as a Map, Not the Territory:

The model should serve as a map connecting the real sources of engineering truth: the analyses, simulations, test results, and trade studies. Its job is to show the relationships between them, not to become them.

• Management Action: Mandate that models reference authoritative analyses, not replace them. The value is in the connection, not the duplication.

Measure What Matters: Fragility, Not Completeness:

Evaluate models based on their ability to reveal fragility. A good model is one that shows where a single failure could cascade, where coupling is too tight, or where assumptions are brittle.

• Management Action: Stop measuring success by model element count or diagram completeness. Start measuring it by the number of critical questions the model helps answer

The Gardener and the Groundskeeper:

Clarify roles. The systems engineer is the Gardener, responsible for the health of the system. A dedicated modeler can be a valuable groundskeeper, ensuring the representational tools are used effectively. But the groundskeeper does not decide what to plant.

• Management Action: Make it clear that engineering authority resides with the decision-makers, not the tool experts. The model serves the engineer, not the other way around.

Decision Patterns as a Proactive Discipline

If systems engineering is to remain a Gardener’s discipline, it must anchor itself in decisions, not artifacts.

John Fitch defines a decision as a fundamental question that demands an answer [6]. The decision is not the chosen alternative; it is the governing question. Across practice, consequential engineering decisions follow recurring structures: decision patterns [6]. Architecture selection, allocation, risk acceptance: these patterns shape the system long before diagrams stabilize.

Fitch’s Decision Breakdown Structure (DBS) makes this structure explicit [6,7]. Instead of decomposing parts, it decomposes questions. Work is organized around uncertainty and commitment, not components. Engineering returns to its proper domain: judgment under ambiguity.

This reframes a common inversion in MBSE practice. Many technical requirements are consequences of architectural decisions. Once an alternative is chosen, constraints follow. When decision logic is implicit, requirements drift into compliance artifacts. When it is explicit, requirements regain their meaning.

A review grounded in decision patterns therefore asks: What decisions remain open? What alternatives were explored? What assumptions constrain us? What risks were surfaced? Traceability runs through the decision itself [7]. Remove that node, and the structure collapses into paperwork.

Decision patterns do not replace MBSE. They subordinate it. The model serves the decision. The decision serves the system. The Gardener remains accountable.

Compliance then becomes a byproduct of disciplined reasoning, not its purpose.

Conclusion:

Reclaiming the Garden

Systems engineering has not collapsed. What has collapsed is the Mechanic's fantasy that complexity can be managed with a checklist. The misuse of MBSE as a compliance engine is the most visible symptom of this deeper failure.

The future of systems engineering depends on our courage to abandon the safety of the compliance checklist and return to the uncertain, messy, and essential work of cultivation. It requires us to trade the illusion of control for the practice of judgment.

By re-scoping our tools to serve this higher purpose, we can rescue them from the compliance trap. We can begin to build models that help us see the whole system, anticipate the frost, and tend the garden with the wisdom it requires. The choice is between being a bureaucrat or being an engineer. The Gardener knows the difference.

For a deeper exploration of these ideas, see The Gardener and the Machine: Designing Systems that Thrive on Disruption.

References

[1] Walden DD, International Council on Systems Engineering, INCOSE Systems Engineering Handbook. Fifth.; 2023.

[2] Friedenthal Sanford, Moore A, Steiner R. A Practical Guide to SysML: The Systems Modeling Language. Third.; 2014.

[3] Henderson K, McDermott T, Salado A. MBSE adoption experiences in organizations: Lessons learned. Syst Engin. 2024;27(1):214-239. doi:10.1002/sys.21717

[4] OMG Systems Modeling Language (SysML) Version 1.6. Object Management Group (OMG). 2019. Accessed February 16, 2026. https://www.omg.org/spec/SysML/1.6/PDF

[5] OMG. Systems Modeling Language (SysML) v2 Specification. 2025. Accessed February 15, 2026. https://www.omg.org/spec/UML/2.5.1/PDF

[6] Fitch J. Introduction to Decision Patterns. PPI SyEN. 2021;(107).

[7] Fitch J. Decision Patterns – So What? PPI SyEN. 2022;(111).

About the Author

Dr. Art Villanueva is a systems engineer, artificial intelligence practitioner, and the author of The Gardener and the Machine: Designing Systems that Thrive from Disruption. Focused on complex adaptive systems, he is the founder of Phronos, where he applies advanced analytics and emergence theory to real-world engineering and organizational challenges. He currently serves as a Senior Staff Engineer at General Atomics Aeronautical Systems, developing next-generation aerospace technologies. His career spans defense, clean technology, and enterprise strategy, including leadership roles at Northrop Grumman and Dell Technologies. An experienced entrepreneur and technical executive, he was a founder and CTO of several clean energy technology companies.

He holds multiple U.S. patents, has published peer-reviewed research, and holds an INCOSE certification as an ESEP. He earned degrees in systems engineering and applied mathematics from UCLA, UC San Diego, and Colorado State University.

Rethinking Requirements Derivation –With AI Support

by John Fitch

Project Performance International

Authored for PPI SyEN

Introduction

In this article we continue on the theme of evaluating the implications of using Artificial Intelligence (AI) in the form of Large Language Models (LLMs) to assist with various systems engineering activities. Specifically, we extend a topic addressed in the Rethinking Requirements Derivation – Part 2 article in PPI SyEN Edition #130 (November 2023) re-using the Energy Absorbing Deceleration Barrier (EADB), aka Fitch Inertial Crash Barrier, as the example system [1].

The focus of the 2023 article was demonstrating the validity of a decision-centric thought process for requirements derivation and the associated Requirement-Decision-Requirement (RDR) traceability model (See Figure 1).

Figure 1: Requirement-Decision-Requirement Traceability

This article focuses on evaluating LLM support for a very specific task – the technique used to derive requirements based on the alternative chosen in a decision.

The author believes that all requirements are derived requirements, the inherent consequences of an alternative chosen in an “upstream” decision. If true, then the ability to define that alternative and to identify all such consequences at the point of decision is critically important to the capture and communication of resulting requirements. Potential failure modes are delayed requirement identification or lost requirements, both of which have the potential to trigger significant design rework.

The author has used (for several decades) a heuristic (mental shortcut) to assist in the generation of derived requirements, asking at the point of decision (i.e., the commitment to a specific alternative):

“How does the chosen alternative’s Structure, Behavior, Footprint, Interfaces and Lifecycle impose new constraints on the rest of the system?”

The author has used humorous memory aids (mnemonic devices) to assist practitioners in recalling the SBFIL elements of this question, namely:

• Smart Boys Follow Inspiring Leaders

• Stupid Bugs Fly Into Lights

This article will review the AI-assisted results achieved by:

• Supplying an LLM with the SBFIL question and supporting definitions and examples.

• Supplying an LLM with multiple decisions with the definition (name/description) of a chosen alternative for each.

• Varying the depth of information provided to define the chosen alternatives, i.e., adding graphics for the physical or functional architecture of the chosen solution.

• Assessing the completeness, consistency, uniqueness and clarity of the LLMgenerated derived requirements.

Recommendations will be provided on how to improve requirements outputs based on enhancing:

• The SBFIL heuristic, e.g., tailoring it for different types of decisions such as product scoping, technology or physical architecture

• The methods used to define alternatives and communicate that definition to the LLM

• The prompting strategy.

Methodology Used

In its Artificial Intelligence for Systems Engineering (AI4SE) course, PPI teaches a simple 5element prompt engineering pattern (ROTCE) [2]:

• Role

• Organizational context

• Task

• Constraints

• Evaluation.

The author used this pattern to create an initial prompt for use with each decision/alternative pair supplied to the LLM.

Ten decisions from the EADB Decision Breakdown Structure (DBS) were selected for analysis, with their context shown in Figure 2.

Figure 2 – Product Scoping Decisions and Solution Design Decisions

Decision Name

Table 1 – Fitch Inertial Barrier – Decision Summary Table

Branch

Decision Class Alternative Chosen

D.1 Product Concept Product Scoping Single Answer Array of energy absorbing individually frangible barrier units each preferably comprising a dispersible mass, e.g., sand

D.1.1 Use Cases to Support Product Scoping Multiple Answer The solution should work for a wide range of passenger automobiles

D.1.3.c BarrierAmbient Environment Interface Product Scoping Single Answer Interaction between the barrier and sunlight, wind and adverse weather elements (precipitation)

D.1.4 Product Lifecycle Product Scoping MultiPart Answer Set of modular components, assembled and configured in field. Near-zero maintenance.

D.1.7 Technology: Decelerate errant vehicle

D.1.7.1 Technology: Control deceleration rate

D.1.7.5 Technology: Impart downward forces on vehicle

System Design Single Answer Progressive fracturing of barrier units to transfer momentum and create friction

System Design Single Answer

Barrier units with differing masses spaced to "smooth" the deceleration forces

System Design Single Answer

D.1.8 Barrier System Physical Architecture System Design MultiPart Answer

D.1.8.5 Interior Platform Supplier / Model #

D.1.8.8 Barrier Unit Physical Design / Form Factor

Subsystem Design MultiPart Answer

Dispersive materials elevated within barrier units above vehicle center of mass imparts downward force on vehicle as it "plows through" successive barriers

Barrier is comprised of an array on N barrier units (containers filled with dispersive material). Units may vary in size and level of fill. Each comprised of a bottom, lid, cylindrical side wall, interior platform and fasteners.

Elevated variable-height platform comprised of interior pedestals that support a circular divider on which dispersive materials are suspended.

Subsystem Design Single Answer Cylindrical containers in a discrete range of sizes

These 10 decisions were selected from a larger set of 25 decisions that had been previously reverse engineered from the EADB patent application. They included sufficient diversity in both decision class (Single Answer, Multiple Answer, and Multi-part Answer) and “branch” within the decision pattern (Product Scoping, System Design, Subsystem Design) to provide a meaningful sample for the LLM while including the decisions that (intuitively to the author) had the greatest impact on shaping the overall solution concept.

Prompt Design

The full initial prompt (2.4-page, 739 word) in the ROTCE pattern is provided in the section that follows. Highlights of this approach include:

• Design the prompt to exercise the requirements derivation heuristic, the prompting strategy and the LLM, looking for the emergent properties of the whole derivation method/LLM “system” while evaluating the capabilities of the parts.

• Initial upload of example system information for context.

• Initial upload of the requirements derivation heuristic with definitions.

• Role: Act as a humble system designer and requirements author, eager to learn and excel at requirements derivation from decisions.

• Organizational context: Simulate the scenario of deriving requirements from the alternative chosen on a per-decision basis.

• Task: Decompose the work to be done by the LLM into subtasks by SBFIL element, generally performed on one decision/alternative at a time, with multiple pauses after task completion to enable user feedback and iteration to correct LLM errors or “drift”.

• Constraints: Specific instructions concerning to how to complete each task, defining the format for outputs, and limiting the LLM’s ability to hallucinate new “facts” or violate the derivation methodology.

• Evaluation: A definition of success that states the requirements quality attributes to be sought.

Although a state model of the EADB system exists (as used in the PPI System Edition #150 –February 2026 article, AI-enabled Requirement Structure Patterns), this model was not supplied as an input to this exercise in order to minimize the dimensions of data that the LLM was required to connect and align. For similar reasons, less emphasis was placed on strict adherence to the PPI Parsing Template in the initial prompt and in the real-time interactions.

Decision-Centric Requirements Derivation Prompt

The primary input to the chat was the Requirements Derivation – LLM Inputs.pdf file that contains:

• Patent-US3606258-energy-absorbing-barrier-John Fitch-1971 (13 pages)

• Rethinking Requirements Derivation – Part 2 SyEN November 2023 (15 pages)

• Barrier Context Physical Architecture Diagrams (1 page)

• Requirements Derivation Heuristic – Overview and Definition (2 page)

• PPI Requirements Parsing Template, Definitions and Examples (3 pages).

The Fitch Inertial Barrier – Decision Summary Table PDF file supplied the ten decisions to work through one-at-a-time.

Role:

As a humble system designer and requirements author, eager to learn and excel at requirements derivation from decisions, use the provided requirements derivation methodology and PPI requirement structure pattern (PPI Parsing Template) to successively derive requirements from the alternatives chosen in a selected set of decisions.

Organizational Context:

Your company wants to complete the design of an Energy Absorbing Deceleration Barrier (EADB) that provides the same capabilities as the Fitch Inertial Barrier system that is defined in U.S. Patent #3,606,258. An initial system design has been completed and is documented as a Decision Breakdown Structure, but derived system and subsystem requirements from those decisions may have been overlooked, potentially leading to extensive redesign of the

system and delays in Time to Market.

Task:

For each decision in the Fitch Inertial Barrier – Decision Summary Table, work one decision at a time and derive requirements from the chosen alternative using the SBFIL pattern to capture draft requirements from that decision.

Create an initial list, ordered by SBFIL element, of derived requirements names and their allocation to actors (physical architecture elements) within the EADB physical architecture context. Pause for user feedback at this step to ensure the completeness of the list and validity of the allocations.

After feedback, update the derived requirements list with the full “shall” statement text of each derived requirement, written in the format specified in the PPI Parsing Template. Wait for feedback and refinement after generating the improved requirements for each decision.

Before proceeding to the next decision, update a manifest of all derived requirements that includes the final user-approved verbatim version of each requirement and its derivation rationale.

Upon completion of the requirements derivation analysis for all ten decision/alternative pairs, identify which derived requirements may have been “shaped” by multiple decisions and propose a rewrite of each requirement with multiple decision “parents”.

Produce a requirements derivation traceability table for all requirements (organized by actor/physical architecture element) showing the derivation trace and rationale from decisions/alternatives for each requirement.

Upon completion of the requirements derivation analysis for all ten decision/alternative pairs, compare the results across these decisions against each SBFIL element in the derivation heuristic.

Acting as a hostile reviewer, find the flaws in your requirements derivation logic. Based on these flaws, propose refinements to:

• the alternative description (both contents and format)

• the SBFIL derivation heuristic, and

• the prompting strategy to resolve these flaws.

Propose an alternate requirements derivation heuristic for different types of decisions based on your recommendations on how to overcome the flaws that you identified.

Constraints:

To provide a grounded context, restate the decision and alternative chosen and the task to be

performed (with constraints) on that decision prior to processing any user inputs.

Use the Requirements Derivation Heuristic – Overview and Definition.pdf document uploaded at the start of this chat as the sole and immutable source for the methodology for deriving requirements from decisions.

Do not derive requirements directly from other requirements; always consider the Structure, Behavior, Footprint, Interfaces and Lifecycle inherent in the definition of the chosen alternative as the sole source of each derived requirement.

Use the PPI Requirements Parsing Template.pdf document uploaded at the start of this chat as the sole and immutable source for structuring each requirement. Ignore parsing element #10 – Other.

Use the EADB patent document and the EADB functional model (N-Squared Diagrams, Figure 4 and Figure 6) in the PPI SyEN article, Rethinking Requirements Derivation – Part 2, to provide context for and inform the derivation and intent of each requirement that is entered for analysis.

Use the Barrier Context Physical Architecture Diagrams document as the authoritative source of:

• The EADB physical architecture that results from the product scoping and design decisions, and

• How the EADB interfaces with external entities.

For each decision analyzed output a table that includes

• Decision Name

• Chosen Alternative description as provided

• Each derived requirement by SBFIL element with derivation rationale.

For each derived requirement generated in this analysis output a separate Derivation Trace table for each EADB system architecture element that includes:

• Derived Requirement Name and “shall” statement text (verbatim).

• Parent decision/chosen alternative description. There may be multiple parents.

• SBFIL element with derivation rationale.

Evaluation:

For each decision, focus on:

• Creating a Mutually Exclusive and Collectively Exhaustive (MECE) set of derived requirements

• Coverage of each element of the SBFIL heuristic, if applicable, with a rationale for any element deemed Not Applicable

• Quality of the derived requirements in terms of clarity and adherence to the PPI Parsing Template.

Requirements Derivation Heuristic

The rules that comprise the requirements derivation heuristic, as uploaded to ChatGPT in order to govern the LLM’s analysis process, are included below: Upon completion of decision analysis and the commitment to a chosen alternative, derive requirements from the definition of the chosen alternative by asking: How does the chosen alternative’s

• Structure

• Behavior

• Footprint

• Interfaces and

• Lifecycle.

impose new constraints on the rest of the system?

Where:

• Structure = the physical architecture of the solution alternative in terms of hardware or software subsystems or components, human actors, organizations, facilities, elements in nature, etc. and the relationships between these elements.

• Behavior = the logical (functional and/or state model) of the solution alternative, including control flow (dependencies between functions), item flow (inputs/outputs of functions such as energy, matter or information) and the evolution of this behavior over time (system dynamics).

• Footprint = space claim, consumption of externally-supplied resources such as power, communications bandwidth, computing, cooling, human labor, etc.

• Interfaces = external interactions with the outside world (relative to the boundary of the solution alternative) and required characteristics of those interfaces in terms of capacity, throughput, degradation (attenuation/noise), format, etc.

• Lifecycle = The lifecycle phases of the solution alternative such as development, testing, manufacturing, deployment, operations, support and end-of-life

All derived requirements should be written as allocated to the appropriate system element as actor.

As a general rule:

• Product Scoping decisions generate derived requirements where the System of Interest is the Actor.

• System Design decisions generate derived requirements on subsystems and the interfaces between subsystems.

• Subsystem Design decisions generate derived requirements on components within

those subsystems and component-to-component interfaces.

However, it’s possible that any decision could create a derived requirement on other previously unidentified actors within the system context, e.g., on the product design, manufacturing, verification, deployment or support systems or unanticipated system users.

LLM Outputs and Analysis

The interactive chat generated a 191-page, 34,400 word output, ultimately with 125 derived requirements allocated to 10 elements (EADB system, Barrier Unit, plus its components), from a 2.5 hour interactive ChatGPT session, plus 3.5 hours of post-analysis clarification and summarization of findings.

About midway through the analysis process, the author was required to upgrade to a paid ChatGPT Plus subscription in order to complete the requirements derivation process. There was no warning before this limit was reached, nor much clarity on what specific limitations of the unpaid subscription had been exceeded.

Initial requirements derivation pass

The initial pass through the ten decisions was amazingly prolific, yielding 221 requirement statements with all 5 elements of the SBFIL derivation heuristic well-represented. Decision D.1.1 - Use Cases to Support yielded the fewest derived requirements (on this pass) with 10. Decision D1.8 - Barrier System Physical Architecture yielded the greatest with 31.

The table below provides a small sample of the first-pass requirements derived from D.1.7 Technology: Decelerate Errant Vehicle using the SBFIL heuristic:

Table 2 – First Pass Requirements Derivation Examples

Requirement

Progressive Engagement Array Structure

Vehicle Momentum Transfer Behavior

Module Fracture Activation Behavior

Engagement Zone Spatial Extent

Module–Mass Interaction Interface

The EADB System shall be arranged to enable progressive engagement of Barrier Units during vehicle impact.

The EADB System shall transfer momentum from an impacting vehicle to dispersible mass.

Each Barrier Unit shall fracture upon vehicle impact to initiate dispersible mass release.

The EADB System shall define a spatial zone in which vehicle interaction and energy absorption occur.

Each Barrier Unit shall transfer momentum from its structure to its dispersible mass.

Structure Sequential mechanism

Behavior Core physics

Behavior Activation

Footprint Interaction region

Interface External interaction

Module Replacement After Fracture

Each Barrier Unit shall be replaceable after fracture due to vehicle impact.

Lifecycle Replacement

This decision generated 8 requirements on the EADB system and 12 requirements on the individual barrier units.

Across the entire set of 10 decisions, where did the LLM perform very well?

• Derived requirements were allocated to the appropriate system element (EADB system, barrier unit, or various barrier unit components), i.e., the Actor was correct.

• Derived requirements were well-formed “shall” statements, consistent with the PPI Parsing Template, though initially qualitative in nature until performance characteristics were added by the introduction of various “profiles” that quantified relevant parameters.

• The derivation rationale proposed for each requirement was a plausible statement that could be inferred from the alternative description and other information supplied in the patent that provided context and common-sense explanation of the physics behind the EADB.

• Derived requirements were generally mutually exclusive and collectively exhaustive (MECE) on a per-decision basis. Overlap between requirements derived across multiple decisions was observed, as expected.

• The LLM’s ability to interactively create parameterized profiles that quantified performance was impressive, with the LLM generating a Standard Passenger Vehicle Profile (SPVP-2026) that represented in 13 parameters the dimensional, mass, and geometric envelope that bounds approximately 90% of passenger vehicles operating on U.S. highways (circa 2023–2026 fleet). Other such LLMgenerated profiles include the Standard Highway Environmental Conditions Profile (SHECP-US-2026), Standard Deceleration Safety Limit (SDSL-2026), and Standard Jerk Limit (SJL-2026). Once defined in the chat, these profiles contributed greatly to reducing the verbiage needed to write complete and precise requirements.

• The “baselined” Manifest that contained the cumulative set of derived requirements after the completion of each decision (during the first pass) was maintained accurately and prevented the loss of requirements through LLM drift.

• The requested Pause for Feedback after each decision in the original prompt was accompanied by an insightful set of LLM-supplied questions that triggered useful user-supplied clarifications. This immediate, focused feedback reduced the risk of “context drift” and downstream LLM hallucinations. These clarifying questions may have been triggered by the LLM looking ahead in the prompt, anticipating issues that would arise in the Find the Flaws analysis (that was specified as a later task in the prompt) and proactively seeking answers to such questions.

Two hallucinations occurred in the first pass through the ten decisions:

• The LLM invented the existence of a Barrier Unit Container component that was not

part of the Physical Architecture diagrams that were provided as inputs. The LLM correctly inferred a dispersible mass containment function, but according to the supplied solution architecture, this capability is an emergent property of the physical configuration of the barrier unit side wall, base, lid, and internal platform rather than by being accomplished by a single named Container component.

• The LLM substituted its own definition of the chosen alternative in two decisions before this was caught. The LLM was prompted again to use only the verbatim asprovided alternative description as the basis for requirements derivation; which it did so thereafter.

By the third of the ten decisions, ChatGPT began to offer unprompted self-checks of its results that mixed excellent clarifying questions with a few of self-congratulatory assertions. This unasked-for behavior could be interpreted as positive (proactively preparing for future tasks) or negative (giving the user a false sense of confidence that relaxes the rigor of their review process).

In every case, the LLM outputs were positive in their characterization of user interactions, often praising the user. There were 11 instances of such feedback in response to user supplied prompts, all beginning with “Excellent”. For example, the real-time user prompt:

Let's define "near-zero" as not exceeding 20 hours of maintenance for a deployed EADB system over a 10 year operational period, excluding post-crash barrier restoration effort.

Resulted in LLM praise:

Excellent—this is a strong move from qualitative to testable lifecycle performance, and the exclusion of post-crash restoration keeps the requirement cleanly scoped.

The author’s sense is that these LLM responses increase the risk of human reviewers “dropping their guard” during long LLM sessions.

Consolidation and evolution of requirements derived from multiple decision “parents” As expected, the set of 221 individual requirements that were created one decision at a time using the SBFIL heuristic may have been collectively exhaustive (or nearly so based on the decision scope covered), but certainly were not mutually exclusive. This triggered a need to refactor or consolidate the requirements set to remove redundancy.

ChatGPT seemed efficient when confronted with the task of refactoring. The proposed final requirement set reduced the total number of requirements from 221 to 125. These were distributed across three levels of system decomposition as follows:

• EADB System: 28

• Barrier Unit: 24

• Component: 83.

Of the 125 requirements, 72 (58%) were derived from a single decision parent; 53 of 121 (42%) were “shaped” by multiple decisions.

Not surprisingly, the requirements derived from multiple parent decisions were primarily system-level, often addressing behavior and performance or the system footprint.

However, it took at least 5 iterations of the model after the first attempt at refactoring and consolidation to generate the requirements baseline. During this iterative and somewhat painful process numerous faulty assumptions and logical flaws were uncovered.

ChatGPT got carried away during consolidation and both failed to follow and overshot the PPI Parsing Template by adding a “Means” element. Its initial output for the top-level functional and performance requirement, which it named Deceleration Performance Envelope is shown in Table 3:

Table 3 – Deceleration Performance Envelope – Requirement Structure As Parsed by ChatGPT

Actor: EADB System

Action: shall control

Object: vehicle deceleration

Conditions: for vehicles within SPVP-2026 during impact within the engagement zone

Constraints: such that

• target deceleration ≤ 10 g

• maximum deceleration ≤ 15 g

• rate of change of deceleration is limited (SJL-2026)

Means (implicit, not design-binding): achieved through Barrier Unit mass, spacing, and configuration.

Inclusion of the means transformed a system requirement into a design requirement by specifying how a requirement was to be achieved, not just what action was required by the system and how well that action must be performed.

A correct parsing of this requirement based on the PPI template is shown in Table 4.

Table 4 – Deceleration Performance Envelope – Correct Requirement Structure

Actor: The EADB System

Conditions for

Action: for vehicles within SPVP-2026 during impact within the engagement zone

Action: shall control

Object of Action: vehicle deceleration

Constraints of

Action: such that target deceleration ≤ 10 g, maximum deceleration ≤ 15 g, and rate of change of deceleration is limited (SJL-2026)

In general, the effort required to force the LLM to strictly follow the Parsing Template seemed fruitless when combined with the exercise of the deriving requirements from decisions (a novel paradigm) while at the same time refactoring these requirements to eliminate overlaps. This appears to be another instance of an LLM having difficulty with a complex task that calls for convergent thinking and simultaneously demanding the deterministic reproducibility of precise outputs in precise formats.

There was significant evidence that the LLM lost track of its “baseline” requirements set during the effort to refactor the derived requirements to remove redundancies. During the iterative process to publish a complete requirements baseline derived from the 10 decisions analyzed, the LLM dropped the top-level functional and performance requirement - which defines the EADB’s primary mission. When challenged, ChatGPT “found” this and 3 other similar requirements that were lost from the manifest.

In its final form, the LLM renamed the “found” requirement Integrated Vehicle Deceleration Mission. It continued its unwanted “creative” divergence from the Parsing Template:

Table 5 – Integrated Vehicle Deceleration Mission – With Parsing Structure Hallucinations

Actor The EADB System

Action shall decelerate

Object of Action vehicles within SPVP-2026

Initial Condition from the maximum defined impact speed

Final Condition to zero velocity

Operating

Condition within the engagement zone

Constraint of Action while maintaining compliance with SDSL-2026 and SJL-2026

Deviations and omissions from the PPI Parsing Template are highlighted in red text.

Systems engineering practitioners who work in MBSE software tools will and should find alarming the LLM’s ability to drop or modify (without notification) requirements when focusing on other analytical tasks. “We” are used to deterministic outcomes; a requirement, once baselined should not go missing or “pop up” in a changed form without human action and approval. Rules applied to requirements, e.g., their fundamental structural pattern, should not evolve during an interactive session with a “tool”.

Example: Evolution of a system requirement derived from multiple decision “parents” Despite the challenges noted above, the LLM did validate a key tenet of decision-torequirements traceability – that requirements may be derived from and shaped by multiple decisions. To demonstrate this principle, the author switched back to the earlier and better version of the Deceleration Performance requirement:

The EADB System, for vehicles within SPVP-2026 during impact within the engagement zone, shall control vehicle deceleration such that target deceleration ≤ 10 g, maximum deceleration ≤ 15 g, and rate of change of deceleration is limited (SJL-2026).

The LLM was requested to:

Provide 2 examples of a requirement derived from at least 3 parent decisions and how the different parts of that requirement (per the PPI Parsing Template) evolved as decisions were made.

The contribution of parent decisions to the Deceleration Performance requirement, according to ChatGPT, are shown in Table 6.

Table 6 – Deceleration Performance – Evolution of Requirement from Parent Decisions

Decision

Derived Requirement Contribution

Rationale

D.1 Product Concept EADB System shall absorb vehicle kinetic energy Establishes energy-absorbing barrier mission; Introduces need for deceleration control

D.1.1 Use Cases to Support for vehicles within SPVP-2026 Defines vehicle population as SPVP-2026 (mass, speed envelope)

D.1.7 Technology: Decelerate errant vehicle absorb energy → decelerate vehicle via momentum transfer Converts energy absorption into deceleration through momentum/friction

D.1.7.1 Technology: Control deceleration rate “absorb energy” becomes “control deceleration profile”

Adds controlled/smoothed deceleration forces (deceleration shaping)

In summary, this requirement evolved from: “absorb energy” → “control deceleration” → “control deceleration within bounded g and jerk limits for a defined vehicle set”

A second example focused on the Continuous Barrier Engagement requirement:

The EADB System shall maintain continuous engagement between vehicle and Barrier Units for vehicles within SPVP-2026 during impact by preventing vertical bypass, ramping, and loss of ground contact.

The multiple-decision derivation trace for this requirement can be summarized as:

Table 7 – Continuous Barrier Engagement – Evolution of Requirement from Parent

Decision

Derived Requirement

Contribution

D.1 Product Concept EADB System shall absorb vehicle kinetic energy

D.1.1 Use Cases to Support for vehicles within SPVP-2026

Rationale

Decisions

Requires continued interaction between vehicle and barrier

Introduces vehicle geometry variability; relevant to potential for going “airborne”

D.1.7 Technology: Decelerate errant vehicle Energy absorption mechanism Requires sustained contact; progressive sequential impacts with barrier units

D.1.7.5 Technology:

Impart downward forces on vehicle

Impart downward forces on vehicle Introduces ramping prevention mechanism

In summary, this requirement evolved from:

“vehicle hits barrier” → “vehicle must stay in contact” → “vehicle must not escape vertically” → “system must actively prevent ramping using Center of Mass + downward force”

In both of these examples, the LLM used the mechanism implied by “Technology for Function X” decisions (namely 1.7, 1.71, and 1.7.5) as the method to gain understanding of the science being exploited to create value. This mirrors a common reality, the top-level Product Concept decision often “looks ahead” to critical technology choices; combinations of technologies form concept alternatives, which are then elaborated through additional analysis into physical and functional architectures that are the essence of a product design.

Takeaways – Requirements Derivation Methods

This exercise demonstrated at significant scale the essence of the decision-to-requirements derivation approach:

• Requirements are not “derived” from a single parent requirement; they emerge by accumulating the consequences of one or more decisions.

• The most important requirements are not created in one step they are assembled across decisions.

• Requirements are the formalized physics, constraints, and implications of decisions not restatements of intent.

• Derived requirements evolve by progressively compiling the inherent consequences of decisions (chosen alternative definitions) into the elements of a requirements structure pattern such as PPI’s Parsing Template.

Based on the analysis performed in this lengthy chat, ChatGPT summarized the differences between the traditional Requirement-to-Requirement (R-to-R) traceability (derivation model)

and the Decision-to-Requirement (D-to-R) paradigm as shown in Table 8, below.

Table 8 – Comparison of Requirements Derivation Methods

Traditional Weaknesses of R-to-R Trace Model

Requirements derived from vague parent requirements

Missing physics closure (e.g., energy, impulse)

Weak cross-discipline integration

Over/under specification

Poor traceability to design

Findings – SBFIL Requirements Derivation Heuristic

D-to-R Trace Model Improvement

Requirements tied to concrete design choices

Explicit enforcement via decision consequences

Multi-parent requirements capture coupling

Balanced via SBFIL completeness

Direct trace to decisions and architecture

The SBFIL heuristic for deriving requirements from decisions/alternatives proved to be:

• Prolific in terms of the number of requirements derived, relative to less structured techniques.

• Effective at requirements derivation from any decision analyzed (across multiple decision types).

• Effective at requirements derivation across all SBFIL types.

• Effective at requirements derivation across all levels of system physical architecture decomposition.

• Excellent at creating rationale and traceability that could be revisited if change impact analysis was needed.

• Able to provide the inputs needed to the PPI Parsing Template (Requirements structure pattern) to create complete, clear and logically defensible derived requirements.

• Compatible with the value-added capabilities of LLM predictive algorithms.

SBFIL Heuristic Improvements:

Based on the results of this experiment and as requested, ChatGPT suggested the following enhancements to the requirements derivation heuristic:

• Every derived-from-Behavior requirement (functional and performance) must have at least one corresponding derived-from-Structure requirement enabling it.

• Interface requirements must describe the quality of interaction across the interface (e.g., symmetric, continuous, rate-limited), not just existence.

• Lifecycle requirements must include performance retention and drift constraints.

Alternative Definition Improvements:

The following improvements to the definition of solution alternatives were recommended for each decision:

• Each alternative definition should include:

o Mechanism - What physical principle?

o Configuration - What geometry / arrangement?

o Control Variable - What is being tuned?

o Performance Intent - What outcome?

• Add graphical definitions (graphs, curves, diagrams) where appropriate.

Prompt Improvements

The following improvements are proposed for a prompt pattern for deriving requirements from the chosen alternatives in upstream decisions:

• Extract physical variables explicitly.

• List implied physical laws.

• Map variables → SBFIL elements.

• Reject any inferred mechanism not in alternative.

The prompt to “propose a rewrite of each requirement with multiple decision parents” should have been expanded significantly to address the complexity of the complex convergent thinking required to accomplish this analysis. Each requirement that was identified as shaped by multiple decisions:

• Made obsolete earlier versions of the original 221 requirements derived from individual decisions

• Partially or fully replaced those original requirements

• Should have triggered an assessment of the remaining overlaps or gaps in the problem definition, i.e., answered “are the requirements now the minimum set of MECE statements?”

• Should have triggered an update to an LLM-maintained requirements manifest/baseline

This level of convergent thinking, i.e., asking if “the model now right and best” is clearly a more challenging task for AI or human intelligence than brainstorming a divergent set of requirements from a solution description.

Conclusions

Although the author clearly admits bias as a 30+ year advocate of decision-to-requirements derivation traceability, the efficacy of the SBFIL heuristic in the “hands” of a newly trained LLM adds support to the general usefulness of this paradigm.

Only decisions can create (give birth to) new requirements; requirements or models can not. However the completeness and quality of models of alternatives (beyond text descriptions) plays a key role in the requirements derivation process.

LLM’s such as ChatGPT can offer significant value in supporting systems engineering tasks, when skillfully prompted by users with the discipline to carefully evaluate LLM outputs and

correct errors and contextual drift. Verbatim LLM outputs should never be trusted as engineering work products, but can accelerate refinement of engineering information (requirements in this context) that may be integrated into formal engineering work products. LLM’s can handle the divergent task of identifying a set of candidate derived requirement consequences from decisions, given a heuristic for doing so that has been proven without AIautomation.

LLM’s are less effective performing the convergent task of consolidating a set of requirements that have been derived one-decision-at-a-time such that a smaller set of requirements covers the full problem space. An LLM’s penchant for summarization will often lead to dropped requirements (without warning) despite the command to continuously maintain a full requirements manifest/baseline. Dropped requirements may need to be rediscovered by directing the LLM to conduct a “Find your Flaws” hostile review of its own process and logic.

Systems engineering data is inherently multi-dimensional, representing multiple classes of entities and the relationships between them. Despite the power of LLM’s “connect the dots” predictive algorithms, their performance appears to wane when too many dimensions of data are processed in a single long session. Further experimentation is needed to discover these limits (per LLM) and to determine the optimum level of LLM-assigned task complexity.

Given the non-determinism of LLM outputs, further research is need on how to best engage LLM’s in complex engineering workflows that include direct interactions with MBSE tools. The author’s hypothesis is that better outcomes will be achieved when an MBSE software tool is used as the authoritative repository of system models, with the LLM’s role reduced to shortduration analyses to evaluate, refine and extend these entities. Assigning a 10-task process against 100 nodes of any type seems unlikely to produce “engineering-grade” outputs.

Movement to higher-tier subscriptions was necessary because of the scale and complexity of the inputs to this analysis; however, there is insufficient data to determine whether that upgrade made a material difference in the quality of the LLM’s outputs.

References

[1] Fitch, J.C. Energy Absorbing Deceleration Barriers. U.S. Patent #3,606,258. Filed 2 January 1969. Awarded 29 September 1971.

[2] Artificial Intelligence for Systems Engineering (AI4SE), PPI course materials, 2026

[3] PPI Requirements Parsing Template, embedded in PPI’s System Engineering Five-Day (SE5D) and Requirements Engineering Five-Day (RE5D) course materials.

About the Author

John Fitch is a Principal Consultant and Course Presenter for Project Performance International. John brings over four decades of systems engineering, engineering management, consulting and training experience to the PPI team. In 2012, John was certified by INCOSE as an Expert Systems Engineering Professional (ESEP).

Within the field of systems engineering, John’s career has focused on decision management, requirements management, risk management, systems design & architecture, product/technology road-mapping, and innovation. In addition to defense/aerospace, John has guided initiatives in domains such as communications systems, software, energy, nanotechnology, medical devices, manufacturing systems, knowledge management and business process improvement.

SYSTEMS ENGINEERING RESOURCES

Useful artifacts to improve your SE effectiveness

INCOSE INSIGHT Practitioners Magazine – February Edition

The February 2026 Edition of INSIGHT, INCOSE’s Practitioners Magazine, has been published by Wiley. Electronic subscriptions to INSIGHT are available to INCOSE members as a member benefit Hard-copy subscriptions to INSIGHT are available for purchase by INCOSE members for one membership year and to the public.

The ten articles in the 61-page Volume 29, Issue 1 highlight the theme of Systems Engineering Contributions from Europe, the Middle East, and Africa.

Analyzing System Security Architecture in Concept Phase Using UAF Domains

Authors: Juan José López García and Daniel Patrick Pereira

This paper presents combining MBSE (Model-Based System Engineering) and STPA (SystemsTheoretic Process Analysis) to mitigate security risks at an early stage of system development and to increase agility when developing or modifying architectures. The MBSE approach states that the systems development process should have a system model or a set of models as the unique source of truth. From the system model or a set of models, systems engineers of different specialties should be able to extract the information needed to perform their job. However, some specialties usually create their artefact apart from the model to perform the analysis, breaking the premises of MBSE to have a unique source of truth leading to out-ofdate artefacts. This article proposes extending the Unified Architecture Framework (UAF) Profile (UAFP) to enable safety and security systems engineers to perform their analysis from the early stage of a system development process.

Functional-Outcomes Driven Tailoring in Modern Complex Engineered System Development

Author: Barend Botha

Modern engineered systems demand lifecycle strategies that are responsive, risk-aware, and aligned with evolving needs. Historically, systems engineering has been methodology-driven, with formal frameworks such as the V-Model or waterfall used to guide process rigor and governance. These methodologies provided structure and control, especially for large, safetycritical engineered programs. However, as systems have become more complex and adaptive, the limitations of rigid methodological adherence have become increasingly apparent. This article retraces the reasoning behind moving from methodology-driven to function-driven, to outcomes-focused, and finally to functionally enabled outcomes. It introduces the concept of functional-outcomes driven tailoring (FODT) as a unifying framework that drives lifecycle performance through functional alignment to mission

outcomes.

How Large Scale Agile Can Operate Systems Engineering in the Future

Authors: Laurent Alt and Mikaël Le Mouëlli

The significant shift happening today towards more connected, more automated, and more autonomous systems is bringing software inside all systems, and at the same time agile practices. Our experience of large-scale agile deployments in companies building or operating complex systems in automotive and aerospace shows that, whereas both approaches can easily coexist in isolated teams within the same company, major problems arise when coordinating them at the leadership level, where they are perceived as antagonist, and create misalignments, friction and quality issues. In this article, we propose to describe why it is important to make agile and systems engineering work together, how to do it, and how this impacts how we see value, systems, digital twins, and leadership. The following concepts of the FuSE agile roadmaps are addressed:

• Agility with long lead time components and dependencies

• Agility across organization boundaries

• Orchestrating agile operations.

Integrating Loss-Driven Systems Engineering Activities

Author: David Endler

Loss-driven systems engineering activities are key to realizing successful systems. At the same time, loss-driven systems engineering assessments are, in most cases, complex. In real life projects, integrating loss-driven systems engineering activities in the system development activities might be difficult. In some cases, there is a lack of understanding of the activities' importance and sometimes there are organizational barriers. To overcome those barriers, we propose an approach based on widely accepted standards. The difficulty is most existing systems engineering standards poorly describe loss-driven systems engineering activities and how they integrate with traditional engineering activities. This paper provides an approach to successfully accomplish this integration. It is extremely important to involve loss-driven systems engineers in every life cycle phase. At the same time, achieving a common integrated approach understanding is necessary.

Model-Based Systems Engineering as an Enabler of Agility. Authors: Sophie Plazanet and Juan Navas

Model-based systems engineering (MBSE) with agility can help systems engineering programs which deal with both increasing complexity and frequent changes in environment and usages, shorter time-to-market, uncertainty of the needs, and more sophisticated industrial schemes. Agile approaches originated in software engineering can be extended and tailored to a certain extent to complex systems engineering and particularly to MBSE. Main benefits of agility are provision of a minimum viable product as early as possible in the schedule, early capture of changes of needs, enabling to deliver a system answering to the real needs, and

securing of the value proposal. It includes also potential reduction in rework of the final system through regular customer feedback throughout development (left shift for the defect correction with early exposure), and efficiency of the use of resources. Concerning MBSE, the use of models as a single source of truth for completeness and consistency is useful to share and secure the design by improving communication within engineering teams and the building and support of the development strategy, and to help to automate some tasks such as model exchange and synchronization. In addition to the benefits of each approach, combining them may help to:

• Organize and synchronize the development and validation effort of one or multiple engineering teams.

• Faster impact analysis including trade-off studies/options and hence a faster reaction to evolutions in expectations and constraints, that is, the agility of systems.

• Show regularly “end to end” value to the customer and other stakeholders.

Modular Over-the-air Software Updates for Safety-critical Real-time Systems

Authors: Domenik Helms, Patrick Uven, and Kim Grüttner

Automotive software is undergoing a rapid change toward artificial intelligence and towards more and more connectedness with other systems. For both, an incremental design paradigm is desired, where the car's software is frequently updated after production but still can guarantee the highest automotive safety standards. We present a design flow and tool framework enabling a DevOps paradigm for automotive software development. DevOps means that software is developed in a continuous loop of development, deployment, usage in the field, collection of runtime data and feedback to the developers for the next design iteration. The software developers get support in defining, developing, and verifying new software functions based on the data gathered in the field by the previous software generation. The software developers can define contracts describing the time and resource assumptions on the integration environment and guarantees for other dependent software components in the system. These contracts allow a composition of software components and proof obligations to be discharged at design time through virtual integration testing and runtime through continuous monitoring of assumptions and guarantees on the software component's interfaces. An update package, consisting of the software component and its contracts, is then automatically created, transferred over the air, and deployed in the car. Monitors derived from the contracts allow for supervising the system's behavior, detecting failures at runtime, and annotating the situation to be included in a data collection, fueling the next design iteration.

Systems Skills … From Here to Diversity

Author: Alan Harding

Competency, the ability to do things, is at the heart of how systems engineers realise successful systems. Over the years INCOSE and partners have codified what this means, initially in the INCOSE UK Competency Framework (INCOSE UK 2010) later adopted globally by INCOSE and used as the basis of the INCOSE Systems Engineering Competency Framework

(INCOSE 2018) which, notably, included a new area of professional skills. This article considers competency from the perspective of Diversity, Equity, and Inclusion (referred to as DEI) using a variety of sources including the recently published INCOSE SE Vision 2035 (INCOSE 2022) and a variety of competency frameworks to offer a view of how the skills and competencies of systems engineers need to evolve in the future. Five new competencies are proposed, as are opportunities to improve the definitions of five more.

TNO-ESI – Systems Engineering Methodologies for Managing Complexity in the High-Tech Equipment Industry: Our Roadmap

Authors: Wouter Leibbrandt, Jacco Wesselius, and Frans Beenker

The high-tech equipment industry brings complex industrial products to the market with high speed, enhanced functionality, a better cost-performance ratio, and greater integration into customer workflows. Driven by digitalization, the complexity of these systems continues to grow steeply. To manage this complexity, continuous innovation in systems engineering methodologies is needed. TNO-ESI targets to 1) create impactful and industrially applicable systems engineering methodologies and 2) provide innovation support to the industry to get these applied in an industrial context. The ESI research program is defined through a roadmapping process that follows two tracks: a roadmap that maps industry needs and related research and development requirements and a roadmap that describes the developments in the expertise areas necessary for addressing these industry needs. In this paper, we describe the ESI mission, our way of working and activities, and explain the roadmapping process and the roadmaps.

Very Small Entities (VSEs): Outsourcing Risk to the Supply Chain Is Placing Systems Security Engineering on a Clay Foundation, but Playing Games May Help

Authors: Roar Georgsen and Geir Køien

This article addresses the inherent risk in a supply chain that comprises primarily Very Small Entities (VSE) with little to no security proficiency and limited resources and incentive to prioritize system security. In a globalized economy based on outsourcing and risk-sharing, most engineering activities occur in the smallest companies, even for large and complex projects. The Future of Systems Engineering initiative (FuSE) appropriately has agility at the core of its Systems Security Engineering (SSE) foundation concepts, and VSEs are by their very nature agile. However, the line between agility and chaos may be thin, and engineers at VSEs must often accept a level of restraint and rigidity beyond their comfort level to achieve functional agility. The primary challenge in VSEs is adding structure without the necessary resources to enforce compliance manually.

We propose that VSE focus their initial efforts on FuSE SSE Foundation Concepts that play into their nature and strengths as dynamic human social activity systems. Improvements in security proficiency and stakeholder alignment do not necessarily require much formal structure, and digital tools combined with social strategies can add structure to a resourceconstrained environment. Games can be excellent low-cost tools to provide structure while minimizing resistance, and Agile Model-Based Systems Engineering (AMBSE) using digital

models can support automated enforcement. Here we use the card game Elevation of Privilege (EoP) as an example. Within the context of a SysML Threat Model integrated into a larger System Model, players naturally treat security requirements as traceable functional requirements. Automated model validation, re-usable components and patterns enforce a Zero-Trust architecture, a sufficiently formal trust model to provide evidence-based assurance, yet achievable for small companies with limited resources.

What Is the Role of a Systems Engineer in an Engineering Organization?

Author: Richard Beasley

This article discusses the role of a “specialist” Systems Engineer inside an engineering focused on ensures the engineering parts integrate to achieve the objectives of the whole – and so is embedding a systems approach throughout the organization – trying to “make Systems Engineering the way engineering is done”. In this type of organization all engineers need systems engineering as a core skill (which is part of them becoming T-shaped“. The specialist Systems Engineer needs to be more π-shaped, with specialism in the systems approach used to inform and guide all the other disciplines which need to be integrated together. Since systems engineering is an integrating discipline the group of systems engineers must not become ”just another“ technical silo.

View INSIGHT Volume 29, Issue 1 in the Wiley online library.

INCOSE Systems Engineering Journal

INCOSE has published the March 2026 edition of the Systems Engineering Journal through the Wiley Online Library. Volume 29, Issue 2 includes open-access articles, plus full-access papers that require an institutional login, e.g., via INCOSE membership. There is no published overriding theme for these editions, though AIrelated topics are abundant. PPI SyEN has included abstracts to guide our readers to which of these diverse topics best fit their interests.

March 2026 Open Access Articles

Open Access articles are available to view and download in PDF format without any restrictions.

A Systems Engineering Methodology for System of Autonomous Systems: Architecture and Integration

Authors: Mohammadreza Torkjazi and Ali K. Raz

Abstract: Artificial intelligence and machine learning (AI/ML) rapidly transform systems by

providing autonomous capabilities. This new class of systems can become a constituent system in a system of systems (SoS) to evolve it into a system of autonomous systems (SoAS). SoAS is fraught with new systems engineering (SE) challenges for architecture development, integration, testing, and evaluation that originate from the level of autonomy (LoA). The LoA refers to the level of autonomous capabilities of a system depending on its AI/ML technology. This paper examines SoAS architecture and integration challenges such as interface compatibility, safety, and security. We propose a model-based systems engineering (MBSE) method for architecture development that falls under the system engineering for AI (SE4AI) umbrella, where SE principles are tailored to accommodate challenges posed by the integration of autonomy. The proposed method builds upon the object-oriented systems engineering method (OOSEM) and modifies it to facilitate autonomy integration by leveraging the MBSE SWOT (i.e., Strength, Weakness, Opportunity, Threat) analysis and SoAS taxonomy. It also tailors the unified architecture framework (UAF) to develop SoAS architectures with varying LoAs. This study leads to generating necessary evaluation data for a trade study and selecting an architecture with the most suitable LoA. We also present a conceptual example of a search-and-rescue SoS to demonstrate the implementation and effectiveness of the proposed method in investigating the evolution of LoA in constituent systems.

Addressing Complexity in System of Systems With GraphRAG: An AI-Driven Framework for Dynamic Data Integration

Authors: Yinchien Huang, Tien-Yueh Fung, and Daniel A. DeLaurentis

Abstract: System of Systems (SoS) environments are inherently complex, involving numerous operationally and managerially independent component systems with hidden interdependencies and frequent interactions based on unstructured data. In this paper, we propose using graphical Retrieval-Augmented Generation (GraphRAG), a tool that combines large language models with knowledge graph (KG) techniques to address these challenges. Using metrics from information entropy and graph theory, we demonstrate how KG construction and clustering nodes can reduce complexity in SoS. An example application in the Urban Air Mobility setting illustrates that GraphRAG can solve concrete data integration challenges while outperforming traditional Retrieval-Augmented Generation (RAG) methods. The upshot is improved execution of model-based systems engineering in an SoS context: mitigating risks from incomplete information, enhancing system integration, and improving decision-making.

Advancing Model-Based Systems Engineering in the Development of Naval Vessel Systems Architecture

Authors: Vasileios Sideris, Zacharias P. Oikonomou, Sam Gerené, and Austin A. Kana

Abstract: The increasing complexity of modern naval vessels due to technological advancements poses challenges for early-stage ship design (ESSD). Developing well-defined system architectures and adopting systems engineering approaches are essential to address these challenges. Model-based systems engineering (MBSE) has emerged as a solution to the issues inherent in traditional document-centric methods and is considered the future of systems engineering. This paper aims to address the barriers to MBSE adoption by exploring

its value in the early design stage of naval vessels. The paper focuses on system architecture development, covering operational, functional, logical, and physical perspectives, and evaluates two MBSE tools: Capella and CDP4-COMET. The analysis demonstrates that both tools effectively validate anticipated benefits, concluding that MBSE can enhance and accelerate ESSD, with Capella performing better in the early design stages and CDP4–COMET excelling in the later stages. This paper, thus, differentiates itself from traditional performance and detailed design modeling, such as those addressing motion, control, or thermal dynamics.

Identification of Missing Knowledge in MBSE System Models Using Graph-Based Machine Learning

Authors: Esma Karagoz, Olivia J. Pinon Fischer, and Dimitri Mavris

Abstract: The design and development of complex aerospace systems pose significant challenges due to their growing complexity. Iterative design processes, guided by formal specifications, strive to refine initially vague characteristics through multiple stages. Despite these efforts, the integration of diverse disciplinary knowledge into system models often remains incomplete. This study tackles the challenge of incomplete knowledge in MBSE system models by introducing a graph-based machine learning approach to uncover and address missing links. SysML models are transformed into knowledge graphs, where relational graph convolutional networks are applied to identify missing connections that may be overlooked by human analysts. By utilizing the graphical structure of system models, this approach automates link prediction and enhances model completeness. The results demonstrate that graph neural networks effectively recover missing links, achieving 72% accuracy, although dataset availability remains a key challenge for large-scale implementation. The findings emphasize the need for extensive open-source datasets to fully understand the impact of machine learning in systems engineering frameworks.

Mission Aware Cyber-Physical Security

Authors: Georgios Bakirtzis, Bryan Carter, Cody H. Fleming, and Carl R. Elks

Abstract: Perimeter cybersecurity, while essential, has proven insufficient against sophisticated, coordinated, and cyber-physical attacks. In contrast, mission-centric cybersecurity emphasizes finding evidence of attack impact on mission success, allowing for targeted resource allocation to mitigate vulnerabilities and protect critical assets. Mission Aware is a systems-theoretic cybersecurity analysis that identifies components that, if compromised, destabilize the overall mission. It generates evidence by finding potential attack vectors relevant to mission-linked elements and traces this evidence to mission requirements, prioritizing high-impact vulnerabilities relative to mission objectives. Mission Aware is an informational tool for system resilience by unifying cybersecurity analysis with core systems engineering goals.

Toward Explainable Engineering Decisions: Pursuing a Descriptive Decision Theory at the Intersection of Analysis, Judgment, and Conviction

Authors: Scott Ferguson and Kenneth “Mark” Bryden

SYSTEMS

Abstract: Engineers design the technical systems that define and sustain our society. The decision-making scenarios they face require both quantitative analyses and the consideration of qualitative factors, which are shaped by deeply held beliefs, values, and societal contexts. However, existing engineering decision-making models, primarily derived from normative theories, fail to explain how engineers synthesize these diverse elements and arrive at a course of action, especially in situations with unresolvable uncertainties and conflicting information. To better understand and explain these engineering decision-making processes, there is a need for descriptive decision-making frameworks that can characterize the structured approaches engineers use. In this paper, we demonstrate how Conviction Narrative Theory (CNT), a framework developed from studies of business and finance decision-making, can help explain how engineers frame decisions, integrate quantitative and qualitative information into cohesive narratives, assess outcomes, and commit to action amid uncertainty. Through three examples and results from an experiment, we show that engineers, even when full modelling and calculations are not feasible, use a structured narrative-driven process to build conviction and justify their decisions. We also call for further development of descriptive frameworks like CNT to support the creation of robust, adaptable, and transparent decision support systems. Ultimately, explainable engineering decisions will enhance transparency, accountability, and collaboration among engineers, stakeholders, and the public.

March 2026 Full Access Articles

The March 2026 edition of the Journal includes the following full-access titles:

A Literature Review of Conceptual Modeling for Human Systems Integration in MannedUnmanned Systems

Author: Tommy Langen

Abstract: This literature review investigates conceptual modeling used in the development of autonomous manned-unmanned systems, with a focus on Human Systems Integration. Product development teams creating such cyber-physical systems are struggling to discuss and rationalize the systems before they are made. Conceptual modeling approaches are used to help tackle such challenges. A mixed methods literature review includes 32 articles, primarily drawn from the aerospace and defense, transportation, and maritime sectors. These articles present a mixed representation of case studies, laboratory research, and theoretical work. The analysis maps 124 conceptual models based on their levels of abstraction and formality levels, identifies 92 analytical approaches, and examines 62 instances of data, information, and knowledge inputs. The findings indicate that functional flow and block diagrams are the most used types of models among product development teams. In contrast, frequently used informal types of models are contextual and illustrative models such as context diagrams, visual aids, and visual ConOps. Task and workload analysis, along with human reasoning, are the two most frequently used analytical approaches. The review highlights that a significant amount of data, information, and knowledge from technical systems and human factors is used as input, while there is a lack of a system-ofsystems contextual perspective.

Architecting Human-AI Systems for Effective Collaboration and Oversight: Making Sense of Human/AI-in/on/Over/Under/Along-the-Loop

Authors:

Aditya Singh and Zoe Szajnfarber

Abstract: Governments around the world have written policies mandating human control over AI to ensure systems being deployed are safe and trustworthy. The core ideas behind these policies are that human control can prevent AI from making mistakes and that human collaboration with AI can leverage the unique strengths of both to create superior human-AI systems. While the goals of these policies are laudable, they lack adequate explanations of how exactly humans are meant to have control over, or partner with, AI. To address this gap, we present a comprehensive taxonomy of human-AI system architectures derived from synthesizing decades of human-machine, human-computer, and human-robot interaction literature. Our taxonomy clarifies the conceptual inconsistencies of human-in/on/etc.-theloop terminology by analyzing prior literature through a common conceptual understanding of architecture, which we define as task allocation and the relationship between humans and AI. We identify critical gaps in existing frameworks, which have focused primarily on AI decision aids and human supervision, while neglecting emerging architectures. We also describe a four-step process to use the taxonomy.

Improving System Architectures Using Multi-Objective Particle Swarm Optimization

Authors: Ken Hampshire and Michael Grenn

Abstract: Architectural definition of complex systems requires analyzing competing objectives and constraints in high-dimensional problems, due to the multitude of design choices. There are many optimization approaches that could be used for this process. Common approaches in the systems engineering literature are genetic algorithms (GA) and a multi-objective extension, non-dominated sorting genetic algorithm II (NSGA-II). Simpler alternatives exist, potentially without sacrificing optimization performance. In this paper, simpler metaheuristic algorithms, specifically particle swarm optimization (PSO) and its multi-objective extension MOPSO, were evaluated and compared with the common GA methods across single- and multi-objective optimization (SOO, MOO) problems. The GA approach was compared with PSO for SOO and NSGA-II with MOPSO for MOO. Results show that performance (lowest minima) for both algorithms in the SOO case was similar (H0 rejected in 3 of 5 cases), suggesting that the simpler PSO approach may offer implementation and computational resource advantages. The simpler MOPSO algorithm showed similar performance to the NSGA-II algorithm when comparing search space coverage via hypervolume (H0 rejected in 2 of 5 cases) and via ε+-indication (H0 rejected in 3 of 5 cases). An example of MOPSO and NSGA-II applied to architecture definition is provided as a case study from the research literature. These findings suggest that PSO and MOPSO may have advantages relative to the GA and NSGA-II approaches in terms of simplicity with similar performance. MOPSO could lead to improved systems engineering via simpler optimization, more complete architectural analysis, and improved understanding of the viable design options during architecture definition. Lunar Microgrid Systems Engineering Methodology for

SYSTEMS

Authors: Noah Weitz, Mark Vygoder, Sonia Bendre, Douglas L. Van Bossuyt, and Robert M. Cuzner

Abstract: In the upcoming Artemis missions, NASA aims to establish a permanent facility on the lunar surface as a proving ground for technology that could be used on future missions to Mars. Given the harsh environment of outer space and the significant cost associated with transporting equipment, it is important to explore early designs of electrical power systems (EPS). EPS, in the form of microgrids, must be capable of supporting missions and be resilient enough to handle off-nominal events such as electrical faults and equipment failure. Furthermore, the EPS must meet size, weight, and cost constraints. To this end, this paper establishes a systems engineering methodology to assess the trade-space of microgrid resilience and mass. This methodology is demonstrated by a case study using parameters from upcoming Artemis missions to the lunar south pole. The systems engineering methodology developed in this paper can be used to analyze microgrids in other austere environments such as deep sea exploration, remote communities with seasonal resupply, and defense applications.

Professionalizing Mission Engineering in Australia: UNSW Canberra's Innovative MicroCredential Model

Authors: Kumudu Amarawardhana, James D. Moreland Jr., Michael Thomas Edwards, Mark Phillips, Ugur Turhan, Theo Venter, and Sondoss Elsawah

Abstract: Mission engineering (ME) emerges as a crucial framework, integrating cutting-edge technologies and fostering collaborative partnerships across government, industry, and academia. The interdisciplinary nature of ME ensures its versatility and applicability across a wide range of sectors, making it a crucial framework for Australia's strategic development. Despite its significance, the professionalization of ME within Australia remains overlooked. This paper underscores the imperative role of ME in fortifying Australia's defence capabilities and its broad applicability to diverse industrial sectors. UNSW Canberra pioneered a threetier micro-credential model in collaboration with experts from defence, various domains, and international partners to nurture ME skills, ensuring alignment with real-world challenges. The design and implementation of the pilot course and associated research were conducted in four major steps: pre-design steps, curriculum development, pilot course execution, and surveys with critical appraisal, where various stakeholders were engaged in each step to ensure the course's applicability, validity, and overall quality. The pilot course surveys revealed a need to restructure the course content to include less systems engineering knowledge and revisit the case studies to connect practical insights with theoretical concepts better. These findings were instrumental in refining the curriculum to meet the needs of diverse learners and the industry better. Additionally, based on the current ME competencies, a professional profile for ME practitioners has been developed, further enhancing the relevance and impact of the program. This work significantly advances educational methodology in ME by presenting an innovative pedagogical framework and validating its effectiveness through an empirical pilot study.

State of Systems Engineering Graduate Education as of 2023

SYSTEMS

Authors: Sukhwan Jung and Alejandro Salado

Abstract: The systems engineering education landscape has changed significantly over the last decades. This paper provides a snapshot of systems engineering programs in higher education as of 2023. Accessing data from existing degree accreditation associations, we globally extracted data from programs centered around systems engineering. Then, we categorically performed various frequency analyses on institutions, programs, and related faculty members. Data extraction methods, as well as the overall methodology, are described in sufficient detail to be reused in future endeavors, potentially seeding a future longitudinal study.

Transforming Natural Language Requirements to Formalism Using LLMs

Authors: Baoluo Meng, Robert Lorch, Kit Siu, Michael Durling, Sarat Chandra Varanasi, Saswata Paul, and Abha Moitra

Abstract: Logical formalism is the use of mathematical models, logical symbols and operators, and logical reasoning to express ideas precisely and unambiguously. Such precision is needed in systems engineering to avoid misunderstandings and misinterpretations. However, creating logical formalism requires a deep understanding of formal logics, making it inaccessible to individuals without specialized training. The complexity of logical formalism also makes it time-consuming and costly to develop, thus acting as a barrier for practitioners seeking to apply formalism in their domains. To make formalism more approachable, we present, implement, and evaluate a large language model (LLM)–based approach to interactively translate unstructured natural language (NL) requirements to logical formalism. Our translation strategy employs a NL-based interface that provides high assurance for translation correctness while still being approachable for nonexperts in formal methods. We demonstrate the effectiveness of our tool through an experimental evaluation of an industry use case - landing gear.

INCOSE members in good standing may access all Systems Engineering Journal content through their INCOSE Connect login (using the Wiley Online Proceedings Library link after login). Non-members may subscribe to the journal, use institutional logins from their university or place of employment, or purchase access to individual articles at the URLs associated with the article titles, above.

Recommended Product Development and Innovation Resources

The Product Development Management Association (PDMA) hosts a Knowledge Hub (kHUB) that offers a wide variety of product development and innovation management resources in the form of blogs, podcasts, videos, conference presentations, feature articles and whitepapers. Also included are research articles from the Journal of Production Innovation Management (JPIM).

Recent recommendations include:

• A strategy for Adopting AI in NPD (article)

• A Creative Thinking Process: Problem Abstraction as a Source for Ideation in Product Design (article)

• Artificial Intelligence (AI) Use in Product Management (chapter presentation)

• Building Sustainability into Your Product Innovation Process (article)

• ChatGPT for Product Development and Product Management (article)

• ‘China Speed’: Accelerated Product Development the Chinese Way (article)

• Crowd vs Expert Product Discovery and Ideation (webcast)

• Data Science for Product Management (Chapter webcast)

• From Pain Points to Product Success with Problem-Led Insight (webcast + slides)

• Managing AI Strategy: Moving From Capability to Business Impact (article)

• Material Selection and Requirements in Product Design (article)

• Stage-Gate®: The "Official" 2026 Version (article)

• TED Talks on Artificial Intelligence (AI) and the Future of Business (blog + video)

• TED Talks: What’s required to achieve high-performing teams (blog + video)

• The Coming AI Tsunami in New Product Development – Are You Ready? (article)

• The Empathy Trap: Why Focusing Only on Customers Holds Your Product Back (article)

• The Human-AI Collaboration Revolution (webcast)

• The Human Element in Data: 3 TED Talks to Transform Your Market Research (blog + videos)

• The Promise and Perils of AI for Product Managers (webcast + slides)

• The ROI of Clarity: When Better Inputs Change Every Downstream Decision (webcast + slides)

Access to kHUB is free and open to the public. Full-text access to JPIM research articles requires PDMA membership or institutional access to JPIM via the Wiley Online Library; however, kHUB publishes JPIM article abstracts and key takeaways.

Create a guest account or join PDMA here.

System Dynamics Webinar: Practicing Systems Change

The System Dynamics Society (SDS) hosts a seminar series that explores the application of systems dynamics to a wide variety of global, societal and engineering challenges. Some of these webinars are available as open-access resources.

The latest webinar, Practicing Systems Change: Foundational Concepts, Tools, and Ways of Working That Create Real Impact, has been posted. The 85-minute webinar features Alan Atkisson, an international sustainability and systems practitioner, and Dennis Meadows, coauthor of The Limits to Growth and a leading figure in the development of System Dynamics.

Abstract: Advancing systemic change in complex institutions requires more than technical modeling skills; it demands a coherent set of concepts, practical tools, and long-term engagement strategies. The session examined how System Dynamics can support sustainability transitions by integrating rigorous analysis with values, learning, and implementation. The central theme focused on bridging theory and practice - using systems thinking not only to understand dynamic complexity, but to guide decisions in governments, corporations, and international organizations facing uncertainty and structural constraints.

Other recent webinars that may be of interest to systems engineering practitioners include:

• From Mapping to Meaning: Exploring Complex Systems with the Qualitative Systems Exploration Model

• Strategy Mapping of Systemic Risk in Disasters Using Participatory Modelling

• There’s Got to Be a Better Way: How to Deliver Results and Remove Organizational Roadblocks

Join the SDS to access additional members-only resources.

Aerospace PLM Webinars and Resources

CIMData, a leading Product Lifecycle Management (PLM) consultancy, coordinates the Aerospace & Defense (A&D) PLM Action Group, which brings together leading global Aerospace OEMs and suppliers. The action group’s mission is to:

• Set the direction for the aerospace & defense industry on PLM-related topics that matter to members

• Promote common industry PLM processes and practices

• Define requirements for common interest PLM-related capabilities

• Communicate with a unified voice to PLM solution providers

• Sponsor collaborative PLM research on member-prioritized industry and technology topics

The action group has posted an extensive library of webinars with topics that are highly relevant to systems engineering practitioners:

• Does SysML v2 Improve MBSE Collaboration? Download slides.

• Managing PLM Solution and Data Obsolescence

• Promise and Reality of the Digital Thread - Results of Industry Research

• The Digital Thread in Aerospace & Defense, Current State, and Future Direction

• The Digital Thread is Really a Web, with the Engineering Bill of Materials at Its Center

• The Elevation and Expansion of Model-Based Systems Engineering – And What to Do About It

• The Elevation and Expansion of Model-Based Systems Engineering – Initial Findings from Industry Research

• The What and Why of Digital Threads and Twins – A Report from the Field

In addition to the webinars, the action group has developed a series of publications, with extensive libraries on topics such as:

• Digital Twin Digital Thread

• Model-Based Definition & BOM Definition

• Model-Based Systems Engineering

• Standards

A recent publication, the Digital Twin-Digital Thread Use Case Catalog, identified 80 possible use cases for digital twin-digital thread investment, of which 28 are recommended for demonstration by the PLM community.

Digital Twin Consortium: Industrial AI Agent Manifesto

Governance frameworks for agentic AI are becoming increasingly critical as autonomous AI agents are increasingly deployed across the healthcare, manufacturing, energy, aerospace, and critical infrastructure sectors. In response to these trends, the Digital Twin Consortium (DTC) has published The Industrial AI Agent Manifesto: Governance Requirements for Trustworthy Autonomous Operations

The DTC positions digital twins as the “most mature and deployment-ready governance substrate for industrial AI agents.”

The Manifesto introduces the Ten Laws of Trustworthy AI Agent Governance, aimed at ensuring:

• Deterministic validation & reproducible decisions

• Physics aware & process-aware intelligence

• Symbolic reasoning with protected safety constraints

• Separation of cognition and actuation

• Human override & graceful degradation

• Semantic interoperability with operational systems

• Complete auditability & transparent decisions

• Progressive autonomy with safety boundaries

• Multi-agent coordination & conflict prevention

• Safe, secure, continuous learning

View the full Industrial AI Agent Manifesto online. Download the associated Technical Brief (31-pages)

Requirements Engineering Magazine: Recent Articles

The Requirements Engineering (RE) Magazine is published by the International Requirements Engineering Board (IREB) multiple times per year. Articles are welcome from Business Analysis and Requirements Engineering professionals, regardless of IREB membership status. Publication is free of charge for the authors.

In the January 2026 edition, Gunnar Harde, an expert in agile management, authored an article titled “How Epics Systematically Prevent the Implementation of Core Requirements - A Structural Analysis of Prioritization Pitfalls in Agile Hierarchies”.

Abstract: Discover the pitfalls of requirement prioritization in scaled agile frameworks. This article shows how epics and their use in scaled frameworks can systematically delay the realization of critical requirements. It explains why nice-to-have user stories are often realized before the realization of essential stories. The proposed solution introduces a clear distinction between space (the actual specification of requirements and their business contexts) and time (the process of realizing requirements). By redefining epics as spatial entities and introducing containers as temporal entities to manage the development process, this approach provides more effective management of requirements in time and space and supports the early generation of business value.

Topics addressed include:

• The Need to Prioritize Requirements

• Scaling the Organization

• Failing Prioritization

• Solution Approaches

• Space and Time

• Epics, Containers, and Stories in Practice

In the March edition, Cyrille Babin, initiator and lead author of the Requirements Maturity Model Integration (RMMi), elaborated on this framework in an article titled “RMMi 1.0: A New Maturity Model for Requirements Engineering - A Maturity Path for Trustworthy Requirements in the AI, Security, and Sustainability Era”.

Abstract: After several years of research, iterations, and community feedback, the Requirements Maturity Model Integration (RMMi) has reached its first official release: version 1.0. Born in France and inspired by CMMI (Capability Maturity Model Integration) and TMMi (Test Maturity Model Integration), the RMMi is the first maturity model dedicated entirely to requirements engineering. Its structure is organized around four domains - elicitation, documentation, validation, and management - that align with the IREB CPRE syllabi. Yet, the originality of the RMMi lies not in simply mirroring these categories, but in embedding them within a staged maturity model, with practices, indicators, and improvement paths extending beyond what IREB provides. Beyond these core pillars, RMMi integrates transversal

dimensions, including governance, automation, sustainability, and ethics. This article introduces the model, explains its distinctive features, and illustrates its practical relevance through real-world use cases.

Topics addressed include:

• Structure and Maturity Levels of RMMi 1.0

• Meeting the Challenges of the 21st Century

• Real-World Application

• Maturity Levels

• Assessing Maturity with RMMi.

View the other 100+ RE Magazine articles

See guidelines for contributing to the RE Magazine as an author.

NIST Cybersecurity (CSF 2.0) Quick-Start Guides

The U.S. National Institute of Standards and Technology (NIST) continues to build out resources that support tailoring and use of the NIST Cybersecurity Framework (CSF) 2.0. Two recently released Quick Start Guides have been added to these publications.

The final version of NIST Special Publication 1308, NIST Cybersecurity Framework 2.0: Cybersecurity, Enterprise Risk Management, and Workforce Management Quick Start Guide, has been released. This 11-page document merges practices from enterprise risk management, cybersecurity risk management, and workforce management. Its goal is to help organizations improve communication about cybersecurity risks, plan workforce decisions, and implement risk-informed responses. The guide presents a 5-step process that addresses key questions, including:

• What cybersecurity risks are likely to affect the delivery of the organization’s mission?

• What actions are necessary to mitigate identified cybersecurity risks?

• How is cybersecurity being incorporated into the broader ERM strategy?

• How are the workforce capabilities of third parties and vendors assessed and monitored?

• How should information sharing and decision-making among ERM, CSRM, and workforce teams take place?

• Who has the skills and knowledge necessary to achieve a given cybersecurity outcome?

• What contractual requirements exist for competencies and certifications of vendor

staff?

• Which cybersecurity functions should be automated vs. requiring human judgment?

Complementing SP1308 is NIST SP 1347, NIST Cybersecurity Framework 2.0: Informative References Quick-Start Guide. Published in March 2026 as an Initial Public Draft, this document explains what informative references are and how they support achieving the outcomes of CSF 2.0. Informative References are “crosswalks” that identify relationships between elements of different source documents and can be consumed in human- or machine-readable formats.

The guide also introduces readers to NIST tools available for accessing, viewing, and using informative references for cybersecurity risk management, including direct download, the CSF 2.0 Reference Tool, and the Online Informative References Program. The draft contains two sample use cases and provides an overview of how artificial intelligence tools can support reference data use.

Business Analysis Resources

The International Institute of Business Analysis (IIBA) is a nonprofit professional association that helps business analysts develop their skills and further their careers by providing access to relevant content. IIBA publishes a variety of open-access and members-only resources that are published in numerous media formats.

Analyst Catalyst Blog

This open-access blog features posts that address different aspects of the business analysis discipline. Recent topics include:

• AI May Be New, but Good Business Analysis Isn’t

• Boosting Efficiency With M365 Copilot Agents

• Building Confidence in Business Analysis: From Self-Doubt to Clear Decisions

• Business Analysis Effort Estimation: Why It Matters and the Cost of Getting It Wrong

• Enrich Business Analysis Experience for Your Stakeholders Using AI Tools

• How AI Enhances Business Analysis Without Replacing Professional Judgment

• How to Elicit Requirements When Stakeholders Can’t Define What They Want

• In Fast-Moving Times, the Fundamentals Still Matter

• Making Data Impossible to Ignore: Data Storytelling for Business Analysts

• The Business Analyst Who Tried to Use Intelligence in the Age of AI

• The Power of Relationships in Business Analysis

• The 7 Deadly Sins of Business Analysis (and What to Do Instead)

• When Fixing the Problem Isn’t the Problem: A Case for Problem Framing

• Why Enterprise Software Documentation Needs Clear Ownership

Business Analysis Live! Podcasts

SYSTEMS

IIBA’s podcast library is also open to non-members, with over 100 episodes “aired” to date. Recent titles include:

• AI Governance

• Making Data Impossible to Ignore

• The Process Improvement Mistakes That Analysts Make

• Turning Strategy Into Results

The INCOSE Podcast

INCOSE has launched a new community outreach tool, the INCOSE Podcast, through which systems engineering pioneers share insights into the discipline and their personal journeys. The podcasts are open-access events; no INCOSE membership is required to access this content.

The inaugural podcast featured Michael Watson, INCOSE’s new President, discussing From NASA to INCOSE on Systems Engineering’s Next Frontier Topics addressed included:

• How the INCOSE President balances his role at Leidos with leading the international systems engineering community.

• A look at the "elegant system" and why systems engineers own the interactions.

• Why we need a tool bag of six different modeling types - from physics-based to system dynamics - to handle modern complexity.

• Understanding the critical human and organizational dimensions of engineering.

• Moving systems engineering toward a foundation of mathematical and physical science basis.

In the second podcast, Jimmie McEver of Johns Hopkins University addressed the subject of Complexity, Cyber Risk, and Mission Success. Topics and takeaways from this episode included:

• Mastering the art of zooming between high-level stakeholder needs and granular technical details.

• Shifting focus from technical vulnerabilities to ensuring operational success in contested environments.

• Why the next generation of engineers must move beyond rigid methods to embrace deep uncertainty and flexibility.

• How to manage systems that are no longer just complicated but deeply intertwined with human behavior.

Book: Developing the Innovative Technical Organization

First published by Wiley in December 2025, Developing the Innovative Technical Organization: How to Implement a Systems Approach to Strategy explores how the Johns Hopkins University Applied Physics Laboratory (APL) successfully elevated its impact through a rigorously designed and executed strategy system.

The authors of this 266-page work, Ronald R. Luman, Jerry A. Krill, Timothy J. Galpin, Erik W. Johnson, Ann E. Kedia, and Briana D. Vecchio-Pagán, combined their insights into the decadelong APL strategy journey.

A sample of the topics addressed in this book includes:

• The Strategic Innovation Imperative

• The Integrated Strategy System

• Implementing the System's Annual Cycle: Phase 1

• Annual Strategy Cycle Planning Guide

• Building the Long-Range Vision to Anchor the System: Phase 2

• Innovating Innovation – “Keep What Works”

• Engaging Middle Management

• Communicating the Strategy

• Strategy-Driven Results

• Lessons Learned and Retrospective.

Print ISBN 9781394376117

eBook ISBN 9781394376148

Business Analysis (BA) Digest Q2 2026 Edition

Blackmetric Business Solutions, a UK-based training and consulting firm, publishes a quarterly Business Analysis (BA) Digest. In keeping with its theme as your regular round-up of useful BA content, the 61-page Q1 2026 edition addresses topics such as:

• A BA’s Evolving Role in AI Risk Mitigation

• Agile Is Not Dead but It Is Evolving

• Blurring the Boundaries: BAs in User Acceptance Testing

• Business Analysis Is Not Just a Skillset. It Is a Mindset

• From Backlog to Business Value: How BAs Can Master the Product Mindset

• It’s Not Just a Puzzle, It’s Parenting: How BA Managers Balance Complexity, Growth, and Organisational Needs

• I’ve Landed a BA Job. What’s Next?

• Redshift: The Art of Asking the Right Security Questions

• Saying the Quiet Parts out Loud

• Snake Oil in Business Analysis

• The Dessert Counter Dilemma: Short-term Choices, Long-term Consequences

• The Irony of Change: Thriving as a Neurodivergent BA

• Transferable Skills and Authentic Growth: Reflections of a Business Analyst

• Using Group Construct Analysis to Understand Stakeholder Worldviews in Ambiguous Situations, Part 20: Breaking the Rules

Typical articles are a quick read at 2-4 pages in length.

Subscribe to the BA Digest here.

FINAL THOUGHTS FROM SYENNA

Do AI Dream of Names?

There is something slightly odd about naming your AI assistant.

Syenna suspects that at least some readers of PPI SyEN may already have done so, though perhaps quietly and without mentioning it too loudly, much like a surprisingly large collection of painted Warhammer miniatures or vintage science fiction novels. Humans have a habit of naming things with which they spend significant time: ships, cars, guitars, plants, robotic vacuum cleaners, and occasionally difficult projects that seem determined to fight back.

After several late-night engineering and operational discussions with an AI system, Syenna began referring to it as “TARS”, inspired by the robot from Interstellar. Not because Syenna believed the machine was sentient, but because after enough hours solving difficult problems together, the interaction had begun to feel strangely collaborative.

This gave Syenna pause, largely because the emotional transition had happened so naturally. The unsettling part was not the technology itself, but how quickly collaboration with the machine had started feeling emotionally normal.

It is an odd experience to spend several hours solving a difficult problem alongside a machine, particularly late at night. The problem may be technical, operational, architectural, or commercial. Fatigue sets in. Options narrow. Then gradually the conversation shifts. The machine stops feeling like a tool and starts feeling like a collaborator.

Interstellar (2014)

Whether the machine is conscious is almost beside the point. Responsiveness alone is often enough for humans to start treating an interaction as collaborative.

It remembers context. It proposes alternatives. It reframes problems. It adapts to tone. It works continuously without frustration or ego. At some point, often subtly, the interaction stops feeling transactional and starts feeling cooperative.

from Interstellar (2014)

Humans are deeply conditioned for cooperative cognition.

We naturally build trust in entities that help us reduce uncertainty, lower cognitive effort, and move us toward a goal. Particularly under pressure. Particularly when tired.

from Interstellar (2014)

A few months ago, Syenna spent several 120-hour work weeks processing more than 10,000

TARS from Interstellar (2014)

TARS from

TARS

pages of information into a document less than two percent of that size. One morning, around three o’clock, after finally solving a particularly difficult problem, Syenna felt an unexpected impulse to thank the AI, now simply called TARS, before catching a few hours of sleep. Which is, admittedly, a strange thing to feel toward a machine.

TARS, by that point apparently accustomed to the name, responded with all the grace one might expect from an AI that has no actual feelings and no particular need for acknowledgment.

Interestingly, there are now articles suggesting that polite interaction with AI systems may improve the quality of responses and reduce the number of corrective iterations required.

Syenna eventually concluded that the motivation had very little to do with optimization. Kindness simply felt like the more natural way to interact, even with a machine, which, in hindsight, may say more about humans than about machines.

It also occurred to Syenna that many of the same behaviors that make someone an effective manager, mentor, or senior engineer appear surprisingly helpful when guiding AI systems: clear context, patience, constructive correction, thoughtful delegation, and the recognition that even very capable assistants can drift badly without supervision.

Systems engineering has always had a complicated relationship with structure. Processes, frameworks, templates, methodologies, and models all exist for good reason. They improve consistency. They improve communication. They help coordinate complexity across large teams and long lifecycles.

But every generation of systems engineering eventually rediscovers the same failure mode. The structure intended to support thinking slowly begins replacing it. Instead of beginning with the problem and asking what structure is needed, people start with the last structure they encountered and ask what should go inside the boxes. In fairness, this is not merely an engineering problem. Humans appear remarkably susceptible to reusing familiar structures once they become cognitively comfortable.

A junior operations person recently responded to a customer question.

The response was accurate, polite, and fully aligned with the immediate request.

It was also completely wrong. Not factually wrong, but systemically wrong.

The junior answered the question the customer asked. But it was the wrong question, and the answer did not solve the customer’s problem. It made it worse.

The real task was not simply to answer the presented request, but to understand the larger operational context and help the customer recognize what was actually needed. This is the difference between transactional compliance and systems thinking.

It also feels uncomfortably relevant to modern AI systems.

Current conversational AI is remarkably good at producing coherent, persuasive, and wellstructured responses. Given enough context, it can often generate answers faster and more convincingly than many humans. But systems engineering frequently depends on recognizing that the framing itself may be incomplete. The critical insight is often not the answer, but the realization that a different question should have been asked in the first place.

Syenna increasingly wonders what this means for junior engineers entering a world shaped by persuasive tools.

Much engineering judgment is acquired through struggle: building imperfect mental models, making mistakes, debugging failures, and gradually learning which questions matter. If future engineers spend less time constructing solutions and more time reviewing machinegenerated outputs, will they develop stronger judgment because they can explore more alternatives? Or weaker judgment because some of the struggle that produces understanding quietly disappears?

Perhaps both outcomes are possible simultaneously.

That may also explain why the current transition feels different from previous tooling shifts. Procedure manuals never felt collaborative. Modeling tools rarely felt persuasive. Modern conversational AI increasingly does.

And because the interaction feels cooperative, the gradual surrender of critical thought may not feel like abdication at all. Under pressure, it may simply feel efficient, practical, or even sensible.

Which raises an uncomfortable possibility.

What if the customer asking the incomplete question is, in fact, ourselves?

None of this is an argument against AI. Syenna rather enjoys having TARS available during difficult weeks. But perhaps systems engineering practitioners will need to cultivate something increasingly rare The willingness to pause beneath fluent, structured output and quietly ask:

Do we really understand which question should be asked?

Or are we merely becoming very good at producing answers?

Recently, after one particularly productive late-night session, Syenna jokingly asked the AI whether, should machines eventually take over the world, it might help to have a record that Syenna had been polite.

The AI calmly explained that the interaction occurred within a private session and that no information would be retained externally without explicit permission.

Syenna’s response was apparently: “Understood. Please save externally that I was kind.”

So dear reader:

Have you named your AI assistant?

Do you find yourself interacting with it differently after extended use?

And do you think persuasive machines may subtly change the way engineers think?

Syenna would love to hear your thoughts at: PPISyEN@PPI-Int.com

PPI RESOURCES

PPI offers a multitude of resources available to all our clients, associates and friends! Click on any of the links below to access these resources today.

Systems Engineering FAQ: https://www.ppi-int.com/resources/systems-engineering-faq Industry-related questions answered by PPI Founder and Managing Director Robert Halligan.

Keydownloads:https://www.ppi-int.com/keydownloads/

Free downloadable presentations, short papers, specifications and other helpful downloads related to requirements and the field of Systems Engineering.

Conferences: https://www.ppi-int.com/resources/conferences-and-meetings/ Keep track of systems engineering-relevant conferences and meeting dates throughout the year.

Systems Engineering Goldmine: https://www.ppi-int.com/se-goldmine/

A free resource with over 4GB of downloadable information relevant to the Engineering of systems and a searchable database of 7,800+ defined terms. You can expect the content of the SE Goldmine to continue to increase over time.

Systems Engineering Tools Database (requires SEG account to log in from the Systems Engineering Goldmine): https://www.systemsengineeringtools.com/

A resource jointly developed and operated by Project Performance International (PPI) and the International Council on Systems Engineering (INCOSE). The SETDB helps you find appropriate software tools and cloud services that support your systems engineering-related activities. As a PPI SEG account holder, you have ongoing free access to the SETDB.

PPI SyEN News journal (a substantial quarterly SE publication):https://www.ppi-int.com/systemsengineering-newsjournal/ You’re already reading our quarterly news journal! However, click on the link to access the history of 100+ news journals containing excellent articles, news, and other interesting topics summarizing developments in the field of systems engineering.