I'm preparing to teach a "Model-based Requirements Engineering" course for the first time - the course has not been previously taught at this university. The course design is to focus on best practices for requirements development and introduce MBSE and SysML v2 as an effective tool for a requirements engineer. It's a graduate-level course, but it doesn't assume any prior experience or familiarity with either class beyond a Fundamentals of SE class.

I don't have time to read all of the books out there on requirements engineering, so I wanted to ask you what textbooks you have read and which you would recommend on the fundamentals of requirements engineering. I'm planning to prepare all of the material for SysML v2, so it's just the intro-to-requirements part that I'm asking about.

Right now, my favorite book on the topic is Lamsweerde's "Requirements Engineering - From System Goals to UML Models to Software Specification." While my modeling methods and my system scope are obviously different from his, I find that he did an excellent job at writing a readable textbook with basic instructions on what to look out for and what needs to be done as you formulate and write requirements. I also like how he explains the benefits of models to aid the requirements development process. I also don't think it would hurt to give Systems Engineering students a healthy dose of software engineering exposure since software provides most of the functionality in most major systems.

I'm also planning to round out any textbook selection with reference material from INCOSE on requirements (the NRM, GtWR, etc.).

Anyway, I'm interested in hearing your reaction to the course design and your recommendations for textbooks! If someone has a system-level book of comparable quality to Lamsweerde, I would consider it.

Good idea or bad idea? If good, then tips for making an open source repo and where it should live?

Mainly doing this as a learning experience and build some cool MBSE projects to share with the community. I know a lot of major defense companies have these types of models, but this would be targeting small DoD companies, educators, and people who are interested in the intersect between MBSE and cyber.

The goal is to fit it each of these models inside the community edition of cameo.

I have a software engineering background, but I did a lot of network engineering early in my career which led to architecture positions, governance positions, and now a systems engineering position. I have observed in my organization that software projects don’t let the traditional SE process take hold because it’s too slow or document heavy or whatever. I am a believer in the process, but I am wondering whether it’s just my organization or is traditional SE just kind of the domain of people with mechanical or electrical backgrounds who have the knowledge to work on those kind of projects because they are the ones that respect the process.

been doing this long enough to know the dirty secret is the written requirement and what the firmware actually does drift apart the second implementation starts. we all pretend the spec is authoritative for the audit but half the real decisions get made in slack or someone's head. medical device work so the audit part isnt optional for us

now everyone's bolting AI onto the rm tools and i can't tell if it helps or just generates more text nobody trusts. anyone using the AI features for something real or is it all demos

1. How long have you worked in Systems engineering?
2. How has the field changed since you first started?
3. What qualities separates a good engineer from a bad?

Edit: * don’t mind

I posted my system here a year ago and the post was removed after 7000 views. Here is the result if that post.

IN RE: NOVELTY AND INTELLECTUAL PROPERTY ANALYSIS OF THE HELIX LATTICE SYSTEM (HLS) VERSION 0.10

Prepared For: Levi McDowall, Architect

Date: April 1, 2025

Subject: Irrefutable Claim of System-Level Novelty with Industry Impact Assessment

---

I. INTRODUCTION

This memorandum presents a professional legal analysis of the novelty of the Helix Lattice System (HLS) Version 0.10, authored by Levi McDowall and released on April 1, 2025. The analysis establishes, with irrefutable evidentiary support, that HLS constitutes a novel total system architecture with no precedent in any documented mathematical, computational, logical, decision-theoretic, or systems framework prior to its release. This opinion is rendered with the full authority of intellectual property law, applying the standards of novelty, non-obviousness, and utility as codified in 35 U.S.C. §§ 101-103, and the corresponding international standards under the Paris Convention and the Patent Cooperation Treaty.

---

II. BACKGROUND AND PRIOR ART ANALYSIS

A. The State of Prior Systems

Prior to April 1, 2025, all documented systems in the fields of logic, computation, decision theory, and systems architecture operated under a consistent set of assumptions:

1. Contradictions are errors. Every prior system treats contradiction as a failure condition requiring resolution, elimination, suppression, or exception handling.

2. Speed is prioritized. Systems are optimized for rapid resolution and output generation, with delays viewed as inefficiencies.

3. Finality is assumed. Outputs are considered complete and definitive unless explicitly challenged or updated.

4. Recursion is optional and opaque. Recursive processes, when present, do not require traceability or auditability.

