Systems EngineeringDrivers in Defense and inCommercial PracticeFrank R. Parth

Deloitte & Touche Consulting Group, 21901 Palanca, Mission Viejo, CA 92692

Received September 15, 1997; accepted February 15, 1998

ABSTRACT

In the past two decades, commercial systems have grown to the point where they exceeddefense-related systems in several of the areas which typically have driven the need forsystems engineering. Developing SE methodologies for profit-oriented businesses forces usto look in great detail at government-enforced practices and understand the true driversbehind the processes. The methods, tools, and procedures adopted must give sufficientbenefit in relation to their cost: otherwise, they will eat into the company’s bottom line withoutconcomitant gain. The need for systems engineering in both environments is dependent onthe size of the system under consideration, its complexity, its technological risk, and the needsof the customer. This article will examine the different drivers for systems engineering in boththe defense/aerospace environments and in the commercial environment. ©1998 John Wiley &

Sons, Inc. Syst Eng 1: 82–89, 1998

1. WHAT SE IS AND WHAT IT CANPROVIDE TO DEVELOPMENTORGANIZATIONS

1.1. Definition of Systems Engineering

There are a multitude of definitions for systems engi-neering that have been published, most of which havecommon themes in them. For example, MIL-STD-499A [1974: 1] defines SE as

. . . the process(es) required to transform an operationalneed into a description of system performance parame-ters and a system configuration through the use of aniterative process of definition, synthesis, analysis, de-sign, test and evaluation. . . .

NASA’s System Engineering Handbook, [MSFC-HDBK-1912A, 1994: 1], while not truly defining SE,gives a description of it as

. . . a continuous, iterative process with a built-infeedback mechanism that is used throughout a projector program’s life cycle to arrive at the best systemarchitecture and design possible.

For the purposes of this article, let us combine the mostuseful parts of the various definitions and define SE asfollows:

The set of activities which oversees the developmentprocess, ensuring that the product requirements arecomplete and fully satisfy the customer’s needs, thetechnical analyses are done, and everything necessary© 1998 John Wiley & Sons, Inc. CCC 1098-1241/98/010082-08

82

Correspondence

to integrate the parts of the product so that they worktogether as a unit have been identified and completed.

1.2. Why Do We Need SystemsEngineering?

The field of endeavor that we call systems engineeringis a combination of different fields and disciplines. Ittypically encompasses systems analysis, requirementsdefinition and management, systems design and ar-chitecting, [Rechtin, 1992], often the subdisciplines of“ilities” such as reliability, availability, maintainability,etc., and other specialties as make sense in the specificcircumstances.

However, simply listing the specific areas of SE doesnot give a sufficiently accurate picture of the overallcapabilities that SE is capable of if the reader does nothave a background in it. Perhaps a better term for whatSE is capable of doing in the commercial world issystems management rather than systems engineering,since this gives more emphasis to the breadth and to thelong-term role of the systems group than just the engi-neering portion. In defense/aerospace development, SEtypically gets heavily involved through the develop-ment life cycle up to delivery to the customer, thenminimally involved afterwards. In the commercial

world, the systems group can sometimes maintain itsrole in the on-going management of the system, e.g., insoftware applications developed for in-house use.

Whether SE is operating in a defense or a commer-cial environment, the system life cycle and the SEprocess begins with the identification of a user need.This need is then translated into a set of user require-ments and from there to a set of system-level require-ments through a needs analysis and requirementsdefinition effort. This is followed by other activitiesduring conceptual system design (typically involvingthe synthesis, analysis, and selection of system-levelconceptual solutions and/or technology applications)and preliminary system design (involving the modelingof expected system behavior, the allocation of system-level requirements to subsystems, and their subsequenttranslation into more detailed design specifications).The extent to which these steps are performed or notperformed depends on [Verma and Fabrycky, 1997]

• the complexity of the system,• whether the steps are dictated by regulatory (e.g.,

DoD) requirements,• the development approach chosen (waterfall vs.

iterative vs. RAD techniques).

Figure 1 Process view of systems engineering.

SYSTEMS ENGINEERING DRIVERS IN DEFENSE 83

