251
Integration in Systems Engineering Context
years, from manufacturers on opposite sides of the globe may not be tightly
coupled situations; however, there may be a commonly practiced design
flaw, a set of parts with similar heritage, or a particular method and approach
to installation or testing that masks a potential problem. The categorization
of such a problem would be “uncontrollable acceleration.” Actual cause(s)
under investigation, perhaps, will never be known.
Problem Domain Analysis
Over the lifecycle of a problem, some things or people are affected and they
reside within the lifecycle boundaries of the problem, while others remain
outside those boundaries. Those within the lifecycle boundaries are termed
as stakeholders (lifecycle stakeholders). Whether the problem domain is
characterized as nested, hierarchical, or like kind, the domain will involve
stakeholders. As with systems engineering, an integration perspective relies
on defining the problem in a most important way: the problem stipulates the
solution. It is the role of the systems engineer and the systems integrator to
provide that solution. If the problem is ill defined, erroneously defined, or
undefined, the solution has no meaning. In other words, the work, resources,
and skills were misused. However, if the solution is defined in terms of the
problem domain, much insight is gained into the type of problem that needs
to be explored to define the problem with which systems engineering and
systems integration must deal.
The usual early work in systems engineering revolves around the triad:
stakeholder, problem, and need. A typical sequence is (1) ask the stakeholder(s)
what their needs are, surmise what the problem might be, discuss the problem to gain concurrence from the stakeholder, and then declare the problem
is (fill in the blank); ask the stakeholder(s) what their problem is, surmise
their needs, discuss their needs in terms of the problem to gain concurrence (or reach consensus), and then declare what the problem is (fill in the
blank); and have the stakeholder(s) tell their problem, what they need, reach
consensus, and then declare the problem is (fill in the blank). All too often,
very little time is spent on determining either what the problem is or what the
problem means. Defining the problem means more than just defining the
problem. Rather, defining the problem means exploring the domain of
the problem to determine what type of problem (nested, hierarchical, or
like-kind) needs solving.
If the discussion with the stakeholder(s) indicates a nested problem, then
the systems engineer needs to identify both the top-level abstraction and the
particular aspects of the nested set of problems that apply. Then, narrowing
down the applicable nested set will expose the causal problem that needs to
be addressed. As part of that analysis, conceptual solutions must be posed, a