ODDSCO's Defense/Aerospace Systems Engineering Introductory Tutorial

An ancillary tutorial about an Integrated Product/Process Team (IPPT) approach to Systems Engineering (SE) in the Defense/Aerospace Industries, from a practitioner's perspective.

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.]

Defense/Aerospace Applications of Systems Engineering

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 judgment.

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 objectives.

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

Work Breakdown Structures

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

Technical Performance Parameters

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 products.

Return to Table of Contents

Life Cycle Cost Parameters

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 practitioners often follow listed activities with a monitoring function; ie., verifying the incorporation of the results of Description of System Elements in the developing system and adherence to the various program plans submitted as data items to the customer.

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

Functional Analysis

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 Engineering.

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

Synthesis of Conceptual Systems

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 Performance Measurement.

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 cost.

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 cases.)

Return to Table of Contents

Evaluation and Decision

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

Description of System Elements

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 (CM)

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

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 those goals.

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 start.

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 fulfillment.

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

System Integration and Verification

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 unit.

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 reliability calculations.

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

Systems Engineering Management

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 minimized.

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 design.

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 controls.

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 do?

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 people.

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 perspective.

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 solution.

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:

The ODDSCO Co. Logo<br> (A stylized duck).<br>

Optants Documented Decision Support Co.
297 Casitas Bulevar
Los Gatos, CA 95032-1119
(408) 379-6448

Return to Home Page

Tutorial Author: jonesjh@optants.com
Other subjects: consult@optants.com