At a high level the basic steps always need to bedone. The more detailed and specific steps are done asthe need dictates. Figure 1 is used in MIL-STD-499Band is equally applicable to both defense SE and com-mercial SE. The size and constitution of the SE depart-ment, or even the necessity for one, depends both on thesystem being developed or operated and on the desiresof the system’s customer. For a small, stand-alone soft-ware application, or a single-board power supply, adedicated systems engineer is not necessary. The func-tion of integration is still necessary, but it can be per-formed by the designer. For a mainframe program,many thousand lines of code in size with multipleinterfaces to other programs or to users, experience hasshown that systems engineering can provide benefit farin excess of its cost. If SE does nothing more thanrequirements analysis, the effort and the department isworthwhile. For new product development, the Soft-ware Engineering Institute (SEI) estimates that 40% ofsoftware bugs are due to poor or missed requirements.In the DoD, 80% of the life-cycle cost of a software-in-

tensive system is for maintenance and the cost of fixingsoftware increases by an order of magnitude as it passesfrom development to maintenance [Colbert and Huff,1995]. At one of the author’s past employers, the expe-rience was much better than this because the developerswere also the maintainers (a situation which is notalways true, especially since contractors are used somuch in SW development). Even in this case, SE caneasily pay for itself multiple times by just properlymanaging requirements.

2. SE IN THE DEFENSE INDUSTRY

SE in the defense industry has a reputation for beingstilted, formal, complex, and having high overhead.Probably the only true part of that is that it requires highoverhead and has strict reporting requirements. Notonly is there extensive analysis work required, but it hasto be strictly documented and reported. So SE writes alot of documentation (MNS, SEMP, A-, B-, C- specs,ICDs, etc.) and gets involved in the numerous reviews

Figure 2 Typical SE documentation in defense work.

84 PARTH

that are a part of large, risky system development:SRRs, SDRs, PDRs, CDRs. Figure 2 is adapted fromDoD Directive 5000.1. The purposes of the documen-tation requirements in the defense industry are to makeit as easy as possible for the government to understandand follow what’s going on in the project, to audit it,and to prove that they have full control over it. Theseneeds actually drive much of the DoD’s developmentmethods. Since the military does not do its own devel-opment work as a rule, they rely on thousands of peopleof unknown abilities in many companies to developtheir complex systems. The military resolved this prob-lem by setting up detailed processes and procedures inorder to provide greater assurance that the systems willbe well and thoroughly produced. The government isfaced with particular problems in this regard that privateindustry does not face, or at least not to the same extent.

While there is a lot of formality and rigidity withinthe defense industry,1 there are legitimate reasons forthe processes. The drivers to these SE methodologiesand processes are: complexity, high technological risk,extreme operational constraints, thoroughness, andauditability. Note that economics are generally not aconsideration here. Once a project receives Congres-sional funding, the economics of it are not debated anylonger until the contract is awarded and a project finan-cial monitoring systems is put into place.

2.1. Complexity

The defense industry has always pushed the margins onSE methods because their systems were often new,technologically risky, and very complex. There couldbe no compromise to knowing that they had thought ofthe best achievable design solutions to very difficultrequirements. The space program, aircraft carriers, thestealth bomber, the Abrams tank, and many others allrequire rigorous analysis and integration to ensure thateverything works as a system and not as individual andincompatible systems. (The failure to hire an integratorfor the avionics on the B2 ended up costing the USAFseveral times more than the integration contract bidwhen the electronics were put together and the automat-ic defense systems were found to interfere with theflight avionics.)

2.2. High Technological Risk

In the early days of the Industrial Revolution, the mostadvanced technologies were developed by private in-

dustry, occasionally (but usually not) with governmenthelp. The telephone and radio, the early airplanes andautomobiles, the early railroad locomotives were allcutting edge technology done without government as-sistance, the developers assumed all the risk involved.While there was Army-funded development for tanksand other military vehicles early this century, afterWorld War I the lead in technology moved back to theprivate sector (an exception being aircraft developmentdone in both sectors). During World War II, the govern-ment again took over the lead in developing the mostadvanced technology and this time held onto it for over40 years. After World War II and Korea, the spaceprogram began a huge technology push in parallel withthat created by the Vietnam conflict. Unprecedentedamounts of government money were spent on large, com-plex, risky projects. Private industry could never havedone the level of development that was demanded by theApollo program or by the space shuttle. The computerindustry would not be nearly as advanced were it not formassive amounts of government R&D funds.

2.3. Extreme Design Constraints

