Reqflow : pick an architecture (WhatsApp,
Uber, Netflix…), hit play, watch a request flow through it step by step. Click any component for purpose + tradeoffs. Kill the cache and watch the path change.
15 systems, 18 concept guides, a drag-and-drop Builder with AI review, and a timed Interview mode.
Feedback welcome — especially what's missing from the 15.
(I'm currently learning about systems engineering so pls do help me out with this little doubt!)
Like let's take a scenario where you are working on a complex engineering project (infrastructure, defence, aerospace, whatever your field). Things change constantly right? Maybe a component gets redesigned, a subsystem spec gets updated, a client changes a requirement, etc.
My question is: what happens next?
How do you figure out everything else that change affects? Which teams need to know? Which designs, specs, test cases, or schedules are now potentially invalid because of that one change?
From what I've seen and heard, this is usually handled through meetings, emails, and a lot of manual checking. Do things still get missed? like maybe this is discovered weeks later in a review or meet, so how do you handle it?
Also, is this a real problem in your work? How do you currently handle such cases, like how do you ensure everyone is updated on the change and needs to work accordingly? Is this a tedious task or has anyone found a good system that actually works?
I'm doing a benchmarking study on SYS.1 requirements elicitation practices. The frustrating thing: three metrics that are referenced in ASPICE and systems engineering literature have no published benchmark values anywhere. No IEEE paper, no industry report, nothing. So I'm trying to collect primary data directly from practitioners.
The three metrics - phrased as simply as possible:
How much does one customer requirement expand?
If a customer says "the vehicle must detect obstacles" and your team writes 12 engineering requirements to cover that, the number is 12. What's typical on your projects? (Your company might call this decomposition ratio, elaboration factor, RER, or something else.)
How fast does your team work through requirements?
Across the full requirements phase - elicitation, documentation, reviews, negotiation, baselining - roughly how many customer requirements does one engineer finalise per working day?
How stable are requirements after sign-off?
Out of every 100 requirements that get formally agreed and baselined, how many get changed during the rest of the project?
Context that might affect your answer: ASPICE capability level, domain (automotive, aerospace, defence, medical devices), project type (new platform vs derivative).
I'm not fishing for exact numbers - rough estimates from experience are completely valid and will be labelled as such. Even a "we don't track this but it feels like X" is useful.
If you're willing to share a few numbers in the comments, brilliant. If you'd prefer a more structured format, I have a 10-question form that takes about 5 minutes - DM me and I'll send it over.
Findings will be shared back with anyone who contributes, anonymised and aggregated.
TL;DR — No published benchmark exists for requirements elaboration ratio, elicitation throughput, or post-baseline change rate in automotive/embedded/safety-critical domains. Collecting primary data directly from practitioners. Three numbers in the comments is all I need
Hi everyone, I’m a recent EE graduate and just landed an Entry level Systems Engineer position at Lockheed Martin. They’ve offered me roughly $80k, and I wanted to ask if that’s the best I could get as someone who just got into the field or should I go and negotiate for a little bit more?
I’m very new as to this is a big next step in life. I appreciate any help I can get! Thank you in advance!
My team is all software engineers and testers. The closest thing we use that resembles good systems engineering is gitlab issues.
The customer refuses to fund systems engineering practices or dedicated systems engineers. I have the support of management, but no bucks, no Buck Rogers. The customer wants us to "think big, move fast".
What are some approaches I can take to pitch the benefits of MBSE and systems engineering in general to the customer?
I have a masters degree in SE from the company but they are getting 0% ROI on it because I'm stuck maintaining Kanban boards.
Anyone know a good iPad app for remote development? Need something with multi windows feature (Stage Manager), SSH, a decent code editor, and ideally some git support. Tired of switching between 3 different apps.
For those who have worked in both software engineering and MBSE/systems engineering: do you feel that MBSE is more resistant to automation by AI/LLMs than traditional programming roles?
My background is in software engineering, and I’m considering pursuing an M.S. in Systems Engineering. One factor I’m thinking about is long-term career stability. My intuition is that MBSE and systems engineering rely more on domain knowledge, requirements analysis, architecture, and cross-disciplinary communication, which seem harder to automate than writing code.
For engineers who have done both, do you believe MBSE is genuinely more resilient to AI disruption, or do you think AI will impact both fields similarly over the next 10–20 years?
TL;DR:
Agentic AI doesn’t “do systems engineering for you,” but it can seriously speed up the boring parts if it’s tightly scoped to the right tools and workflows.
Key takeaways:
https://blogs.mathworks.com/simulink/2026/04/26/model-based-systems-engineering-and-agentic-ai/
Hello all,
I just finished my masters in systems engineering and wanted to make a post to see as me and my wife wait a year, what topic should I do? I know I want it to be about governance and using AI models for SE workflows but need to pinpoint that as my mind scrambles a bit. I’m picturing on doing some ground work before going head first while I take a year off. Did anyone of you while waiting before heading back ever think out your research topic or just waited and enjoyed your time haha? Is there anywhere I can see current topics to start brainstorming?
My resume: I have a bachelors in EE and a masters in EE focusing on VLSI.
I got hired on to a Big Tech company as a "design engineer", but there was 0 design to it. It was a weird-ass role custom built by one manager, but it was kind of like systems engineering. The biggest part of it was meetings with stakeholders where I drove some high-level requirements and documented action items. They laid me and my manager off after 3 years and sent that job to India.
After that, I ended up at an aerospace company working as an actual systems engineer. I've spent 2 years here, and so far, my primary job skills have been copy/pasting screenshots of other people's work into a Powerpoint deck, and copy/pasting values from an Excel sheet into a Word sheet. I shit you not, I have literally worn the paint off of the C and V keys on my desktop.
I'm getting frustrated with these zero skill growth, low value add, copy/paste bullshit jobs, and wanted to get back to technical work like design.
Here's the thing... I've got a couple technical job interviews, and they have gone BAD. After 5 years of writing Powerpoints, and 0 years doing design, I'm getting smoked the fuck out. When they start drilling down into how I would bring up a PCB, it becomes pretty apparent that it's been half a decade since I've handled a PCB.
So I want to be technical, but I have zero chops to be technical. Those skills have just eroded.
At this point... do I just lean into the documentation skid, and start asking my boss for opportunities to start learning project engineering / program management? Do some similar kind of work to what I'm doing, but more transferrable and higher-value? Does it get better than copy/pasting?
Or do I just act like I'm a fresh grad, enroll in some online graduate classes (they cost about $3k a pop, and I'm not sure my current job would pay for them b/c I already have a masters), build PCBs or something as a side project, and try and re-launch a technical career from square one.
Hi r/systems_engineering,
I would like to ask for feedback on a problem that I suspect many systems engineering teams will face more often as AI tools become normal in engineering workflows.
AI can generate engineering artifacts much faster than organizations can make those artifacts trustworthy, accountable, and usable for decisions.
By “artifacts,” I mean things like:
- draft requirements
- interface assumptions
- architecture options
- verification plans
- test ideas
- risk lists
- change impact notes
- summaries of stakeholder discussions
These outputs can look polished. They can even be directionally useful. But in a systems engineering context, that is not enough.
Before an artifact can support a real engineering decision, we still need to know things like:
- What exactly is being claimed?
- Which operational scenario or context does it apply to?
- What evidence supports it?
- What assumptions are embedded in it?
- What trade-off or value criterion is being used?
- Who is responsible for approving, rejecting, executing, or reopening the decision?
- How does it connect to requirements, verification, and validation?
- What would cause us to hold, rollback, or escalate?
This seems to be where a lot of AI discussion becomes too shallow.
The hard part is not only generating more text, models, plans, or code. The hard part is turning those outputs into something that can survive engineering review, organizational accountability, and domain validation.
In other words, AI makes generation cheaper, but it does not remove the cost of judgment.
I do not think this is just a prompt engineering problem. It feels closer to a systems engineering problem:
How do we manage the state of knowledge around a system so that generated outputs, human claims, evidence, decisions, validation results, and operational feedback can be inspected together?
For example, suppose an AI assistant drafts a requirement or proposes a change. In a software-only workflow, we might ask:
“Does the diff pass the tests?”
But in a systems engineering workflow, that is not enough. We may also need to ask:
- Was the stakeholder need understood correctly?
- Is the operational scenario clear?
- Is this requirement actually approved?
- Is the verification method defined?
- Is the validation scenario defined?
- Is the AI agent or human implementer acting within an approved scope?
- Is there a rollback or reopen condition?
- Has the impact on neighboring requirements or interfaces been checked?
I am trying to understand whether this is a real gap in current systems engineering practice, or whether existing SE / MBSE / V&V methods already cover it well when applied properly.
One way I have been framing the issue is as “knowledge convergence”:
the process of turning generated outputs, human claims, documents, evidence, decisions, and operational feedback into a decision-ready knowledge state.
I have written an early draft/spec of this framing here, mainly to make the idea concrete enough to criticize:
https://github.com/sawadari/knowledge-convergence
Disclosure: this is my own early public work. It is not a mature standard, not a finished tool, and I am not selling anything. I am posting it here because I would especially like criticism from people who work with requirements, MBSE, verification/validation, safety, architecture decisions, or AI-assisted engineering workflows.
A few questions for this community:
Does “decision-ready knowledge state” describe a real problem you see in systems engineering work, or is there a better existing term for it?
Are existing SE / MBSE / V&V practices already enough to handle AI-generated artifacts, if applied properly?
Where would this framing break down in real engineering organizations?
What would be the smallest practical artifact that would make this useful: a decision ledger, a requirement-validation graph, an AI delegation envelope, lint rules for missing evidence, or something else?
I would appreciate blunt feedback. I am less interested in whether the terminology is perfect, and more interested in whether the underlying problem is real.
If the link makes this feel too self-promotional, I am happy to remove it and keep the discussion focused on the question.
I’m considering starting a master’s in Systems Engineering in the fall but I’m trying to figure out whether it’s a realistic path or a waste of time.
For context, I’m currently an Army helicopter pilot and will be retiring in about 2 years. I’m only mentioning the background because I’m curious whether it moves the needle at all for systems engineering roles, especially in defense/aerospace.
My main concern is that I spend 2 years on the degree and then find out I’m not competitive because I don’t have a traditional engineering bachelor’s. My bachelor’s degree is missing some of the math prerequisites for certain programs, so my options are a little limited.
I’m looking at Johns Hopkins Engineering for Professionals, Penn State, and possibly UMGC as a fallback.
For people already working in systems engineering:
Am I wasting my time pursuing this without an engineering undergraduate degree?
Would this background help at all, or not really?
Which programs would you recommend or avoid?
What entry-level or transition roles should I realistically target?
What salary range should I expect starting out?
Is defense/aerospace the best lane for this kind of transition?
Any honest advice is appreciated. I’m just trying to make a smart decision before committing the time and money. Can’t hurt my feelings.
Hi, pls help! I got the offer for SIT Infrastructure and Systems Engineering but idk if i should accept it cuz during my interview with them, they said it is very engineering heavy which ik cuz its an engineering course but my mom says that ppl who she works with that were in the course says that the course is not difficult and not so engineering...
for some background i did cyber in poly...and i lowkey wanna reject the offer cuz its engineering
but my question is could yall tell me more about this course and what yall actually learn. tysm!
Hi everyone, (sorry if this has been asked before, this is my first time visiting this sub and I’m happy to take it down if necessary)
I have a mechanical engineering bachelor’s degree and have been working as what I understand as a systems engineer for about 5 years. Maybe you can tell me if it doesn’t make the cut, or if it falls under another category
I was responsible for what I consider the “big picture” in relation to my company’s product. Integrating all components and subsystems into entire engine systems as a whole, creating the layout of all components in CAD and the associated full-assembly drawings, interfacing with customers to incorporate the requests and resolve issues, designing certain custom top-level components, working with manufacturing to resolve assembly issues, conducting test fits, signing off on engineering changes from a “layout” perspective, and more. I can provide clearer examples and details if needed.
Would you consider this under the category of systems engineering, or something else?
I have been searching for job opening to apply to, but noticed almost all the jobs I search for with the title of “systems engineer” are looking for someone with a programming/software background and not mechanical like me.
From what I’ve read on other threads here, systems engineering can mean many different things depending on the company and the product, and who is defining it.
Is there a way you recommend to find positions that actually relate to what I did?
Thank you for the help!
I've been doing backend / system design for a while and there's something about my own process I keep noticing that I'd love to hear other people's perspective on.
Whenever I'm sketching a new service or reviewing someone else's design, I'm constantly making calls based on rough estimates I'm pulling out of my head. "Postgres can probably handle ~5k QPS for this workload." "A queue here will smooth out the spike." "If this service dies, retries should cover us."
Some of those numbers come from benchmarks I actually ran once. Some are from a blog post I half-remember. Some are, honestly… vibes. The unsettling part is I usually can't tell which is which until prod tells me.
So I'm curious how other people deal with this. A few things I'd really like honest answers on:
Not pitching anything, genuinely trying to understand what people do. The more embarrassingly honest the answer the better — I have a hunch we all fake the confidence more than we admit, and it'd be kind of nice to normalize that.
What's the dumbest assumption you ever made in a design review that bit you later?
Hey everyone, I am contemplating advancing my heavily mechanical technical career with a D.Eng in Systems Engineering. I have a BS in Civil Engineering and MS in Engineering Management but most of my professional time (7+ years) has been spent in mechanical technical operation roles across Nuclear Propulsion Plants and Data Centers. I also have 3-ish years of MEP Project Engineering and I've recently started to pivot to more of a commissioning role with some systems reliability while also pursuing Mechanical PE.
My main reason to pursue SE is to stay relevant in the increasingly digital and data-driven engineering landscape. Systems Engineering really interests me, but I’m struggling to evaluate the ROI of pursuing it for my industry in particular: critical facilities & engineering operations. While I am familiar with some systems principles in industry, I have mainly found formal Systems methodologies to be more prevalent in aerospace, defense and manufacturing settings.
There are a lot of high-paying roles with “Systems” in the title, but the terminology across engineering and tech feels extremely broad and sometimes inconsistent. I’m trying to figure out what paths are actually worth pursuing versus titles that just happen to include the word “systems.”
Bottomline, my primary interests are in operational analytics, critical infrastructure systems reliability, and lifecycle management. From my perspective, many of these areas seem naturally connected to Systems Engineering principles, even if the formal SE terminology aren't always used directly.
Does anyone have ideas about the relevance of SE in critical infrastructure operations such as data centers, pharma, or related operational environments? Or does anyone have insights if there is a growing need for critical operations to adopt SE methods over traditional facilities engineering and maintenance approaches?
Hi All,
I am looking for an advice.
I am offered a role which i think i am a bit under qualified for. It aligns with what i want to grow into in the future which is MBSE domain.
In the interview, i really liked the team and what they do. I was asked to rate my skill level with Cameo. It was a very spontaneous question as the rating level can be subjective in everyone’s mind.
I feel like I overrated myself while I am just a starter for this tool. I think I did it because i was desperate for getting the job (while everyone is lol). Rest assured I have strong urge to learn and i think that’s the biggest reason I
thought to myself that its just a tool it can be learnt in few weeks. I have already enrolled myself in a formal training for learning this tool.
While i understand the concepts behind Sysml and UML diagrams, i have less experience actually practicing on Cameo.
Now they offered me the job and asked me to start on Monday. I am beating myself up that maybe I shouldn’t have overrated myself. Maybe i am dishonest but i had no intention.
So confused should i go on Monday or not!!!
Hello all,
I recently completed my masters in systems engineering. I currently work as a systems engineer with 6 months into my role and almost 2 years in my previous technical role that’s in the same niche as what I’m doing now. I want to get into consulting as a systems engineer which I know is a very small entry. How can I prepare myself to get into “management” consulting for systems engineering?
I graduated with a bachelors degree in natural resource management this past year and I’m finding out pretty quickly just how much experience jobs want with no really guarantee for good pay (job market looked way better when I swapped majors). I have friends that all went the engineering route and have great jobs right out of school. One of those friends in particular only has an associates in systems engineering and is making close to 80k. I initially started out in computer science but swapped fields but I’m thinking it may have been a bad choice looking back. Do you think it would be worthwhile for me to go and get an associates in systems engineering? For context I’m 24 and I’m starting to feel like I’ve fallen behind and I’m worried I’m gonna end up locking myself out of a good lifestyle if I don’t change career paths. I’ve always had an interest in technology but computer science just wasn’t for me.
Solo. Tired of using spreadsheets for everything. Made a tool that can keep track of stakeholders, ilities, requirements, and help make decisions and do concept selection. Would love feedback from people that do this sort of thing.
Any input appreciated.