231
Integration in Systems Engineering Context
systems sociologist who recognizes behavior patterns as symptomatic of
structure and processes, the systems psychiatrist who sees integrative medicine as more effective (Lake 2007), and the systems mathematician who
appreciates the equal sign as signifying relations rather than equality.
Systems and Engineering
To engineer and build a system means to know what it takes to define a system and to make a system. But just defining and building a system are insufficient in the main to deliver the system that is needed and will be used.
Defining a system is inadequate if the stakeholder needs do not address the
real problem (as opposed to merely addressing symptoms of the real problem). And, building a system that merely addresses symptoms of the real
problem only frustrates users, as much time and expense is wasted dealing
with symptoms. A common example is purchasing medicines that placate the
common cold. They do virtually nothing to cure the ailment, but only ameliorate the symptoms. We feel both frustration in not being able to do what we
want to do and misery which accompanies illness. Defining a system that is
needed is the first stage of systems engineering work. Some people know they
have problems and also have the wherewithal to ask for help. Their needs
may be sufficient to warrant paying someone to push technology and incorporate it into a product or service. Even if the needs are sufficient, such a product or service may be unobtainable. Systems engineers are skilled in thinking
in systems and engineering to work alongside those people who have the
needs to solve complex problems. Key stakeholders are those who represent
the totality of the people who have various needs associated with the product
or service that is to be built by systems engineers. The stages of work are
stated generally and simply as (1) describing the problem in sufficient detail to
manage the development effort; (2) designing a set of alternative solutions
that reflect the functionalities that are wholly responsive to solving the problem within the limitations of budget and schedule; (3) architecting the artifacts to be consistent with the various relations and performances; (4)
developing and integrating the one solution that is consistent with the requirements, specifications, constraints, and conditions imposed by the system
boundaries, boundary conditions, skills, technologies, and policies; (5) verifying that what was conceived and built as the system solution indeed
matched the requirements and specifications of the stakeholders; and (6) validating that the delivered system solution satisfied the stakeholder needs in
solving the defined problem. The systems engineering development process
is highly interactive, sometimes rigorously recursive, and necessarily iterative. It is highly interactive because multidisciplinary teams of people and
subject matter experts are called on to participate; it is rigorously recursive for