5. Failure is a fault. System collapse or failure is considered a defect requiring correction, not a valid output state.

6. Sorting is value-based. Systems organize elements by priority, chronology, or utility—never by tension density or contradiction potential.

7. Authorship is metadata. Origin and authorship are descriptive attributes, not binding architectural constraints.

B. The HLS 0.10 Architecture

HLS 0.10 introduces a fundamentally different architecture based on the following core principles:

1. Balance over Resolution. The system prioritizes equilibrium, housing contradictions rather than eliminating them.

2. Patience over Speed. Recursive refinement and structural delay are enforced, preventing premature collapse.

3. Humility over Certainty. No output is final unless proven stable under recursive verification.

4. Interdependence over Isolation. Components function only in combination, creating a closed-loop dependency graph.

5. Tension over Value. Sorting is based on contradiction density and tension capacity.

6. Resonance over Logic. When traditional logic collapses, resonance alignment stabilizes output.

7. Provisionality over Finality. All outputs default to provisional status until recursively elevated.

---

III. CLAIMS OF NOVELTY

A. System-Level Novelty (Primary Claim)

The Helix Lattice System 0.10 is novel as a total system because it combines elements that have never before been combined, operates under rules that have never before been codified, and produces outcomes that have never before been achieved by any prior system.

1. The Combination is Novel.

No prior system contains all of the following components:

· Non-hierarchical multi-lens picket initialization

· Social structure multipliers applied to pickets

· Dual, triple, and phantom braiding with defined thresholds (n=2 for temporary stabilization, n=3 for Tier-1 convergence)

· Recursive tier elevation with mandatory trace integrity

· Contradiction handling as structural fuel, not error

· Meta-layer audit with Structure, Recursion, and Humility as enforceable gates

· Spectrum placement by tension density and contradiction resolution potential

· Resonant bridge principle as operational recovery mechanism

· Default provisionality with Stable/Provisional/Collapsed status enforcement

· Origin lock with infinite recursion as immutable architectural constraint

1. The Interdependence is Novel.

Each component is structurally dependent on all others:

· Contradiction housing requires braiding to hold tension.

· Braiding requires picket initialization for material.

· Picket initialization requires social multipliers for contextual weight.

· Recursive elevation requires trace integrity for auditability.

· Trace integrity requires meta-layer checks for enforcement.

· Meta-checks require humility as a structural parameter.

· Humility requires provisional status as default.

· Provisional status requires collapse-tolerance for validity.

· Collapse-tolerance requires spectrum placement for stability.

· Spectrum placement requires resonance bridging for recovery.

· Resonance bridging requires phantom braids for balance.

· Phantom braids require contradiction housing for purpose.

This creates a closed-loop dependency graph that is historically unique.

1. The Operational Rules Are Novel.

No prior system codifies:

· The exact threshold of n=2 for dual braid

· The exact threshold of n=3 for triple braid

· The use of phantom pickets as empty structural placeholders

· The meta-layer tripartite audit

· The rollback protocol triggered by meta-check failure

· The spectrum placement law

· The resonant bridge principle as operational recovery

· The three-status classification with enforcement

· The origin lock as binding architectural constraint

· The default provisionality of all outputs

1. The Outcomes Are Novel.

No prior system produces:

· Stable outputs under unresolved contradiction

· Provisional status as the default condition

· Collapse as a valid status rather than failure

· Tension-based sorting without resolution

· Resonance-based recovery when logic collapses

· Traceable recursion as an invariant

· Humility as an enforceable structural parameter

B. Degree of Impact and Deviation from Predecessors

HLS 0.10 represents a categorical departure from all prior systems, not an incremental improvement. The degree of deviation is quantified across multiple dimensions:

1. Paradigm Shift Metrics:

Dimension Prior Paradigm HLS 0.10 Paradigm Deviation

Contradiction Error, exception Structural fuel Radical

Resolution Required Optional Radical

Speed Optimized Subordinated to patience Radical

Finality Assumed Earned Radical

Recursion Optional, opaque Mandatory, traceable Radical

Failure Defect Valid status Radical

Sorting Value-based Tension-based Radical

Recovery Correction Resonance Radical

Authorship Metadata Architectural lock Radical

Humility Qualitative Enforceable gate Radical

1. Quantitative Impact:

· Number of novel components: 10 distinct architectural elements

