Site problemsBefore considering the meaning of systems engineering, it is useful to reflect on the meaning of engineering more generally:Engineering is the application of science to develop, design, and produce logical and/or physical objects such as buildings, machines, or a computer program to fulfil l a desired need or to achieve an objective.So the object or goal of engineering is a design. For example, aerospace engineering is the application of physics, material sciences, and other science to design space systems such as launch systems and satellite systems. It is important to note that in most cases the engineer has no direct way to arrive at the design such as by a set of formulas that can simply be evaluated.Instead, he or she must create (or invent) and plan. Often, as the engineer works through each aspect of the design, multiple alternatives come to mind. In the case of a launch system, alternative booster configurations, internal payload adaptive configurations, materials selections and many other plausible solutions might be considered. Thorough engineers will trade-off the promising alternatives. That is, the engineer will first compare the promising alternatives by evaluating or assessing each, usually by analysis or test. He or she will then select one that meets the objective of the design and otherwise balances such factors as cost, producibility, and the design margin that accounts for uncertainties such as material properties and worst case dynamic loading on the structures. The engineer must also communicate their creation and plan to those who will build the system. The engineer therefore documents or specifies the design, often via drawings, parts lists, and step-by-step manufacturing instructions for hardware and such means as a use-case or an activity diagrams for software.To understand in more detail how systems engineering is different from other types of engineering such as electrical or mechanical engineering and why it is important to the success of a “military acquisition” program is not so easy for several reasons. 1.Systems engineering has evolved and continues to evolve as the systems that are to be engineered become more complex and engineering the systems becomes correspondingly more demanding. In particular, systems engineering for military space systems are evolving to keep pace with and support the evolving space systems acquisition policy. 2.The details of systems engineering is usually described in terms of the steps in a process flow diagram. But starting with a fully developed flow diagram describing a particular process can obscure why those steps have been found to be useful to achieving a system design.3.No single process has achieved universal acceptance. There are differences in the flow diagrams, terminology, and the specifics in the processes described in various textbooks, standards, and corporate policies. Thus starting with a particular process flow diagram can also obscure the steps that are common to most processes.Systems Engineering is especially appropriate for large and complex systems that require a formal process to control and manage cost, schedule, and technology. A formal process for system design is based on transparent processes and documented and traceable communications or interaction among the customers, users, engineers, and other stakeholders. To formalize the relationship between the customers or users and the engineers, systems engineering usually starts with the system technical requirements that drive the engineering design or response. The system technical requirements state the customers or users purpose for the system, i.e., what they need or desire the system to do. They also include the needs or desires of other stakeholders such as program decision makers and the constraints imposed by the environment which the system will operate – the natural environment and, in the case of military systems, the threat environment – and the interfaces with other systems. Through analysis, systems engineering seeks to define system technical requirements that completely and accurately capture the need and all other requirements and constraints such that compliance of the resulting system can be objectively verified by test or other means.To formalize the relationship between multiple teams of engineers, systems engineering focuses on allocating the system requirements to the system elements to be designed by each team. But before the allocation can take place, the systems engineer must conceptualize a system architecture, i.e., the definition and organization of the system elements that will act together to achieve the purpose of the system, i.e., to meet the system technical requirements. The system technical requirements are then allocated to each of the elements of the conceptual architecture to provide a framework for design.SystemsEngineeringprovides the technical foundation for an acquisition program throughout the acquisition process. Particularly in the early stages of an acquisition, the program seeks to assess the feasibility of addressing the user needs and the technology of potential solutions, and determine robust estimates of cost, schedule, and risk intended to result in a predictable, disciplined acquisition.
Site problems
Before considering the meaning of systems engineering, it is useful to reflect on the meaning of
engineering more generally:
Engineering is the application of science to develop, design, and produce logical and/or physical objects
such as buildings, machines, or a computer program to fulfil l a desired need or to achieve an objective.
So the object or goal of engineering is a design. For example, aerospace engineering is the application of
physics, material sciences, and other science to design space systems such as launch systems and
satellite systems. It is important to note that in most cases the engineer has no direct way to arrive at
the design such as by a set of formulas that can simply be evaluated.
Instead, he or she must create (or invent) and plan. Often, as the engineer works through each aspect of
the design, multiple alternatives come to mind. In the case of a launch system, alternative booster
configurations, internal payload adaptive configurations, materials selections and many other plausible
solutions might be considered. Thorough engineers will trade-off the promising alternatives. That is, the
engineer will first compare the promising alternatives by evaluating or assessing each, usually by analysis
or test. He or she will then select one that meets the objective of the design and otherwise balances such
factors as cost, producibility, and the design margin that accounts for uncertainties such as material
properties and worst case dynamic loading on the structures.
The engineer must also communicate their creation and plan to those who will build the system. The
engineer therefore documents or specifies the design, often via drawings, parts lists, and step-by-step
manufacturing instructions for hardware and such means as a use-case or an activity diagrams for
software.
To understand in more detail how systems engineering is different from other types of engineering such
as electrical or mechanical engineering and why it is important to the success of a “military acquisition”
program is not so easy for several reasons.
1.
Systems engineering has evolved and continues to evolve as the systems that are to be
engineered become more complex and engineering the systems becomes correspondingly more
demanding. In particular, systems engineering for military space systems are evolving to keep
pace with and support the evolving space systems acquisition policy.
2.
The details of systems engineering is usually described in terms of the steps in a process flow
diagram. But starting with a fully developed flow diagram describing a particular process can
obscure why those steps have been found to be useful to achieving a system design.
3.
No single process has achieved universal acceptance. There are differences in the flow diagrams,
terminology, and the specifics in the processes described in various textbooks, standards, and
corporate policies. Thus starting with a particular process flow diagram can also obscure the steps
that are common to most processes.
Systems Engineering is especially appropriate for large and complex systems that require a formal
process to control and manage cost, schedule, and technology. A formal process for system design is
based on transparent processes and documented and traceable communications or interaction among the
customers, users, engineers, and other stakeholders. To formalize the relationship between the
customers or users and the engineers, systems engineering usually starts with the system technical
requirements that drive the engineering design or response. The system technical requirements state the
customers or users purpose for the system, i.e., what they need or desire the system to do. They also
include the needs or desires of other stakeholders such as program decision makers and the constraints
imposed by the environment which the system will operate – the natural environment and, in the case of
military systems, the threat environment – and the interfaces with other systems. Through analysis,
systems engineering seeks to define system technical requirements that completely and accurately
capture the need and all other requirements and constraints such that compliance of the resulting system
can be objectively verified by test or other means.
To formalize the relationship between multiple teams of engineers, systems engineering focuses on
allocating the system requirements to the system elements to be designed by each team. But before the
allocation can take place, the systems engineer must conceptualize a system architecture, i.e., the
definition and organization of the system elements that will act together to achieve the purpose of the
system, i.e., to meet the system technical requirements. The system technical requirements are then
allocated to each of the elements of the conceptual architecture to provide a framework for design.
Systems Engineering provides the technical foundation for an acquisition program
throughout the acquisition process. Particularly in the early stages of an acquisition, the
program seeks to assess the feasibility of addressing the user needs and the technology
of potential solutions, and determine robust estimates of cost, schedule, and risk
intended to result in a predictable, disciplined acquisition.
