216
Engineering Systems Integration
result is a presumed difference in management methods and systems engineering approaches to solve problems.
While these problems appear different due to the driving influences of
performance, schedule, or costs, they are most alike in many respects.
Performance-driven requirements rely on a collective of parties in opposition to achieve an “at will” consensus. In other words, a buyer (one who puts
forward a set of requirements) and a seller (one who proposes to satisfy those
requirements) come to an agreement on a proposed schedule and budget to
deliver various product or service performance(s). Systems engineering provides the thinking and the approach to establishing performance, cost, and
schedule trade-offs, in deference to the needs of the buyer and the seller.
With the approach carefully planned, the systems engineer originates tasks
that become the mainstay of the work for budgeting, assigning skilled
workers, and monitoring progress. The premise of the deal (e.g., contract)
is that two parties (at “arm’s length”: without conflicts of interest) agree on
the deliverables, progress milestones, payment schedule, acceptance criteria,
and methods.
In contrast, consider the firm that has an existing installed base of products or services or an infrastructure in use by its users (or customers). If the
seller determines that an economic advantage is possible through innovation
or changes in the functions (for example) for its offerings, systems engineering first sets out the objectives (i.e., requirements). The technical approach,
management supervision, progress milestones, and acceptable product or
service performance(s) are proposed by the systems engineers and, if acceptable, agreed to by the decision makers overseeing the activities supporting
the installed customer base. In both cases, the systems engineering planning
guides the development work to produce the desired product or service
performances. The results of systems engineering fall into two domains. The
subjective domain (i.e., the cognitive structures that provide planning, methods, and approaches; procedures that follow a model of steps that signify the
phase of work and the expectations for each phase; and models and representations of the results of planning and procedures, such as requirement
documents, trade-off analyses, and build-to specifications). The purpose of
the subjective domain is to engage engineers and subject matter experts to
work with the systems engineering plans to build and test physical entities
with the appropriate functional traits so that the users can exhibit the sets of
behaviors that effectively exploit both the physical entities and their resultant functions. Systems engineering takes subjective information and turns
it into objective properties, traits, and attributes. The process of transforming
knowledge into objects that work as a part or as a whole is integration.
Systems engineers deliver their most beneficial performance on problems
whose boundaries (physical, functional, and behavioral) reach well beyond
what is often presented in a set of requirements. Even a widely defined scope
of work may impact on systems of import unbeknownst to the buyer and the
seller. A review by a qualified systems engineer is most appropriate for any