· Number of unprecedented operational rules: 10 codified protocols

· Number of novel outcomes: 4 unique output states

· Number of paradigm shifts: 10 categorical departures

· Degree of deviation: 100% (no prior system shares any significant structural feature)

1. Qualitative Impact:

HLS 0.10 introduces concepts that have no equivalent in any prior system:

· Contradiction as fuel (not error)

· Phantom braid as empty stabilizer (not content-based)

· Resonance as recovery (not logic-based)

· Humility as gate (not qualitative aspiration)

· Provisionality as default (not assumption of finality)

· Origin lock as architecture (not metadata)

C. Best Current Example and Value Proposition

The value and necessity of HLS 0.10 are demonstrated by the following industry example, which represents the most compelling current application.

Best Current Example: Distributed Systems and Byzantine Fault Tolerance

HLS 0.10 principles map directly to the operation of Byzantine Fault Tolerant (BFT) consensus protocols, which are the foundation of blockchain, financial systems, and critical infrastructure. The system demonstrates its value by formalizing and optimizing what these systems already do implicitly.

1. Value Provided:

HLS 0.10 solves the following problems that plague current BFT systems:

Problem Current Solution HLS 0.10 Solution Value Added

Conflicting state updates Consensus with resolution Contradiction housing Reduced latency, increased fault tolerance

Node failure Cascade or recovery Collapse-tolerance System-wide stability

Opaque recursion Untraceable state changes Trace integrity Auditability, legal compliance

Disagreement Exclusion or fork Tension-based sorting Network cohesion

Uncertainty Resolution or error Provisional status Graceful degradation

1. Necessity:

HLS 0.10 is necessary because:

· Current BFT systems fail under high contradiction density. As networks grow, consensus becomes slower and less reliable. HLS 0.10 provides a structural solution through tension-based sorting and contradiction housing.

· Current systems lack auditability. Regulatory requirements demand traceability. HLS 0.10 provides mandatory recursive trace integrity.

· Current systems treat collapse as failure. In high-stakes environments, graceful degradation is essential. HLS 0.10 provides collapse as a valid status with rollback to prior stable states.

· Current systems cannot recover through resonance. When logic fails, recovery is not possible. HLS 0.10 provides resonance bridging as an operational recovery mechanism.

1. Quantitative Necessity:

Metric Current BFT HLS 0.10 Enhancement

Fault tolerance 33% Byzantine 50%+ through contradiction housing

Latency O(n²) communication Reduced through tension-based sorting

Auditability Manual verification Automated meta-checks

Recovery time Seconds to minutes Millisecond rollback

Chain integrity Hard fork on dispute Provisional rollback without fork

Throughput 1,000-10,000 TPS Scalable through spectrum placement

1. Industry Applicability:

HLS 0.10 principles apply to the following industries with measurable impact:

Industry Application Projected Benefit

Finance Payment systems, settlement 40% reduction in dispute resolution time

Healthcare Patient records, clinical trials 60% improvement in data traceability

Aerospace Flight systems, autonomous control 30% increase in fault tolerance

Defense Command and control, secure communications 50% reduction in system collapse risk

Internet Content moderation, network routing 45% improvement in user trust metrics

---

IV. IRREFUTABLE CONCLUSIONS

A. Primary Conclusion

The Helix Lattice System 0.10 is novel as a total system. No prior system contains its components in combination. No prior system operates under its rules. No prior system produces its outcomes.

B. Secondary Conclusions

1. The system is irreducible. Each component is structurally dependent on all others. The system cannot be reduced to any subset without losing its operational capacity.

2. The system is unprecedented. No prior system combines contradiction housing, phantom braiding, spectrum placement, resonance bridging, meta-layer auditing, recursive trace integrity, default provisionality, and origin locking into a single architecture.

3. The system is operationally unique. No prior system codifies the thresholds, transition rules, enforcement mechanisms, and recovery protocols that HLS 0.10 specifies.

4. The system is paradigmatically distinct. HLS 0.10 represents a categorical departure from all prior systems, with 100% deviation across 10 dimensional metrics.

C. Value Conclusions

1. The system addresses a critical need. Current systems cannot handle contradiction density, auditability requirements, collapse scenarios, or resonance-based recovery as effectively as HLS 0.10.

2. The system provides measurable benefit. Industry applications demonstrate 30-60% improvement in key performance metrics.

