Now, discussions on system

engineering become very complicated due to the very broad mandate

of the discipline. The wide range of the
types of systems involved, the complexity and
the relationship of many engineering activities, and the relationships
with other disciplines throughout the entire
system life cycle, not to mention the
experience and the backgrounds of the people
who having the discussion. The ability to understand a complex subject such
as system engineering is greatly enhanced by
a solid framework within which concepts
can be considered. There are a number of excellent system engineering
standards available today that contribute to the elements of a
suitable framework, but each standard contains
complexity, terminology, in detail that itself
requires interpretation. The inter-level
for many students, for junior engineers, and
for project managers, therefore doesn't allow
the use of such standards as effective frameworks to
examine system engineering. For the remainder
of this course, we use a simple
framework which shows three main elements of system
of engineering, processes, that is the doing
element, management, the controlling
element, and tools, which support both
management and processes. These elements are placed
within the context of a fourth element called
related disciplines. System engineering
processes and tasks are dividing the life cycle stages within which they
typically occur. In this course, we
don't attempt to detail exhaustively all system
engineering processes. Instead, we concentrate on the intent and the main
aim of each phase within the system life cycle
and examine some of the likely techniques that may be used to arrive at that aim.
We place particular emphasis on the acquisition phase of
the life cycle as it is the phase during which
system engineering has the ability to have the
most impact on the system. Systems engineering management is an overarching
activity, responsible for directing the
system engineering effort, monitoring and
reporting that effort to the appropriate areas, and reviewing and
auditing the effort at critical stages in
the entire process. Later in the course,
we address briefly the major system engineering
management elements of technical reviews and audits, system testing evaluation,
technical risk management,
configuration management, the use specifications
and standards, integration management, and system engineering
management planning. The preeminent
position of system engineering management
in our framework illustrates that it's the key to the entire system
engineering effort. Now, many tools exist to assist system engineering
processes and management. These tools range
from techniques and methods through to system
engineering standards. Here we describe the most
popular tools and standards without repeating
information that might be contained elsewhere. Throughout the course, we
present generic process tools, such as the requirements
breakdown structure, the RBS, functional flow
block diagrams, have FFBDs, work breakdown structures, WBS, trade off analysis, and
PW simulation as
examples of tools that may be applied to the system engineering effort
for processes. We also describe the system
engineering management tools of standards and capability
maturity models. Now, there are many disciplines, both technical and
non-technical, related to system engineering, such as project management,
logistics management, quality assurance,
requirements engineering, hardware engineering, software
engineering, and so on. The relationship between
the related disciplines and the other fasts of
systems engineering, depends very much on the
discipline in question. Some, such as
project management, oversee the whole system
engineering discipline, while others, such as hardware
and software engineering, sit between systems
engineering management and the processes, and others, such as
quality assurance, sit alongside the system
engineering effort. We discuss these disciplines and the relation to
system engineering at the end of the course. All extent system engineering
standards and practices, extern processes that
were built around an iterative application of analysis, synthesis,
and evaluation. The engineering nature
of the application is critical to system
engineering processes. Initially, the analysis
synthesis evaluation loop is applied at the system level, and then re-applied at
the subsystem level, then the assembly level, and so on until the entire
process is complete. During the early stages, the customer is
heavily involved. Towards the end, the contractor
is made responsible, wanted by the customer. Forward to detail the
individual activities within the system
engineering processes, it's worth considering
for a brief moment the basic foundations that the analysis synthesis
evaluation loop provides. The concept's not complex, it's simply a good
sound approach to problem solving that's
applicable in any domain, but particularly fundamental
to system engineering. During conceptual design,
analysis investigates the business and stakeholder
needs and identifies the essential requirements of the system in order
to meet those needs. Analysis at the system level
aims to answers the what, how well and why questions that are relative
to system design. Analysis activities continued in throughout the
subsequent life cycle to help in defining the
low level requirements associated with the
physical aspects, the hows of the system. Depending on the
particular design phase, these requirements may be
grouped in accordance with some logical criteria that
makes them easier to manage, and then allocated to a
particular physical component. That is, the component
becomes responsible for satisfying those functions that have been allocated to it.
The allocation of requirements forms a description of
the system elements, and therefore assists in the process of
synthesis or design, that is answering
the how questions. Once the analysis activity
resolves what is required, as well as how well and why synthesis or design then
determines the how. Synthesis of the process where creativity and technology are
combined to reduce
the design that best meets the stated
system requirements. The term synthesis is more
appropriate than design in a system engineering
context because it hints at the evolutionary nature of
the design and development. Analysis has told us what the system will do and
how well it will do it, synthesis proposes
how to achieve this. Synthesis, of
course, is probably the most widely recognized role of a professional engineer. In
the early system
engineering process, synthesis is limited to defining the logical
design of the system, and then considering all of
the technical approaches. From this consideration, the
best approach is selected, and the process then moves
to the next level of detail. Later in the system
engineering processes, the selected design concept is synthesized further until a
complete design is finalized. If we completed analysis
and then synthesis, we have some candidate designs. Evaluation is the process of
investigating the trade offs
then between those designs. At the earliest time it's the evaluation between
requirements and design, design alternatives and making
the necessary decisions. But that process
continues throughout all stages of the system
engineering effort, ultimately determining
whether the system satisfies the original
requirements. Trade off analysis as well
of the tools available to the system designer
in performing evaluation of competing
requirements or designs. We discussed trade off
analysis in more detail later. The outcome of the
evaluation is a selection or conformation of the desired
approach to the design. Discrepancies are
also identified if they're applicable
and may result in further analysis
and synthesis as the synthesis evaluation
loop is closed. You've shown how the analysis
synthesis evaluation loop can be applied across all the activities in the life
cycle. This figure summarizes that by showing you in a visual way, how can be
applied iteratively to each of those activities. It finishes the introductory
presentations for Module 2. In the next module, we begin our more detailed
discussion of system engineering processes by examining the role of
requirements engineering and the major artifacts that are produced as the
system is developed.