Systems Engineering

The Traditional Practice

Systems engineering has always been about managing complexity — decomposing systems into subsystems, defining interfaces, flowing requirements, and verifying that the integrated whole meets stakeholder needs. The discipline has been structured and methodical since its formalization in the 1960s for defense and space programs.

But structured does not mean digital. Traditional systems engineering is overwhelmingly document-centric: requirements in spreadsheets or word processors, architectures in slide presentations, traceability in manually maintained matrices, and verification evidence scattered across test reports and analysis documents. The systems engineer's primary tool has been the document, not the model — and the primary integration mechanism has been the review meeting, not the computable data link.

Model-Based Systems Engineering (MBSE) has been promoted for over a decade as the remedy. But the digital engineering transformation goes beyond MBSE. It's about making the entire system description — requirements, architecture, behavior, interfaces, verification — computable, queryable, and connected to every downstream engineering activity.

What's Different Now

From Document-Centric to Model-Based — and Beyond to Computable Knowledge Graphs

Traditional MBSE represents an improvement over document-based SE: system architecture is captured in formal modeling languages (SysML, OPM) rather than in slide diagrams, and requirements are stored in databases rather than documents. But most MBSE implementations stop at representation — the model is a better document, not a fundamentally different way of working.

The digital thread as a computable knowledge graph goes further:

• Typed, linked data: Every element in the system description — every requirement, interface, component, test case, risk — is a node in a graph with typed relationships. "Requirement R-042 is verified by Test T-117, which uses Test Procedure TP-089, which was last executed on Build B-23 with result PASS." This chain is computable, not implicit in someone's head or buried in a document
• Automated impact analysis: When a stakeholder changes a requirement, the graph instantly identifies every affected design element, interface, test case, and verification artifact. Traditional impact analysis requires an engineer to manually trace through documents — a process that takes days and misses connections
• Cross-program reuse: When system descriptions are structured data rather than natural language documents, components, interfaces, and verification approaches can be searched, compared, and reused across programs — building institutional knowledge computationally

The shift: The system model moves from a representation of the architecture to a computable knowledge base that enables automated reasoning about the system.

Reference: INCOSE Vision 2035, which calls for "digital engineering ecosystems" as the future of SE practice. DoD Digital Engineering Strategy (2018) mandating model-centric acquisition. ISO/IEC/IEEE 15288:2023 (Systems and Software Engineering — System Life Cycle Processes). OMG SysML v2 specification enabling interoperable, API-accessible system models.

From Manual Requirements Analysis to NLP-Assisted Specification

Traditional requirements engineering is a deeply human process: stakeholders express needs in natural language, systems engineers interpret and formalize them into "shall" statements, and reviewers check for completeness, consistency, and testability. This process is slow, subjective, and error-prone. Studies consistently find that 40-60% of system defects originate in requirements.

NLP for requirements engineering automates the parts that humans do poorly at scale:

• Ambiguity detection: ML models flag requirements with vague terms ("appropriate," "sufficient," "timely"), passive voice, missing quantification, and other patterns correlated with downstream defects
• Completeness checking: NLP models trained on domain-specific requirement corpora identify gaps — requirement categories that similar systems address but this specification doesn't mention
• Consistency analysis: Automated detection of conflicting requirements — two requirements that impose incompatible constraints on the same system element — across specifications with thousands of requirements where manual cross-checking is impractical
• Automatic classification: ML models categorize requirements by type (functional, performance, interface, constraint) and map them to system architecture elements, accelerating the allocation process