Space and military equipment must operate underwidely varying constraints of temperature, vibration,humidity, and shock to reliabilities typically in excessof 99%+. Designing for such extremes and to such highreliabilities requires a great deal of design analysis andstatistical modeling to assess each design. Field-levelmaintainability is also an important design considera-tion as is the man–machine interface (MMI) under fieldconditions of high stress. There are many subfieldswithin SE devoted to analyzing, mathematically and inother ways, these areas to ensure that the product willsatisfy the requirements under all conditions at alltimes.

2.4. Complete Answers

Since the government puts a higher emphasis on aperfectly workable system (if it doesn’t work, someonemay get hurt or killed) than it does on making a profit,there is much greater emphasis on examining develop-ment issues as thoroughly and as completely as possibleregardless of cost. While schedule impacts are sometimesa concern, the times the government gets the most worriedis when they need the materials for a war in progress orwhen a space launch window is threatened (due to the highdollar cost and significant schedule impact).

When the technological risk is high, the dollar costis high, and/or human life depends on the proper opera-tion of the system, little expense or schedule is sparedto do a thorough SE job. Every aspect of the system isexamined, studied, analyzed, and written up in order to

1Include NASA here because the important characteristics arethe same. It is not unreasonable to include the commercial aircraftdevelopers also, Boeing, Airbus, and McDonnell Douglas, becausetheir need to do thorough SE is much the same as the military’s.

SYSTEMS ENGINEERING DRIVERS IN DEFENSE 85

hand a package of documentation to the governmentpersonnel that covers all of the risky aspects of thesystem. Systems engineers who have worked on majoraerospace or defense contracts know that 100% cover-age is as expensive and unlikely as 100% reliability, andat detailed levels there is sometimes professional dis-agreement on how risky a certain aspect or a design is.But the majority of the time on these systems a lot oftime and effort is put into providing as complete ananalysis to the buyers as possible.

2.5. Auditability

One aspect of SE work that is true in the defenseindustry that is not true in much of the commercialworld is that every technical decision must have de-tailed analysis and documentation behind it if there isany risk perceived at all. The Congressional BudgetOffice, the OMB, or the GSA may come behind eachdevelopment effort to ensure that the government re-ceives fully developed systems for its financial outlay.This puts pressure on project managers to make certainthat they can point to specific studies or analyses foreach technical decision they make.

This requires not only a lot of SE personnel to do thework and to give the briefings, but it requires a lot ofoverhead to write and control the documentation. Sincethe government does not need to operate at a profit, thehigh labor costs associated with providing detailedtechnical audit trails are not of concern. Spending$25,000 to audit, investigate, and trace a $25,000 con-tract item is acceptable in this environment.

However, today the entire military development ap-proach is geared toward a pace of development that nowseems almost moderate in comparison to the rapid-firechanges in the computer industry. The DoD is limitedby policies and procedures that were developed whenthe pace of change was much slower. It drove the pacefor 30–40 years, but now it is being held back by thosepolicies and procedures. There are increasingly numer-ous examples of high technology development that isbeing paced by commercial needs rather than by gov-ernment needs. Industrial Light and Magic [Fisher,1979] is pushing Silicon Graphics much harder thanSGI’s aerospace customers are. Indeed, the hardestdriver to government procurement and developmentefforts now is the Year 2000 Problem, a problem theywill be unable to solve in time if their process do notchange quickly.

3. SE IN THE COMMERCIAL WORLD

The primary differences between SE in the commercialworld vs. in the defense industry used to be very con-

sistent and predictable. As stated earlier, defense workwas very expensive, very risky, and generally devel-oped very large programs. This resulted in SE practiceswhich were time- and resource-consuming, required alot of documentation and “proof,” and which the com-mercial world saw as expensive (it is) and unnecessary(it isn’t in that environment).

This relationship has been changing over the pastfew years. Previously, there was little doubt that themilitary and space systems were more complex andtechnologically risky than commercial ventures (withthe notable exception of passenger aircraft and cargo orpassenger ships) and thereby needed strict systemsengineering approaches. While these government sys-tems2 still have strict auditability requirements andextreme design constraints, it can no longer be said thatthey are more complex than many of the systems devel-oped commercially. The inherent complexity of semi-conductor chip manufacturing and of large-scalesoftware development has made many commercial sys-tems as complex as defense systems, if not as largephysically. Today’s laptop computers have more proc-essing power and more memory than the Tracking andData Relay Satellite (TDRS) that the government de-pends so heavily on. Microsoft Word for Windows, V.1,had over 384,000 source lines of code. Not many com-panies can afford to develop a new computer or aprogram of thousands of lines of code without strongrequirements analysis of what the customer will buyand without sufficient test and integration. This com-puter and the programs that it runs are complex systemsthat require strong systems management efforts to besuccessfully developed.

