Abstract. This introductory tutorial provides an overview of Defense/Aerospace
Systems Engineering because that is the discipline which orchestrates development from
concept to fielding of systems of complex systems such as ships, aircraft, armored
vehicles, guided missiles, and satellites.
This free ancillary tutorial is intended to explain the initial source of the
author's experience and knowledge; the processes and methods that were adapted and
tailored to medical device development in automated compliance with the design
controls provisions of the FDA Quality System Regulation.
At the end of this tutorial is an opportunity to pose question(s) on this subject.
Return to IPPT/Concurrent
Engineering/Systems Engineering Page [Use a Return Link after any of the
listed subsections to quickly reach this option.]
The overwhelming importance of military systems acquisition has led to decades
of thorough consideration of appropriate procedures and application of
specifically directed tools. Systems Engineering is the primary approach,
further managed by a judicious selection of wording for the implementing
contract provisions (tailoring) for data items delivery of required,
"essential" information and quantity of prototype systems.
Tailoring is the reduction of planned deliverable project documentation
from potential worst case scope and scale to the necessary minimum; that is,
applying the Systems Engineering method to the new product development process
before it is applied during the project phases.
When required, government standards are intended to provide the benefits of lessons
learned on previous similar programs. General specifications for materials, parts,
processes, testing criteria, and project management apply to all programs. The
tailoring process intent is to streamline the acquisition by specifying results
rather than achievement methods to take advantage of suppliers experience and
Systems Engineering is directed as the overall management process, with the tasks
of developing design concept architectures and system requirements, assigning
technology to the system design concepts, performing project risk management, and
verifying that defined operational requirements are met by the developed system.
Unfortunately, the government may not systems engineer and tailor its own process
requirements completely, so conflicts can exist in and between some cited standards.
The benefits of tailoring can be prevented or undone by automatic, blanket
invocation as boilerplate instruction or by implicit referencing in subordinate
documentation without attention to maintaining an integrated approach. Another
effect of untailored requirements is a tendency to provide equal treatment to
both necessary and unnecessary specification statements such that fulfillment
of an important requirement may not be delivered by the contractor.
A definition of Systems Engineering (from MIL-STD-499A) is:
"the application of scientific and engineering efforts to: (a) transform an operational need into a description of system performance parameters and a system configuration through the use of an iterative process of definition, synthesis, analysis, design, test, and evaluation; (b) integrate related technical parameters and ensure compatibility of all physical, functional, and program interfaces in a manner that optimizes the total system definition and design; (c) integrate reliability, maintainability, safety, survivability, human engineering, and other such factors into the total engineering effort to meet cost, schedule, supportability, and technical performance objectives."
Some projects emphasize performance effectiveness while others seek cost
effectiveness. Systems Engineering judgment may suggest relaxation of selected
rigid requirements to obtain a system better balanced for fulfilling customer
While the specific tasks performed by individuals vary in accordance with
project tailoring, the underlying objectives for Systems Engineering remain
consistent. The Systems Engineer's primary goal is to ensure that requirements
documentation and resulting system design include all essential
elements of hardware, software, people, facilities, and data. To accomplish this
broad objective, the Systems Engineer must:
Understanding of the total system is essential to managing its development.
This usually requires communication with the customer and/or users, to ensure
both correct interpretation of each defined need and unambiguous wording of the
responsive requirement(s). You must know what the customer really needs
or wants, not just what you think was stated! If the requirements don't reflect
the needs, the customer is unlikly to be satisfied with the product.
When the Systems Engineering perspective is lacking during a development project,
system level performance goals receive significantly less attention from program
management than do the hardware item designs. On any complex project, very
effective communications must exist between Systems Engineering and System
Analysts for Software Engineering, hardware specialty design engineering, and
Systems Engineering management.
Accordingly, many complex military projects require that contractors provide a
Systems Engineering Management Plan (SEMP) which describes the proposed systems
engineering process as well as its management. The SEMP contains a general
definition of the proposed system and subsystem integration requirements, with
description of documentation and work tailoring for adequate fulfillment of
program peculiar requirements. It also contains a Critical Items List to
identify those items for which there is a substantial likelihood of project
Technical Risk, Schedule Risk, or Cost Risk. It is a structured overview of the
proposed technical work and frequently is required of each contractor early in
a development program for evidence of expected process knowledge.
The SEMP program planning section describes plan interrelationship with other
key program plans, the proposed approach to Project Risk Analysis (when a Risk
Management Program Plan is not required), Engineering effort integration, the
Contract Work Breakdown Structure (WBS), assignments of responsibility, planned
program and technical design reviews, Technical Performance Measurement (TPM),
control of the interfaces between the various system elements, control of
documentation and configuration management, and the plan for technical and
program administration tasks.
The SEMP process section describes the proposed approach to performing requirements
determination and their allocation, trade studies, design synthesis for optimization,
generation of hardware/software requirements/interface specifications, coordination
of engineering specialty plans, provision of information for tasks specified in other
program plans, and performance of many other anticipated Systems Engineering tasks.
The SEMP is updated as necessary to reflect program changes.
Subsumed by Systems Engineering, trade-off studies become the essential means of
determining best design approaches as well as selection of a system from alternatives
generated by the process. The following is an overview of the defense contractor's
approach to making systems development decisions.
Return to Table of Contents
A Work Breakdown Structure (WBS) is the hierarchical structuring of a system which
defines a program. The inverted tree format WBS divides a system into hardware,
software, services, and data. Composition of the WBS for a specific program is
a Systems Engineering function that relates the contract Statement of Work (SOW)
to the plans, schedules, and budgets necessary to provide the desired product.
The WBS sets forth the individual items that must be delivered to produce the
final system as its uniquely numbered elements. (The DSIDE™ process
Decision Model is like a simple WBS with relative priority levels assigned.) Several
types of WBS formats are used.
A WBS provides the benefit of a top-down structure for comprehension and
decomposition with alignment of tasks and both technical and management
accomplishment responsibility. Earned value project tracking techniques are
supported by a WBS. Progress and accomplishment are compared with scheduled
work performance objectives to obtain budget value credit or requirement for a
variance report with attendant project management interest and "help."
Return to Table of Contents
Most conceptual areas of technical performance are divisible into parameters or
attributes that you may measure or estimate. They usually consist of system
characteristics other than Cost. When a problem is decomposed within the System
Engineering approach, grouping of elements is in accordance with functional
relationship rather than with seeming similarities.
With many military systems, such performance parameters as operability,
survivability, transportability and supportability are critical considerations.
Almost all of the military concepts have civilian industrial analogues.
Transportability considers the system overall weight, volume, and mechanical
design characteristics such as handles or graspable surfaces, or which result
in a sensitivity to vibration, temperature, pressure, moisture or other
environmental conditions. This concept has direct application to proposed
civilian systems, if they are not manufactured in place of use, are themselves
mobile, or are otherwise moved from place to place. It is extremely important
to a Just-In-Time (JIT) manufacturing implementation, of course.
Producibility is the concept of ease, efficiency and economical system
manufacture. Because the system design concept affects producibility in terms
of simplicity and process variability, Systems Engineering must ensure that
production capabilities become part of the design selection criteria. A
production engineering analysis begins with an estimate of the production
capability required to fulfill program scheduled system deliveries. You must
know if you will have or can develop the necessary capacity, considering the
required process technology, facility, tooling, inspection, and people for
number, skills, and training.
It matters not how good a prototype appears, if you can't make the
product from the final design in the necessary quantity at near the target cost.
In the commercial realm, it is called production planning. In the military
arena, it is Producibility Engineering and Planning (PEP). These SEMP analyses
fit under the Total Quality Management (TQM) umbrella. (See the Continuous
Improvement Process tutorial for more on TQM.)
Finally, because all things come to an end, consideration must be given to
safe system disposal at the end of its life cycle. Design for recycling and
recovery of dangerous materials for hazardous waste disposal is part of the
Systems Engineering process with effect on commercial as well as military
Return to Table of Contents
Life Cycle Cost (LCC) encompasses the total cost of a system, from early
research and development costs through production, acquisition, logistics
support, and eventual disposal at the end of its useful life. Total LCC is
the most equitable way of comparing alternative project costs. Determining
the total cost requires the use of constant dollars and present value techniques
for estimating the particular cost quantity assignable to a defined period for
each system under analysis.
SYSTEMS ENGINEERING PROCESS:
Contractor programs often assign a Chief Systemss Engineer as the primary
technical authority to orchestrate the product development by Systems Engineers and
engineering specialists of system design documentation and audits.
Requiring specialists to report to the Chief Systems Engineer is intended to
assure uniform flowdown of requirements to functional subassembly designs.
This includes development of specialty testing requirements in an Integrated
Test Plan (ITP) or Test and Evaluation Master Plan (TEMP).
Return to Table of Contents
The goals of Functional Analysis are to provide comprehensive specification of
the purpose of all system, support and verification elements for all phases of
the system life cycle. The critical design interfaces and elements are
identified, along with suggested technical performance measurements.
Functional Analysis describes such activities as:
A Basic Input Analysis generally consists of a scrutiny of the available
documentation for system performance requirements, as well as some optional
"nice to have" features.
The operational concept documentation identifies where (both geographically
and environmentally) the likely missions will be accomplished. It includes
mandatory performance and effectiveness criteria along with the estimated
utilization factors for the prescribed life cycle under every anticipated use.
Performance metrics must be devised to provide the means to verify fulfillment
of critical requirements.
Assistance by other key disciplines, such as the specialties in Integrated
Logistics Support, Reliability, Maintainability, Human Engineering, and Safety
Engineering, may contribute some additional appropriate performance parameters
and value ranges. Further, their assistance in developing or at least their
review and approval of the derived requirements in subsystem specifications
incorporates necessary realism and applies a Concurrent Engineering approach to
developing the basic architectural concepts.
You use the Operational Requirements Analysis portion of a Functional Analysis
to complete definitions of system functional performance requirements, always
keeping cost effectiveness in mind for both operational and maintenance
concepts functions while evaluating alternative design approaches.
The object, maintaining direction set in the operational concept, is to establish
the what, where, when, and how for the system that will allow you to
synthesize a feasible preliminary design concept.
The completed definition of functional requirements provides a basis for
selection and design of system elements, with initial identification of areas
for trade-off studies and the preliminary system evaluation criteria. To that
end, the military development contracts often require that suppliers produce an
Integrated Test Plan which describes their approach and support systems
required for verification of requirements in accordance with the included
preliminary Verification Cross Reference Matrix/Index (VCRM or VCRI). Success,
after all, is determined by fulfillment of the identified requirements.
The allocated requirements are used to develop schematic block diagrams of
system concepts, with the object of defining modular functional units which
implement single, independent, logical and separately testable tasks. Desirable
attributes for a module are low coupling (interdependence or information
sharing), high cohesion or binding (within module task similarity), and low
connectivity (reference from internal elements of one module to the internal
elements of another) for simplest interfacing.
Although software adds no additional mass to system hardware (that is likely to
be overfilled with electronics beyond the program memory), it has become
increasingly expensive to develop and maintain. To rectify this problem,
software requirements traceability must be maintained and the development
proceed in a disciplined fashion just as for hardware. Requirements allocated
to software can wait longest to firm up, but must be stable from the user
perspective by time of Preliminary Design Review. Software must be designed
concurrently with the computer that will execute it, if the computer also is a
new special purpose development item.
Further, splitting off the software requirements definition task to a different
organization and managing the software development separately until final
system integration begins is a recipe for poor design regardless of purported
capability of Computer-aided Software Engineering (CASE) development tools or
the people employing them. It also violates the spirit and intent of Concurrent
When project management understands the value of its proper application, you
may develop a simulation model of the top-down decomposition to obtain the
required accuracy of performance effectiveness estimates within the functional
requirements for such decisions. Design alternatives may be examined in depth
from varying perspectives for their impact on performance effectiveness.
Validation of a Simulation Model is an additional difficulty, if that model is
not rigorously mapped to the system requirements. Your confidence in the model's
performance predictions should be proportional to its confirmed validity.
Project Management must assign adequate Systems Engineering resources to the
Functional Analysis task, else the temptation is to have specialty designers
do their own analyses. This breaks the connection to a common baseline as the
multitude of independent design decisions develop a form of bottom-up design.
If you cannot avoid doing this, the specialty designers should work as System
Engineers under technical direction of the project Chief Engineer for that task.
Preparation of Specifications is the formal documentation of system requirements
as preparation for the system design. Requirements in design specifications should
state the essential functions or what shall be accomplished with as
little preconception of how to do it as is possible, because that is
each specialty designer's job. In fact, it is best to assume that some internally
perfect and mistake-proof technology exists, without attempting to define it when
writing the initial set of requirements. This is extremely difficult to do when
reverse engineering a specific incarnation of a similar system because an imperfect
but existing solution is foremost in thoughts. Nevertheless, system level requirements
specification should be of low complexity and implementation independent (only specify
the functional essence of a logical model) except when retrofit is made to existing
interfaces in the system environment or incorporation of an existing design solution
is mandated by the customer. Customers and users seldom know how to state what the
system should do in requirements specification language, so the standard problems with
supplied initial requirements are:
Application of proper specification language is an art in itself, for avoidance
of ambiguity, redundancy, or impossible imposition (such as to a higher system
which cannot be controlled from the lower level). A critical point:
If a "requirement" cannot be verified, it is merely a string of
text which may or may not contain useful information.
A fundamental Systems Engineering task is to determine what the set of valid
requirements actually is; to understand customer requirements and to correct the
above listed deficiencies before proceeding with the system development. The only
"holes" remaining after developing the essential requirements are those
allowed as design decisions for implementation of the selected architecture. These
should be stated in lower level requirements documentation, of course. Maintain
traceability to the higher level requirements through paragraph number and title
equivalency or other simple control means, so justification of each
requirement is simultaneously maintained.
Another approach to requirement verification is to determine its necessity in the
first place. Have the author of each requirement document the reason for its
inclusion. Analysis of the rationale can reveal actual or near duplication,
design implementation, or erroneous assumptions. Reviews by novice people can
highlight ambiguities and other deficiencies. The ensuing deletion or rewriting
results in a more valid specification of the functional requirements and an
education for the authors. Systems Engineering interpretations of the requirements
become more defensible.
The four methods of requirements verification (in order of preference) are
Test, Demonstration, Inspection, and Analysis:
Callout of military, industrial, or company standards is to provide
minimum requirements for processes, procedures, and methods employed
in design and development of the system and subsystems specified. The Systems
Engineering responsibility here is ensuring that the procurement or other
specification requirements are all tailored, adequate, and traceable.
It is easy to grab the block of specifications and standards used on other
projects and assign them to new projects without tailoring to that minimum and
assigning order of precedence. Don't. Such overspecification is expensive,
requires conflict resolution, and limits design options to as few as no
feasible solutions that fulfill all requirements.
Return to Table of Contents
Another major Systems Engineering process task is Synthesis of Conceptual
Systems. Within this recommended methodology, the summary list of the major
system requirements and desired features is set forth in accordance with a
structure definition showing the attribute tree. Having that list and the
preliminary system specifications of the system functional essence, design
engineering groups or appointed architects can postulate feasible system
physical concepts as well as generate the associated subsystem hardware/software
and support concepts. Design concept synthesis should be performed concurrently
with Functional Analysis, to assure responsive concepts with the minimal set of
interfaces. This top level design begins to provide hows for the
requirements specifications along with a preliminary list for project Technical
The criteria for architectural concept designs are:
Engineering creativity in technology application as expressed in design studies
is balanced by the Systems Engineering process to generate an optimal concept
for fulfilling system requirements. Specialty designers provide technical
assistance to systems engineers, whereas the systems engineers review specialty
designs for requirements fulfillment. A high-tech or complex solution for a
simple manual process is not desirable:
Availability of a technology is insufficient justification for its use.
Research to identify candidate technical solutions to system design problems
is ongoing, so breakthroughs are possible even if unlikely. Usually, even when
subjected to Research & Development, the advances are small evolutionary
improvements because producibility of new technologies is unproven. Systems
Engineering at this stage is part of cost savings rather than an additional
Any attempt to schedule technology breakthroughs is risky, at best.
When system design must leave off-the-shelf adaptation and requires invention,
uncertainty becomes a major project driver and evaluation of the technical,
schedule, and cost risk is required. (See the Project Risk Assessment Tutorial.)
Understand, however, that most system designs are fallible in the sense of
not fully meeting all requirements. (Some may completely fail, in the worst
Return to Table of Contents
The next defense Systems Engineering process is Evaluation and Decision. You
employ trade-off analysis here, with output in a Trade Study Report. For
selecting a best mix of system elements, the DSIDE™ process assists your
evaluation of candidate system approaches. After you establish the decision
bases, that process virtually causes the best final decision through the
ranking of candidates in accordance with their net utility scores. Don't forget
Risk Assessment for the project technical, cost and schedule issues, so you
can take assessed risk level abatement or mitigation actions.
A decision process takes place under Evaluation whenever you perform design reviews
at critical points during the system concept development activity. You design to
match the anticipated system performance capability initial requirements. You need
to identify worst-case function input loading situations to determine if an overload
condition will exist. Functions which affect Availability or reaction time are
time-critical. Perhaps the throughput and output capabilities must be increased. This
is part of optimizing the system as an alternative to establishing its best use.
You should conduct formal design reviews at critical program milestones to
check for technical adequacy of functional schematic block diagrams, interface
specifications, requirements specifications, and for complete traceability of
the system requirements to determine that the resulting baseline design
actually will fulfill its specifications if built. The customer will be
conducting a preliminary validation as well, to determine if the system concept
will support accomplishment of the proposed mission needs, confirming that the
right system was defined.
Documentation presenting results of each review is in accordance with each Data
Item Descriptions (DIDs) called out in the contract or supplier data requirements
list (CDRL or SDRL). Technical reviews should not be instruction sessions, so only
appropriate and knowledgeable personnel should attend -- after having had adequate
time to study the documentation that will be presented.
Return to Table of Contents
The concluding listed Systems Engineering process activity is Description of
System Elements. An approved set of system level specifications that was
produced to fulfill the tailored program's Supplier Data Requirements List
(SDRL) is the resulting primary output documentation from this activity.
A system specification is the design baseline descriptor for translating all the
generated paper into tangible hardware and associated software. It contains an
explanation of what the system is, what it has to do, maximums of weight and power
required, accuracy, capacity, and so forth. Any qualified manufacturer could develop
the system or interfacing subsystem from the applicable design specification, if it
sufficiently sets forth the overview as well as key details. Where combined system
attributes affect any other performance parameter, the specification must address
that system performance requirement in section 3 and its method of verification in
section 4. This is true for every requirement at every level of system decomposition,
and insistence upon it keeps requirements statements verifiable.
The Interface Control Document (ICD) defines every interface from analog signal
level to digital control codes on a bus for electronic items but physical
interfaces are described as well. It can include facility descriptions for
exchange of models and define responsibility for verification of its content.
It does not duplicate the specification but describes the actual implementation
requiewd for fulfillment thereof.
When different contractors make equipment that communicates with each other,
both must agree on the definition in all respects. Upon signoff and placement
under configuration control, an ICD has the status of a deyail design specification
with respect to electrical and mechanical definitions.
Return to Table of Contents
Configuration Management, simply put, is being sure that you have what you think
you have for each Configuration Item. The baseline is recorded and all changes are
formally controlled with records maintained for audits. Each equipment is identified
for hardware configuration, such that the same complete part number of an item is
interchangeable with any other unit with the same part number.
Descriptive documentation, specifications, and schematics also must match the
associated unit. Changes must run the gantlet of a Change Control Board (CCB) plus
may require government concurrence in some cases. The object of this scrutiny
is assurance that safety, litigation prevention, environmental concerns, and quality
are high in priority.
Return to Table of Contents
System design always has concern for what the performance of the system will be
after the subsystems are integrated into a complete, functioning entity. How well
subsystems and components will work together with respect to the integrated set of
customer requirements overrides optimum performance of any subsystem.
Subsystem designers always must be harnessed to the system goals through the
subsystem specifications whose requirements are allocated and tailored to support
Without adequate system level requirements definitions, the individual specialty
designers will make their own assumptions about subystem design requirements and may
seriously err by neglecting the non-performance parameters. Some organizations have
learned, through bitter experience with the extensive delays for redesign and
interminable verification test periods before customer acceptance, that even
moderately complex system designs require substantial Systems Engineering from the
Support equipment is part of the overall system and therefore not less
important than the prime equipment to ultimate customer satisfaction. Their design is
to a different set of requirements, however.
System level requirements should not levy specific solutions on subsystem designers
and software engineers. In the exercise of this truth, it is often forgotten that the
system requirements should cause and may define specific testing to verify their
If support for system testing drives the design of prime and support equipment
beyond what would have been implemented with only subsystem performance
characteristics of interest, the job of verifying system readiness for delivery
becomes so much easier and quicker that the extra front end work is more than
paid for through rework costs not being necessary. System level accessible
built-in test verification features are particularly invaluable, but must be
designed in from the start or system level testing is virtually impossible.
The best long-term solution is to adopt the following rule:
A system performance or design requirement is most legitimate only if
its fulfillment can be proven during system verification testing against the standards
provided or implied by the customer needs for the product.
Return to Table of Contents
Integration is where system decomposition is reversed, where the hardware
components and firmware expressions of software begin to come together in a
support equipment integration environment, so the system perspective continues
to be necessary. Integration activity is a mix of bottom up and top down
functional/performance requirements and interface documentation verification.
Composition proceeds with assemblies becoming subassemblies which are further
integrated and verified into subsystems which are integrated and verified to
become the final system. The overall process of top-down design and bottom-up
integration now looks like a "V" in diagram form.
In larger organizations, the associated activities are divided into engineering
(development) testing for predicting performance, qualification testing
for verifying the design, system integration testing, and acceptance
testing for verifying minimum performance is provided by every deliverable
Acceptance testing of many military systems includes exercising the test unit
during cycles of rapid change between temperature extremes, after a soak time,
and vibration along most susceptible axis. This is called Environmental Stress
Screening (ESS). This "shake and bake" environmental testing for
manufacturing screening is designed to induce any incipient "infant
mortality" and thus preclude early failures of installed and operating
production units. Mean Time Between Failures experienced by the customer then is
likely to exceed the value predicted for the developed system during design
Development of requirements verification and maintenance testing requirements is
integral to the Systems Engineering process for system design. The same skills
required of primary system designers often are necessary to design test equipment for
system level verification and validation.
Return to Table of Contents
As with other management assignments, your purpose is to make it possible for
others to accomplish the mission of your organization. Your selection should
have been based on ability to communicate the systems perspective across many
technical disciplines, not on your performance as a technical designer or as a
project engineer dealing mostly with schedules and budgets. If you think of Systems
Engineering professionals only as better educated factory robots, you lose.
System engineers are just individuals whose personalities, strengths and
weaknesses you must learn in order to make the most appropriate assignments
for their most effective achievements in support of the organization goals
applied in a typically hostile environment. When you don't provide challenge
in meaningful assignments and appropriate support, in terms of resources,
tools, empowerment and direction, you are responsible for much of the blame
for their supposed ongoing mediocrity. The foregoing applies as much to the
Chief Engineer of the project Systems Engineering and system test teams as to
the functional director of a Systems Engineering group.
Objectives of the Systems Engineering function are:
The project system engineer also must balance cost and schedule against the
technical performance objectives, provided that critical system performance
minimums are not jeopardized by reported shortfalls in subsystem or component
reliability or in some other performance factor. Attempting to simultaneously
minimize all of project Technical, Schedule, and Cost Risk aspects is
impossible when attempt is made to agressively schedule technical
accomplishment at a defined low cost. When you fix two of the elements, the
third becomes relatively indeterminant. Sometimes, only one risk aspect can be
This brings up the issue of describing the work required to define new system
development efforts. Part of project tailoring must be the schedule for the
data list, so the laudable urge for parallel work does not require simultaneous
delivery of serial process products. Work packages will consist of cost and schedule
estimates for development and release of requirements specifications and the
"level of effort" required to fulfill the objective of an adequate system
Estimates based on the actual expenditures during previous "similar"
projects may not be directly applicable. For military projects, the Seller
Requirements Data List is different between the military services for similar
equipment and evolves over time. The degree of difficulty in attaining
technical objectives may differ substantially. (It is prudent to have a
technical performance criteria budget with significant slack for the same
reason as in project cost and schedule predictions. Uncertainties will at
least as often work against you as for you.)
Major, complex systems development projects never proceed cleanly from
one Systemss Engineering step to the next. Discoveries of errors of omission or
commission drive changes to requirements which affect one or more somethings
at some stage of development, forcing return to an earlier stage for the
affected item(s). This is most likely when users and maintainers are left out
of the initial concept design development, when Concurrent Engineering
principles were not heeded. Some parts will become advanced and some retarded,
with respect to the initial plan, very early in the system development cycle.
Sometimes, unwarranted optimism led to setting of performance objectives that
happen to be physically impossible within the cost and space constraints
required by feasible technologies.
This is one reason Risk Management is considered a Systems Engineering
Management responsibility. An analysis may call for data that leads to
rethinking the original problem and radically changing requirements well before the
variances would show up under an earned value process, saving enormous cost and
schedule delays that would come from reworking instead of early redesign.
Complex subsystems will suffer from similar problems because they are systems
at the next lower level of perspective.
A checklist, with questions tailored to the system or subsystem at hand as
well as to the step being assessed, helps you keep your system perspective
during design reviews.
Further, the more the overall environment supports effective Systems Engineering,
the greater the likelihood that the resulting system design will fulfill its
requirements effectively. Any metrics used to measure the performance of the process
should motivate improvement either in the deliverable system or in the Systems
Engineering output products. No metric is preferable to a bad metric in a supportive
environment, because you then work under a minimum of high-documentation management
Applying even the desirable Systems Engineering approaches as contractually
required or mandatory procedures will make them as suspect as regular management
control procedures in the view of working engineers. That is, "management by
exception" controls applied to surface and highlight deficiencies frequently
are misused to assign only blame, so the more experienced engineers will find ways
to comply at a minimal level. When working engineers become defensive and begin to
hide all but the most glaring problems, to avoid undesirable attentions of higher
management, suboptimum system designs are virtually guaranteed. So, what can you
Fortunately, the practices of Risk Management and Technical Performance
Measurement provide inherent controls on the Systems Engineering process while
being generally acceptable to working engineers. Just as individual components
are assembled into subsystems which are then integrated into complete systems,
Risk Assessment begins at the lowest design levels for each project phase. Those
technical judgments are integrated into subsystem level assessments which in turn
form the system level Risk Assessments. (See the tutorial on Risk Assessment for
additional detail regarding constituent factors.)
Each higher level must increasingly employ a greater proportion of the
total systems perspective. When pressure is applied by people whose
success is measured by meeting delivery date milestones without corresponding
attention to quality or performance of the product, integrity of the risk
judgments by technical and systems people may be compromised. Complex systems
development takes so long that the people who must integrate subsystems and
patch the whole thing into a system often are not the original requirements
specifiers and designers.
Short term thinking is affordable only to those who don't expect to live with
the consequences of their decisions. When budgets are tight, management
pressure to take shortcuts can become even stronger. Pride in output product
stays with members of teams who maintain involvement through the completion of
development and operational performance verification tasks.
The greatest likelihood, however, is that the early team members will
"meet" the initial project milestones with deficient documents and
designs, yet be praised as heros and be sent on to the next glamorous project.
The supposed second-stringers that remain will have to do the grotty job of
making it all work and to quietly accept the expressed or implied blame for
system shortcomings. By that time, budgets and schedules are overrun and upper
management is not interested in requirements deficiencies.
The only information of interest to management in that situation is how the
current team will get the system delivered soon at minimum cost, regardless of
performance problems. When a critical system is very late, some performance
requirements may be waived by the customer.
After all that, don't be surprised that some team member's judgment bias will
be towards choices likely to be made by the more ambitious, politically conscious
Unless Systems Engineering management helps the process, the rewards for keeping
the systems perspective are more likely to be penalties. It takes a very
self-confident systems engineer to risk walking the bed of hot coals just
described. Professional pride must exceed personal ambition by a large margin.
Junior design engineers should be assigned to the projects for learning from
the experienced people, even at the risk that they will develop the appropriate
Systems Engineering attitude and approach. They need to understand it, but not
for functioning within the everyone is a Systems Engineer paradigm. The
design organization rewards are not likely to be for maintaining the systems
The tool to help management retain control while maintaining the systems
perspective is Technical Performance Measurement. Design deficiancies which
may not seem important when reviewed at the subassembly level may assume much
greater importance when reviewed for impact at the systems level where its
mission accomplishment criticality becomes apparent.
To alleviate the usual problem of delivering "garbage," such as key
specification documents that are mere skeletons filled with TBDs just to meet
early project milestones, Systems Engineering management must recognize that
technical uncertainties at the start of complex development projects coupled
with the inevitable changes prevent casting schedules in concrete.
You win some and you lose some, if schedules are realistic. You lose them all
if unbridled optimism substitutes for experienced judgment and no slack for
contingencies is allowed in the tasks.
Poor design remains long after memory of congratulations for meeting a
schedule milestone has faded.
The Japanese, in their "lean" production approach, assign a program
manager and engineering team for the life of the project. They obviously apply
Concurrent Engineering because the majority of changes occur during design,
with only a few at readiness for production. They practice Systems Engineering
by front loading the project to determine what to design as early as possible.
There is a lesson here.
It helps to begin analyses with the customer/user perspective and remember that
systems engineers see to it that their system requirements are met without
being concerned about how it was done in the hardware. You don't care how it
was done, be it smoke, mirrors, or magic, so long as you can verify fulfillment
of the requirements with scientifically repeatable tests. Adequate technology meets
the customer's objectives soonest, not application of the theoretically best possible
An incremental improvement to an existing approach may be the solution. Remember,
it is system rather than subsystem optimization for which you are shooting. Does the
output value justify application of the input to the process?
Successful systems engineers should be capable of becoming some of the more
successful project engineers/managers because only then do they really
know what is required to bring a system from initial concept to fielded reality and
can avoid a short-sighted and limited perspective that leads to sub-optimum decisions.
Hard-won system development experience contributes to smoothest integration of
knowledge from multiple disciplines and to better modeling of systems. It is
recognition that advancing any technological state of the art can bring forth
unanticipated problems. It is recognition that starting, stopping, abnormal
conditions, and implementation factors should receive nearly as much attention as
design effort for normal operation. This assists arguing the necessity for a larger
contingency factor in development schedules and budgets despite lack of clairvoyence
necessary to provide hard supporting numbers. It is realistic prudence rather than
"planning for failure."
The reverse job change is less successful, because assignment is to leadership
without the seasoning of hands-on experience. Simple observation of others doing it
is not enough to develop the necessary perspective for proper tailoring of the
Systems Engineering process to the project at hand. Seeing it without having
done it is like watching a travelogue on television and thinking you were
there. A few concepts penetrate but only at the intellectual level. It is not
internalized "knowledge," so tasks seem easier than they are and
budgets are chopped accordingly.
Balancing budgets and schedules is easier than managing and coordinating a
design that balances competing technical objectives because physical reality need
not be a constraint on wishful thinking in the former tasks.
Return to Table of Contents
If you have any questions on this tutorial subject, please contact the author as
listed below. A response will occur and entries in the FAQs section may result.
Return to Table of Contents
This tutorial is presented by:
Tutorial Author: email@example.com
Other subjects: firstname.lastname@example.org