Can confirm, any 'real world' engineering will use the NASA definition. The best way I've found to understand systems engineering is in how my org implements th

Can confirm, any 'real world' engineering will use the NASA definition. The best way I've found to understand systems engineering is in how my org implements them - a project has a systems engineer and a project manager working alongside each other. They have small overlaps but by and large, the PM is responsible for the non-technical management of the project whereas the SE is responsible for the technical management. This encompasses scope definition, requirements specification, system and subsystem interfaces, testing and verification regimes, etc. etc. They take the intangible requirements of the client and beat them into a robust series of defintiions that outline what the whole raft of pieces that must assemble together to perform that duty must do, and then also confirm it does indeed meet the client needs. Meanwhile, the PM makes sure the team delivers on time, within budget, with the right organisational oversights to confirm processes are followed, quality management is maintained, etc.