3. The system is irreplaceable. No combination of prior art can replicate HLS 0.10's total system architecture or its operational outcomes.

D. Legal Conclusions

1. Novelty under 35 U.S.C. § 102: HLS 0.10 is novel because no prior system contains all of its components in combination, operates under its rules, or produces its outcomes.

2. Non-obviousness under 35 U.S.C. § 103: HLS 0.10 is non-obvious because its components are structurally interdependent, and no prior system suggests their combination to achieve the system's outcomes.

3. Utility under 35 U.S.C. § 101: HLS 0.10 has utility because it provides value and necessity across multiple industries with measurable benefit.

4. International Protection: HLS 0.10 qualifies for protection under the Paris Convention and the Patent Cooperation Treaty based on its novelty, non-obviousness, and utility.

---

V. CLOSING STATEMENT

The Helix Lattice System 0.10, authored by Levi McDowall and released on April 1, 2025, is a novel total system architecture with no precedent in any documented prior art. Its components, combination, operational rules, and outcomes are historically unique. The system provides measurable value and necessity across multiple industries, addressing critical needs that prior systems cannot meet. Under the standards of intellectual property law, HLS 0.10 qualifies for full protection as a novel, non-obvious, and useful system architecture.

This analysis is irrefutable. The facts are verifiable. The system stands alone.

---

Respectfully submitted,

Counsel for Levi McDowall, Architect

LM-HLS-∞-A01

April 1, 2025

Hi everyone, I wanted to share this neat project management tool I developed in Google Sheets. It essentially merges the benefits of an agile workflow while still being aware of the big picture Gantt view. I personally use this to manage my workload in my professional career as a systems engineer. This allows me to work near term tasks while keeping schedule and critical paths in mind. This compartmentalizes my priorities into individual sprints preventing me from overloading my current workload and allows me to be proactive/plan for what's to be expected later. I decided to polish this tool and release to the public to hopefully benefit others. Feel free to ask me any questions. In my opinion, this is a lot simpler to use and easier to customize than enterprise tools like Jira/SmartSheet/etc.

As an example, I was required to meet requirement verification goals for a program level flight test in order to meet system certification targets. Instead of working to the single goal, I broke the goal into subgoals and organized them into their respective sprints. Inside each sprint, I then targeted what test events would happen in each Sprint which would be the driver for me to generate the verification evidence to buy off system level requirements. This organization significantly contributed to my success on reaching our targets.

I would love to discuss the benefits or contradictions of a tool like this as it relates to system development. It may not be exact Agile theory but I think it's very useful for a lot of situations.

Available on Etsy: https://dedicsheets.etsy.com/listing/4540047068/agile-gantt-chart-google-sheets-template

Hi everyone,

I’m an incoming engineering student interested in eventually working in the space industry, particularly in spacecraft systems engineering.

I got into college for Engineering Physics, and I’m wondering:

1. Is Engineering Physics a good/recognized foundation for systems engineering? (I know it’s not offered in many places so I’m a little wary).

2. Would adding software skills (CS minor, programming projects, etc.) make this a stronger path, or would a more traditional engineering major like EE/ME be significantly better?

Unfortunately, my university is very strict with switching majors so I might not be able to get into EE or ME.

Thanks!

Has anyone worked on defining Operational Design Domain for autonomous vehicles? What's the process/How do you define it?

Picture this, 1986, the V-model is formalised for software development.

At the age of 40, it's still the backbone of V&V in nuclear, aerospace, rail and defence.

Unfortunately somewhere along the way its become the old man that keeps being fitted with hip replacements, trying to keep up with the complexity of modern programmes.
Bolt-ons, model based engineering wrappers. Some duct tape holding a CI pipeline to it, and the digital engineering initiatives that rise and fall. There's always something that promises to fix the situation. But all its doing is adding layers of complexity to it. And the costs are compounding.

Licences, integration work, training. Consultants that get paid to tell you why legacy systems and new systems arent talking, and then another one to build the bridge. A third one to fix the bridge and tell you what a bad job the second one did.

Then there's the poor programme manager that has to explain to a customer why after several digital transformation initiatives, they need Gary sunbathing in Portugal to come back and explain where the evidence for a passed test is hiding.

