I've attended several presentations, conferences, and workshops on Systems Engineering over the last few years, it always seems that there is someone new to the practice that wants to know what Systems Engineering is. Many people struggle with the typical definitions as many can not avoid using the words "System" or "Engineering" in the definition making a clear understanding even more difficult.
The recent CIMdata PLM Road Map 2013 conference included presentations on the topics of Systems Engineering and Model-Based Systems Engineering (MBSE). There was discussion about how to define Systems Engineering and what tools are being used. It became cloudy when it was suggested by one presenter that some engineers might actually be performing systems engineering and not know that is what they are doing!
It is often assumed that for Systems Engineering to be required, the problem must be multi-domain (not true) or use one of those abstract block-diagram based tools (also not true). It was suggested that the most significant aspect of taking a Systems Engineering approach was if the product's development started from the highest level (what we would call the system) to meet the performance requirements and the sub-systems and, ultimately, components were developed to a cascading set of requirements down from the highest level. Contrast that approach with starting from components and sub-components (the lowest levels) and integrating them into sub-systems and further integration into the product at the highest level. This can be summarized as a Top-Down (MBSE) approach versus a Bottom-Up (Integration) approach. Put this way, it should be far more clear what the real differences in the approaches are. It should also be clear that these approaches are not dependent on what tools are being used: either approach could be conducted with a single tool (in a CAD tool for instance) or with multiple tools being used.
I'm a very visual thinker, so I spent some time thinking about how to communicate this in a graphical way. I developed the figure below to (try to) help illustrate the approaches with my example the Stabilizer System I indroduced in an earlier post (Am I the Only One That Thinks This Way? Conceptual Engineering Example):
Figure: Top-Down vs. Bottom-Up
With the Top-Down approach, the Requirements and the System are considered first. Simple, conceptual geometry that only attempts to capture the engineering content (I call these Engineering Models) would be developed. Within the geometry creation tool (likely to be 3D CAD) preliminary packaging, mass, kinematics, load-path studies etc. could be assessed if required. Additional abstractions and representations of the system and the concept(s) would be modeled (in this case a dynamic performance model and a structural analysis model) in such a way that the simulation results directly address requirements. Ideally, multiple concepts would be developed to maximize the opportunities to explore the design space and best meet the requirements. The promising concepts should be matured by increasing the fidelity of the models and development the sub-systems to the cascaded requirements. When it is appropriate, detailed design activity (CAD models and production software code) should commence, but only when the requirements are well established.
The Bottom-Up approach starts with much lower-level components being developed and integrated into higher-level sub-system models or assemblies. More components at the lower-levels will need to be created before analysis can be conducted and the simulation results may not address the product's system-level requirements. If much of the development on physical components is occurring in a CAD system, the enforcement of a "product structure" may limit the flexibility to create multiple concepts. The bottom-up approach not only requires many more components to be created at lower-levels early in the development process, the work-flow often encourages premature refinement of those components before their impact on the system-level performance can be made. If the system architecture is relatively simple or does not differ significantly from and existing design, this is not an issue at all and more effort can be spent on maturing the design of the components, solving integration issues in context, and performing parametric sensitivity and optimization studies.
The Top-Down approach typically allows for many more concepts and studies to be conducted with greater flexibility in selecting the appropriate tools for simulation resulting in a faster development cycle while raising the probability that the product meets the performance requirements. Bottom-up approaches will work best when the designers and engineers can work together very fast and when the simulations that need to be conducted are either integrated or at least highly associative.
With this as background, you may be performing Systems Engineering if you are developing the product by starting at the product level requirements (top) and continually assessing performance and driving the design into lower levels (down). If you are working initially from components (making parts and assemblies) first (bottom) and combining the various portions of the maturing product (up) then you are likely Integrating the product to a finished state. I hope this helps.