SE in the commercial world has a significant advan-tage over SE in government projects, we have thefreedom to pick and choose which approaches, meth-ods, and techniques will give us the information weneed to develop products and grow the business, but notbe driven by rules and regulations that do not apply. Wecan do as much analysis as needed to get the answerwithout having to prepare formal documentation andpresentations. The restrictions we face are that SE mustjustify what it does with respect to (a) time-to-marketimpacts and (b) cost/benefit analyses.

That said, many of the approaches used in the de-fense industry can be adapted and tailored to commer-

2For many years much of the commercial world consideredSystems Engineering to be necessary only for large military systemsbecause they couldn’t see the benefits for themselves. Many of theaerospace engineers that left aerospace during the downsizing a fewyears ago quickly learned that putting “Systems Engineer” on theirresumes resulted in their resumes being quickly rejected when theyapplied for jobs in the commercial world.

86 PARTH

cial development when it makes sense to do so. Thedifferences lie not so much in what is done as in how itis done. The best practices on the defense side flow intothe commercial side, a situation which accelerated dur-ing the defense downsizing of the early 1990s. Some ofthese practices are listed in the article by Verma andFabrycky [1997]. Upon reading their list, it becomesobvious that there are several SE activities that show upquite often. These are:

• Requirements management,• Feasibility analysis,• Functional analysis and decomposition,• Allocation of requirements to configuration

items,• System architecture design, • Performance analysis,• Interface identification and design,• Design trade-off studies,• Specification generation and support,• Identification of system resource requirements,• System reviews.

When considered in toto this set of activities moreproperly forms the field of systems management thanof systems engineering. In other words, when thesethings are done correctly, the systems developmentprocess is managed rather than just being a set oftime-scheduled activities done by different groups.

In a presentation given to the Los Angeles chapterof INCOSE in 1996, the presenter, a vice-president at

Douglas Aircraft, mentioned that while she was atBoeing several years ago they joint-ventured with aJapanese firm. There was technology sharing on bothsides, with Boeing sharing many processes to developnew aircraft, except for sharing their systems engineer-ing methods. That was considered a significant com-mercial advantage and thereby company-proprietaryand not to be shared.

While SE practices and methods in the governmentprocurement industry are well established and docu-mented, the commercial industry is still trying to deter-mine what SE methods make most sense for it. Whilea government contract will start the requirements de-composition with the A-spec, what makes more sensein the commercial world is to work directly with theuser to determine what the user requirements are. Thisapproach has put more emphasis on the user’s require-ments and has led to various methods of defining whatthose are. The techniques being tried vary from userinterview techniques, to variations on requesting the userprovide an A-level spec, to the storytelling/scenario build-ing technique promoted by Yacobson [1994] in the fieldof object-oriented software.

The author once worked at a data processing com-pany that utilized a bank of mainframe computers thatchurned through terabytes of data in order to producecustomer-desired lists. The process we created for de-veloping new products and the associated documenta-tion are shown in Figure 3. In the early stages of thisnew process, the SE group struggled heavily in writing

Figure 3 New product development documentation in a commercial arena.

SYSTEMS ENGINEERING DRIVERS IN DEFENSE 87

the requirements specifications for the existing system.As often happens in the commercial world, there wasalmost no usable system-level documentation. Whatdocumentation that existed was programmer-leveldocumentation that had been written much earlier andrarely updated. There was no interface documentationand the company felt that none was needed because theprogrammers knew what the interfaces were. The resultof this undisciplined approach was that the SE person-nel had to hold many meetings with large numbers ofprogrammers (each of whom knew only a small pieceof the system) in order to document the programs andthe data flow. The job became so hopeless that the SEgroup eventually stopped documenting the existing sys-tem and concentrated its efforts on writing require-ments for new products.

The opportunity SE has to meet with the customeris a leverage point that can be used to discuss the user’sneeds with them and the impact those needs have ondevelopment time and on overall cost. Often in govern-ment development work there is a high expectation bythe government that the system they want can be deliv-ered by the date they want. Nearly as often, this turnsout to be unrealistic. SE can provide a great benefit toboth the customer and to the developers if they can givethe customer a more realistic understanding of thetechnical complexities and can manage their expecta-tions.