The shift: Requirements analysis moves from manual expert review (which doesn't scale) to AI-assisted analysis that processes thousands of requirements systematically.

Reference: IEEE Transactions on Software Engineering and Requirements Engineering Journal publish extensively on NLP for requirements. INCOSE INSIGHT and Systems Engineering Journal special issues on AI in SE. INCOSE Requirements Working Group publications.

From Manual Architecture Exploration to AI-Assisted Trade Studies

Traditional architecture development relies on the systems engineer's experience and creativity. The architect conceives candidate architectures (typically 2-4), evaluates them against criteria using weighted scoring or utility analysis, and selects the preferred approach. The number of alternatives explored is limited by human cognitive capacity and calendar time.

AI-assisted architecture exploration expands the search:

• Generative architecture synthesis: Given a set of functional requirements and constraints (mass budget, power budget, cost targets, technology readiness levels), algorithms generate candidate architectures by combining and configuring building blocks from component libraries. Instead of 3 human-conceived alternatives, the system evaluates hundreds
• Multi-objective trade space analysis: Evolutionary algorithms explore the trade space across competing objectives (performance, cost, schedule risk, reliability) and surface the Pareto frontier — the set of architectures where no objective can be improved without degrading another
• Sensitivity and robustness analysis: For each candidate architecture, Monte Carlo simulation with uncertainty in component parameters reveals which architectures are robust to assumptions and which are fragile

The systems engineer shifts from conceiving architectures to evaluating and refining AI-generated candidates — bringing engineering judgment to a much richer set of options.

The shift: Architecture selection moves from evaluating a handful of human-conceived options to exploring a computationally generated trade space and selecting from Pareto-optimal alternatives.

Reference: INCOSE Systems Engineering Journal papers on computational architecture exploration. AIAA MDO (Multidisciplinary Design Optimization) conference tracks on system architecture. NASA's Architecture Trade Space Exploration tools. DoD Engineered Resilient Systems (ERS) program.

From Manual V&V to Automated Verification Pipelines

Traditional verification follows the V-model: requirements at each level are verified through a combination of inspection, analysis, demonstration, and test. Verification is planned early, executed late, and the results are documented in test reports that trace back to requirements through manually maintained matrices. When a design change occurs late in the program, the cost of re-verification is enormous because test campaigns must be partially repeated.

Automated V&V pipelines — borrowing from software engineering's continuous integration practices — transform this:

• Continuous verification: Every model change triggers automated checks — requirement satisfaction analysis, interface consistency validation, simulation-based performance evaluation — providing immediate feedback rather than waiting for formal test events months later
• Simulation-based qualification: Virtual test campaigns using validated models replace or supplement physical tests, especially for conditions that are dangerous or impossible to create physically (structural failure modes, extreme environments, rare fault combinations)
• Automated evidence collection: Test results, analysis outputs, and inspection records are automatically linked to the requirements they verify, maintaining a continuously current verification status dashboard — not a matrix that's updated quarterly

The shift: Verification moves from discrete test events with manual evidence management to continuous, automated verification integrated into the engineering workflow.

Reference: INCOSE Handbook on Systems Engineering (5th edition) sections on digital V&V. DoD Digital Engineering Strategy emphasis on automated testing in digital environments. ISO/IEC/IEEE 29119 (Software and Systems Testing). NASA-STD-7009 for simulation credibility in verification.

The Tool Ecosystem

What Systems Engineers Need to Learn

Systems thinking, stakeholder analysis, requirements engineering, and architecture principles remain the foundation. What's added:

• Formal modeling proficiency: Not just drawing SysML diagrams, but building system models that are computable — with precise semantics, typed relationships, and API-accessible data
• AI/ML literacy for trade studies: Understanding how optimization algorithms explore trade spaces, what Pareto optimality means in practice, and how to set up architecture exploration problems for computational solution
• Data engineering: The digital thread is fundamentally a data integration problem. Systems engineers need to understand data schemas, ontologies, APIs, and how information flows between tools and disciplines
• Automation mindset: Borrowing CI/CD concepts from software engineering and applying them to systems verification — writing executable test procedures, automating evidence collection, and maintaining verification pipelines

Key Organizations and Resources

• INCOSE — Vision 2035, Systems Engineering Journal, INSIGHT magazine, SE Handbook (5th edition), Requirements Working Group, MBSE Initiative
• IEEE — Systems Journal, Transactions on Systems, Man, and Cybernetics
• DoD — Digital Engineering Strategy (2018), Engineered Resilient Systems (ERS) program, Digital Engineering Fundamentals working groups
• ISO/IEC/IEEE — 15288 (System Life Cycle Processes), 42010 (Architecture Description), 29119 (Testing)
• NASA — Systems Engineering Handbook (SP-2016-6105), NASA-STD-7009 (simulation credibility), Architecture Trade Space Exploration tools
• OMG — SysML v2 specification, UAF (Unified Architecture Framework)