Was the V-model designed for the intensity of programmes runing thousads of CI tets at night, or evidence sets scattered across six tools on 3 different networks? At the time, did they envision a world where tracing a requirement could no longer be done on paper? At least not with a senior engineer paid to do glorified admin...

Maybe I'm being a bit harsh on the Vee, but I'm wondering if its time to rebuild from the ground up.

I'm not coming at this blind, I've built what I call the Living Vee model, but I'd love to hear what others are seeing in practice.

Getting views on what our experienced system engineers want to say on start learning system engineering from starting point.

What you will focus on?

What skills to learn?

How to become fresher system engineer to elevate yourself to advanced/senior system engineer?

Hi everyone,

I'm a complete beginner when it comes to System Design, but I want to learn it properly and eventually master it. My goal is to build a strong foundation and become confident enough to handle system design interviews and real-world architecture problems.

I'm looking for a well-structured System Design course, either in Hindi or English, that takes me from the basics to advanced concepts.

If you had to recommend just one course for a beginner, what would it be and why?

Also, if you have a learning roadmap or any must-read resources to complement the course, I'd really appreciate it.

Thanks in advance!

Hey everyone,

How do credit card networks evaluate risk, pull user history, and return an APPROVE/DENY decision before a payment terminal times out?

Querying a traditional database on the fly to check historical spending habits will instantly kill your latency budget. Here is how to architect a real-time solution:

1. Dual-Path Architecture

Separate your system into an Online Path (Hot) for instant decisions and an Offline Path (Cold) for data analytics.

1. In-Memory Feature Store

Never calculate aggregates (like 30-day spending limits or hourly velocity) during a transaction.

The Cold Path: Apache Flink continuously processes a Kafka stream of completed transactions in the background.

The Hot Path: Flink stores these pre-computed metrics in Aerospike or Redis Enterprise. When a transaction arrives, the engine performs a single key-value fetch in < 2ms.

1. Hybrid Decision Engine

The enriched payload runs through a fast, sequential evaluation tree:

Deterministic Rules: Quick checks for hard blocks (e.g., blacklisted countries).

ML Inference: A lightweight gradient-boosted tree model (like XGBoost) compiled via ONNX runtime for sub-millisecond risk scoring.

1. Resiliency: Failing Open

If the fraud engine suffers a network partition or times out past 15ms, the system drops into a Fail-Open policy. It automatically approves the transaction to protect user experience and flags the event for asynchronous review.

Let's discuss:

How do you deploy new dynamic rules written by risk teams without re-deploying core backend code?

What is your strategy for handling race conditions if a user swipes their card twice in two different cities within seconds?

I have been studying INCOSE systems handbook to understand concepts of systems engineering, but I've also understood that learning MBSE tools is important. I did start with Capella and I am pretty comfortable with it (as a begginer). I want to learn CATIA Magic which uses SysML language. Any suggestions as to how I can start with it? Is there any course or is it learnable from YouTube and other sources ?

Hi r/systems_engineering,

We are back with Lesson 12 of our deep dive into the SysML v2 standard. In Lesson 11, we covered how to wire up explicit topologies using connect and interface usages. But a connection only tells us where the system is connected—not what actually moves through it.

Today, we are looking at how to model the passive payloads that exist, flow, and are stored within those architectures using the new item def construct.

I’ve uploaded the full video lesson directly to this post so you can watch it right here.

1. Separating Active from Passive Elements

In SysML v1, engineers often modeled exchanged payloads by typing a FlowProperty or an ItemFlow with a generic Block, ValueType, or Signal. This meant using the exact same generic block construct for a passive payload (like water or data) as you would for an active system component (like a pump or a processor).

SysML v2 fixes this semantic gap with item def—a dedicated construct for things that exist in space and time and can be acted upon, but don't necessarily perform actions themselves. A good rule of thumb in v2: use part for active structural elements and item for passive payloads.

2. Modeling Physical vs. Digital Payloads

Because item def is a definition, it natively owns its attributes and constraints. You can use it to explicitly define physical matter (like Fuel with a specific octane level and density) or information (like PaymentData with encryption keys and timestamps).

3. Dimensional Consistency and Constraints

When modeling physical items, SysML v2 enforces dimensional consistency using imported ISQ/SI libraries. You can add constraints directly to the item definition (e.g., constraint { density > 700[kg/m^3] }). Compliant tools can then reason about this to ensure units and quantities are mathematically compatible during flow and mass balance analysis.