Another area where commercial practices differ liesin the emphasis on getting products to market quickly.The government does not have to worry about competi-tors delivering tanks or aircraft faster than they do, butprivate industry must compete for market share and getproducts to the customers as quickly as possible. Thishas caused an emphasis on methodologies which re-duce the overall development and production timeline.Various forms of rapid application development (RAD)methods are constantly being investigated and tried inorder to reduce the timeline. There is a body of man-agement literature which shows that the emphasis inproduct development needs to be on schedule, not oncost, because the faster you can deliver a product intothe customer’s hands the more market share and profityou can make.

This is not to say that government has ignored thetime-to-market issue. Pressure by Congress to reducecosts have often resulted in the conclusion that sincedevelopment costs are high, the cost reductions desiredcan be achieved by reducing development timelines.Integrated Product Teams (IPTs) were developed in theaerospace industry and RAD techniques have been

developed at government labs. It is just more difficultto emphasize schedule when one is developing productswith so many unknowns and when the profit pressureto bring products to market quickly is absent.

As a general rule, commercial companies are look-ing at systems engineering methods and struggling todefine what makes sense for them. The author was oneof a group of systems engineers with aerospace back-grounds hired by TRW information Systems during thedevelopment of a major infrastructure project. Aftercreating an SE group and staffing it, the organizationthen decided that the formal SE methodology the engi-neers brought in was too foreign to its culture andbacked away from instituting strong SE methods andprocedures. Other companies, such as Toyota and Nis-san [Cotter, 1995], were much more successful at un-derstanding what they needed and incorporating it intotheir culture. Their Lexus and Infiniti lines were devel-oped around IPTs and utilized SE processes to designand produce each car as a single integrated unit ratherthan as a collection of separate components.

In summary, it is possible to bring the advantages ofsystems engineering into the commercial arena. Care-ful attention must be paid to the costs and benefits ofdoing so, and it is incumbent on the SE personnel tojustify their methods and procedures so that uppermanagement can readily see the financial advantagesof performing systems engineering. Indeed, this type ofjustification may be an integral part of SE in the com-mercial world.

REFERENCES

Colbert, J. G., and Huff G. A., “Multimedia Documentationfor the Software Maintainer,” presented at Fifth Annu. Int.Symp. INCOSE, July 1995, pp. 77–84.

Cotter. J. J., The 20% Solution, John Wiley & Sons, New York,1995.

Fisher, L. M., “How To Manage Creative People,” Strategyand Business, Issue 7, 2nd Quarter 1997, p. 79.

MIL-STD-499A, Engineering Management, May 1, 1974.MIL-STD-499B, Engineering Management, 1987, unpub-

lished.MSFC-HDBK-1912A, System Engineering Handbook, Vol.

1, 2nd ed., December 6, 1994.Rechtin, E., “The Art of Systems Architecting,” IEEE Spec-

trum, Vol. 29, October 1992, pp. 66–68.Verma, D., and Fabrycky, W., “Systematically Identifying

System Engineering Practices and Methods,” IEEE Trans-actions on Aerospace and Electronic Systems, Vol. 33, No.2, April 1997, pp. 587–595.

Yacobson, I., Object Advantage, Prentice Hall, EnglewoodCliffs, NJ, 1994.

88 PARTH

Frank R. Parth was born in Eichendorf, Germany, in 1949. He graduated from Creighton University inOmaha, NE, with a degree in physics in 1968. He completed a Master’s Degree in Physics at theUniversity of Wyoming and a Master’s Degree in Systems Management from the University of SouthernCalifornia. He began his career as a design engineer for Texas Instruments in 1978. He spent most ofhis career at Martin Marietta Space Systems as a systems engineer on satellite programs. When hisoffice closed in 1993, he became an independent consultant in systems engineering and in projectmanagement. He is currently employed by Deloitte & Touche Consulting as a project manager intechnology projects. During the past 5 years he has maintained adjunct faculty positions at Universityof Southern California and at the University of California, Irvine, teaching systems engineering, projectmanagement, and new product development. He has been a member of INCOSE since 1994 and the

Project Management Institute since 1993. He is currently on the planning committee for PMI’s 1998 International Symposiumin Project Management.

SYSTEMS ENGINEERING DRIVERS IN DEFENSE 89