232
Engineering Systems Integration
the planned revisiting of work previously attempted to reflect the newly
acquired information and knowledge for planning and staging new work;
and it is necessarily iterative to satisfy the persistent need to double check
the work, clarify issues, voice concerns, and fix what needs to be fixed so that
the cumulative work reflects the benefits of all the subsequent results.
Systems engineering can be extremely frustrating for a domain engineer,
expressly focused on these three habits that are inculcated in the systems
engineers thinking: (1) interactivity implies frequent, but not necessarily substantive, communications (often with nonengineers) to tease out subtleness
buried in the proposed concept of operations, or implied by requirements, or
ensconced as basic tenets of the problem statement; (2) rigorous recursion
exposes the misunderstandings and omissions typical of developing and
integrating something that has not be built previously; and (3) iteration
determines the eagerness to correct all problems and the tenacity to do the
right things so that the product can be built and delivered.
Charter of Systems Engineering
The charter of systems engineering is to create and express ideas and integrate components into systems that are referred to as products or services.
These products and services are most often presumed enigmatic or incomprehensible by some methods, means, or fields of study. Each domain of
study is built on the premise of boundedness, framework for measurements
and interpretation, and theory. The essence of systems engineering is to
unbound the seemingly bounded, broaden the concepts to beyond recognition, open the solution domain to include the ridiculous, and consider the
issues and problems in an abstract space rather than as they are posed or
presumed to be real. No other discipline or field carries with it that worldview. The rationale and purpose are clear to the systems engineer, but
enigmatic to others. Specialty engineers (e.g., mechanical, electrical, and
materials) often find dealing with systems engineers frustrating and annoying. Why discuss issues and factors that are not germane to the problem at
hand? Why spend any time on any issue that does not go to solving the problem? Why “waste” valuable effort on talking about solutions, when simple
trade-offs analyses will surface the salient relations from which to make
decisions? Why indeed? The roots of systems engineering supposed the
problem was either incorrectly defined, in which case the solution might be
perfect, but inappropriate to solving the needs of the stakeholders, or correctly defined, but all that was needed to solve the problem was unavailable
to those charged with solving the problem. The distinguishable difference
between systems engineering and other engineering disciplines or fields is
the context of the thinking—that of thinking in systems (always thinking in
Engineering Systems Integration
the planned revisiting of work previously attempted to reflect the newly
acquired information and knowledge for planning and staging new work;
and it is necessarily iterative to satisfy the persistent need to double check
the work, clarify issues, voice concerns, and fix what needs to be fixed so that
the cumulative work reflects the benefits of all the subsequent results.
Systems engineering can be extremely frustrating for a domain engineer,
expressly focused on these three habits that are inculcated in the systems
engineers thinking: (1) interactivity implies frequent, but not necessarily substantive, communications (often with nonengineers) to tease out subtleness
buried in the proposed concept of operations, or implied by requirements, or
ensconced as basic tenets of the problem statement; (2) rigorous recursion
exposes the misunderstandings and omissions typical of developing and
integrating something that has not be built previously; and (3) iteration
determines the eagerness to correct all problems and the tenacity to do the
right things so that the product can be built and delivered.
Charter of Systems Engineering
The charter of systems engineering is to create and express ideas and integrate components into systems that are referred to as products or services.
These products and services are most often presumed enigmatic or incomprehensible by some methods, means, or fields of study. Each domain of
study is built on the premise of boundedness, framework for measurements
and interpretation, and theory. The essence of systems engineering is to
unbound the seemingly bounded, broaden the concepts to beyond recognition, open the solution domain to include the ridiculous, and consider the
issues and problems in an abstract space rather than as they are posed or
presumed to be real. No other discipline or field carries with it that worldview. The rationale and purpose are clear to the systems engineer, but
enigmatic to others. Specialty engineers (e.g., mechanical, electrical, and
materials) often find dealing with systems engineers frustrating and annoying. Why discuss issues and factors that are not germane to the problem at
hand? Why spend any time on any issue that does not go to solving the problem? Why “waste” valuable effort on talking about solutions, when simple
trade-offs analyses will surface the salient relations from which to make
decisions? Why indeed? The roots of systems engineering supposed the
problem was either incorrectly defined, in which case the solution might be
perfect, but inappropriate to solving the needs of the stakeholders, or correctly defined, but all that was needed to solve the problem was unavailable
to those charged with solving the problem. The distinguishable difference
between systems engineering and other engineering disciplines or fields is
the context of the thinking—that of thinking in systems (always thinking in