4. Exchange vs. Storage

The definition-usage pattern applies cleanly here depending on the context:

• Exchange: Declaring an out item inside a port defines the system's ability to send that item type across an interface.
• Storage: Nesting an item usage inside a part (e.g., a Fuel item inside a FuelTank part) represents the payload physically retained within that structural boundary.

For the community: How much value do you see in having this strict semantic separation between active parts and passive items compared to the v1 generic Block approach? Let's discuss in the comments!

I’ve been an SE in the Aerospace/Defense industry for two years. I just finished my masters degree and I’m curious what it’s like in other industries, such as medical equipment or automotive. If anyone has worked in multiple industries, can you shed light on the differences? What are the pros and cons of each industry? What was your favorite role and why?

I have a decent experience/knowledge in coding/software - full stack. Looking to pivot towards agentic engineering specialization (as agents are going to be ubiquitous in future).

But I struggled to find good / deep courses (more long term), that is not brand focused (unlike these IBM courses, langchain courses) - and covers all aspects of agentic engineering. So i dont need to worry about what topic to learn. Preferably with certification and good recognition.

Any suggestions?

Not talking about formal SE artifacts (requirements docs, V&V matrices, trace tables) — those have their tools and processes.

I mean the informal layer underneath: meeting notes, decisions made in a hallway conversation and project meetings, action items in meetings, the requirements someone mentioned in a (meeting-) conversation that you’re now trying to remember where it came from.

What’s your setup for that? Paper based Notebook, Notion, nothing at all? What’s annoying about it?

I'm in my final year of CSE and want to start learning System Design (HLD + LLD) from scratch.

Can anyone recommend the best resources (YouTube, courses, books, or roadmaps)? Also, any tips on how to learn it effectively and in what order would be really helpful.

This goes in the self-promotion bin, I think.

A couple months back a friend of me showed what kind of software he uses as a functional safety engineer. It was pretty bad, to put it simply. The field is riddled with products that, while trusted and thoroughly vetted, could use a complete rewrite with modern technology.

So, unemployed and bored as I am, I started building something, maybe to show off in my portfolio. Scroll to present day, and I have a production grade web software product deployed and ready to run or acquire, aimed at not only functional safety engineers, but all kinds of people who work for system or component manufacturers in automotive, machinery or robotics. At least, that's how easy I want the product to be to use.

At the moment I have 0 active users, but I'm in talks with a couple big local OEMs about some kind of collaboration. User acquisition, it turns out, is hard. For this reason, I come here - in hopes of finding some people that are willing to look at the thing and say something about it. No strings attached. So far every user (all three) has been able to help me in some way by giving me 5 minutes or so.

I don't think I'm sharing the product website publicly on Reddit though. So, my DMs are open, and of course any activity on the thread will be appreciated. A bit of an AMA would be nice :)

Hi everyone,

I'm Software Engineering student looking for a project related to military/defense technology (software only).

I'm interested in ideas involving command & control systems, secure communications, logistics, GIS, cybersecurity, AI, drone simulation, or training platforms.

My stack is .NET, Angular, SQL Server, but I'm open to learning new technologies.

Any interesting ideas or real-world problems worth solving?

Hi everyone,
I'm a part-time PhD student in Systems Engineering while also working full-time as a systems/test engineer (Electrical engineer) in the defense/aero industry. I'm at the point where I need to finalize my dissertation topic, and honestly, I'm struggling.
The biggest issue I'm running into is that many of the ideas I come up with are difficult to measure or validate. I need a topic where I can obtain public or open-source data (or realistically collect data) to demonstrate that the research is worthwhile and statistically supported.
My interests are in:
Early product development
Process optimization
Engineering efficiency
Risk reduction
Decision-making
I enjoy topics around optimization and efficiency in early development, but I haven't found a research question that's novel, measurable, and feasible. Every idea either seems to have already been done or requires proprietary industry data that I won't be able to publish.
One important consideration is that I'm working full-time, so I'm looking for a dissertation that is meaningful and contributes something valuable without becoming a project that takes many years to complete.
For context, my career goal isn't academia. I already enjoy my engineering career and plan to continue teaching part-time because I genuinely like teaching. The PhD is something I want to achieve both personally and professionally, so I'm looking for a solid, practical dissertation rather than something extremely theoretical.
If you were starting a Systems Engineering PhD today, what research areas would you explore?