In modeling your system is it possible to go beyond what’s called for? I would argue, yes and have defined the term: promiscutivity. That is, when the goal of productivity in your model goes so far that it becomes unrestrained (promiscuous). In other words, you have done more in your model than you ever needed to in order to satisfy the questions required for the project. This often happens because engineers are trying to achieve greater efficiency or output in their organization and don’t know when to stop. They haven’t paused to consider what they are asking in the first place. They start with good intentions, and go into the nth detail of their model structure, but then fail because they are not looking for a specific solution but rather modeling for model’s sake.  At some point you need to just stop and build it.

Of course there is some value to be gained when modeling just to document your system. But do you know why you are modeling? Did you already figure out the questions that you are trying to answer? If you don’t pause to consider these things, and just go on to model reality resulting in the minutiae of every detail documented, you will be frustrated at best, and lack productivity at worst. For instance, you can model the electrical output to need 120 Volts, and it will cause X resistance, and Y heat. But suppose your system isn't restrained by such details like specifying plane aerodynamics when taking off in extreme heat. You are only designing the aircraft's APU and don't care about the aerodynamic effects. In the end, does it really matter to your project? Is your system being impacted by the fact that this piece of data is in there or not? If the answer is NO, then it might be a waste of time.

Most people just want to know generalities about the systems they are building to start off. It’s only when focusing on some problem that’s happening that this kind of intricacy is warranted. If you have an issue, ask a specific question, and then get into the details that would help you understand the system effects on that issue. Once you understand what you are trying to answer then you can get into a simulation, and do an analysis against the part you care about. But if it has no affect on what you are trying to build, then scrap it. If you only need to worry about the thrust to weight then you can just put in SWAP (size weight and power) values to generate the appropriate output. Of course most system engineering is not at this level, but instead there are systems of systems, and the complex things they are trying to build. Reality says that you can’t figure out all of what you want to simulate without knowing something about the system you are trying to build. For example, a popular car manufacturer was designing a car to be aerodynamic so they would shut off the air flow to the engine compartment by shutting off the front of the vehicle. They built a prototype of the vehicle and tried this out only to find that their fuel efficiency went up. So they had to design a model to simulate what was happening. They found that by shutting off the air flow the vehicle would overheat and cause the AC unit to work extra hard causing the fuel consumption issue. They then modeled the heat distribution of the engine to figure out the optimal open/close routine to maximize aerodynamic effects and not overheating. The conclusion was their prototype was their first model which was reality. The model of the system didn't cause any further detail until they saw they needed to answer some question about the system. Now they will have that model in they system library to use in the future and not have to re-model this over and over. So, the key is focus. Focus on designing your system of systems, designing the pieces you care about, and answering the questions about which you need to go into depth, but not on everything.