233
Integration in Systems Engineering Context
systems). Every problem needs to be thought of as a system; every stakeholder is considered as a system or system of systems; every solution reflects
not only the problem with which it is matched, but also its implementation
as a system or system of systems. Systems engineering exists only if its
implementations can result in the integration of its artifacts into the requisite
product or service.
No single discipline has developed the tools to engineer multidisciplinary
products or services. Systems engineering is more than engineering. Systems
engineering is the nexus of bringing together the variety and breadth of disciplines and fields required to accommodate the needs and priorities of
objects (e.g., people, organizations, and the environment) put at risk during
the product’s or service’s lifecycle. Each object put at risk has a stake in the
lifecycle of the solution and are referred to as stakeholders. Stakeholders
may be key stakeholders who impose requirements or are affected directly
from the building, delivery, or use by the primary users. By definition, all
stakeholders have needs that can be expressed as requirements. But nearly
all stakeholders are undeterminable at the onset of the work, that is, the conceptualization that eventually will result in a set of requirements that will
drive systems engineering and integration will themselves help expose
additional stakeholders and new requirements. It is the role of the systems
engineer to elicit requirements, and by doing so identify the hundreds of
people, organizations, and situations that will be affected by the proposed
system over the system’s lifecycle.
Lifecycle Considerations
The allure of using systems engineering for solving vexing problems is
determined to a great extent by three issues: (1) how comfortably the solution
reflects lifecycle needs; (2) the broader context in which the design is considered to have utility; and (3) the flexibility to incorporate cross-disciplinary
views. These three issues are captured in a lifecycle thinking in systems.
Lifecycle needs are often mentioned in the same vein as low-cost solutions
that deliver high performance. Yet the realities of development within the
constraints of budget and schedule often imply and impose “hidden” requirements on the system design and architecture. These hidden requirements are
likely visible during the product or service lifetime, and are indeed traceable
to the original specification documents. Specifically, the requirements indicate
what the stakeholders need to solve their problem. Specifications are written
by the project team to guide the project work. And while the specifications
embody the letter and spirit of the requirements, the interpretation of these
specifications and the decisions made by the individual engineers may result
in more or less than what was stated in the requirements. Sometimes these
Integration in Systems Engineering Context
systems). Every problem needs to be thought of as a system; every stakeholder is considered as a system or system of systems; every solution reflects
not only the problem with which it is matched, but also its implementation
as a system or system of systems. Systems engineering exists only if its
implementations can result in the integration of its artifacts into the requisite
product or service.
No single discipline has developed the tools to engineer multidisciplinary
products or services. Systems engineering is more than engineering. Systems
engineering is the nexus of bringing together the variety and breadth of disciplines and fields required to accommodate the needs and priorities of
objects (e.g., people, organizations, and the environment) put at risk during
the product’s or service’s lifecycle. Each object put at risk has a stake in the
lifecycle of the solution and are referred to as stakeholders. Stakeholders
may be key stakeholders who impose requirements or are affected directly
from the building, delivery, or use by the primary users. By definition, all
stakeholders have needs that can be expressed as requirements. But nearly
all stakeholders are undeterminable at the onset of the work, that is, the conceptualization that eventually will result in a set of requirements that will
drive systems engineering and integration will themselves help expose
additional stakeholders and new requirements. It is the role of the systems
engineer to elicit requirements, and by doing so identify the hundreds of
people, organizations, and situations that will be affected by the proposed
system over the system’s lifecycle.
Lifecycle Considerations
The allure of using systems engineering for solving vexing problems is
determined to a great extent by three issues: (1) how comfortably the solution
reflects lifecycle needs; (2) the broader context in which the design is considered to have utility; and (3) the flexibility to incorporate cross-disciplinary
views. These three issues are captured in a lifecycle thinking in systems.
Lifecycle needs are often mentioned in the same vein as low-cost solutions
that deliver high performance. Yet the realities of development within the
constraints of budget and schedule often imply and impose “hidden” requirements on the system design and architecture. These hidden requirements are
likely visible during the product or service lifetime, and are indeed traceable
to the original specification documents. Specifically, the requirements indicate
what the stakeholders need to solve their problem. Specifications are written
by the project team to guide the project work. And while the specifications
embody the letter and spirit of the requirements, the interpretation of these
specifications and the decisions made by the individual engineers may result
in more or less than what was stated in the requirements. Sometimes these