Systems Engineering for Defense Acquisition

This guest article by Mike Gangl explains how Government acquisition agencies use modern systems engineering to define new systems. If you are not familiar with some of the DoDAF terminology later articles will explain concepts like Operational Views in more  detail.

Whereas systems engineering is needed to develop any new system or improve on existing products, there are unique activities and nomenclature for those engineers who are supporting US Department of Defense (DoD) acquisition programs. DoD has recognized that the systems they procure are much too complicated to not address quality systems engineering practices. Additionally, if these procured systems do not perform as required or fail in operation, then the consequences may be severe including failed US policies or even injury or death to our military men and women. Therefore, it is important that engineers and program managers who are working on government projects understand the system engineering processes defined by the DoD and how these relate to their own product development SE processes.

The standard by which the DoD acquires new systems, from planes to ships to radios and beyond, is Department of Defense Instruction (DoDI) 5000.02, Operation of the Defense Acquisition System. The latest version is dated December 8, 2008 and a copy can be found at http://www.dtic.mil/whs/directives/corres/pdf/500002p.pdf. Figure 1 of the “5000” process shows the primary stages of the acquisition cycle, which include pre-system acquisition, system acquisition and sustainment. The DoD acquisition community has statutory and regulatory requirements to follow this process to procure new military systems. But there are two important exceptions.

The first exception is for research and development. Government organizations such as the Defense Advanced Research Projects Agency (DARPA) and the military laboratories issue research and technology development contracts to other government agencies and industry contractors. These contracts do not follow the 5000 process. Typically, the systems engineers will receive a Statement of Objectives (SOO) and perhaps a set of target performance requirements. In some cases, such as DARPA with their go-no go criteria, further funds are predicated on achieved performance. This is good since no program manager or systems engineer should sign up to meet hard, budget linked requirements for technologies that are not yet demonstrated. Of course, companies are frequently tempted to do so to win the contract. So it is important that the engineers, even on these technology development projects, follow some form of a systems engineering process and ensure all stakeholders understand risks and mitigation tasks. A company’s profit and reputation depend on it.

The second exception is a more recently popular acquisition approach called Quick Reaction Capability, or QRC. For these types of contracts, the system developer is provided with a set of requirements the military need to satisfy to field an operational capability. A QRC is typically justified to either demonstrate the utility of a new technology or mission, or to satisfy an immediate need of the warfighter. This is especially important in times of war. The largest, most recent example is fielding technologies to defeat improvised explosive devices (IEDs). With a QRC program, the government elects to forgo the 5000 process and have the contractor build and field the equipment on a best effort basis.

Of course, the degree to which the requirements are met still have a significant impact on whether the customer is satisfied. Here, it is extremely important that the engineers maintain some level of systems engineering discipline in a highly accelerated schedule. Managing performance and expectations are even more critical when you are working “under the gun.” A big issue for many DoD acquisition programs in today’s environment is having the Pentagon leverage a 5000 process while imposing a QRC schedule. Everyone wants the latest and best capability. And in time of war, this is amplified. These competing requirements, full acquisition process vs. schedule, are not easily solved and will require continued systems improvements to the acquisition process.

Back on the subject of the 5000 process, it is important to point out some of the key systems engineering products the government is required to produce and how they relate to engineers and their programs. This article does not cover the whole DoDI 5000.02 process since that is a separate, extensive topic. Training can be found through the Defense Acquisition University (www.dau.mil).  Typically, this training is only necessary for government systems engineers. There are three important items for engineers who work on government contracts to develop systems.

The first is the flow of requirements. It is important that a contractor systems engineer understand the way the program requirements have flowed down through the government process. For a typical military acquisition program, the primary requirements are captured in a Capability Development Document (CDD). The CDD contains the government agency’s Key Performance Parameters (KPPs), Key System Attributes (KSAs) and any additional attributes they believe are necessary to have the system satisfy their objectives. The CDD is usually worded in language from the user community rather than from technical personnel. The government organization that is responsible for the acquisition then must procure a system that satisfies these KPPs and KSAs. The systems engineers of the government acquisition organization must translate these CDD requirements into technical and operational requirements. These are documented in a System Requirements Document (SRD). Many government systems engineers now use software tools such as DOORS™ to track the linkage of the CDD to the SRD. Typically, the government may release either a top-level SRD or a complete SRD. The difference is the amount of engineering maturation that occurred to derive the SRD requirements. If the agency doesn’t have all the expertise and time at their disposal they may elect to go with a top-level SRD and work with the contractor to mature the requirements. Prior to entering the Engineering and Manufacturing Development phase of the program, the SRD will be worked into a final System Specification (sometimes called a Weapon Systems Spec, or WSS). The WSS is intended to resolve all To Be Determined (TBDs), To Be Reviewed (TBRs), and no longer contain Threshold (T) and Objective (O) requirements. It is expected that the WSS contains the specific requirements that the government and contractor will comply with during fabrication and test.

The second important DoDI 5000.02 document to understand is the Systems Engineering Plan (SEP). Like Systems Engineering Management Plans (SEMPs) that many contractor companies create, the SEP describes the engineering processes, tools, plans and schedules as determined by the government acquisition engineers. The SEP may be reviewed as high as the Pentagon, depending on the program’s acquisition category. It is considered a living document that changes as the program matures. It takes on different information as the program progresses through development maturity. Although the government continues to own and maintain the SEP they expect the contractor’s program management and engineers to not only contribute to the maintenance of the document but to synchronize any of their own SE processes and plans with it as well. It should be noted that the SEP must be updated and provided at key milestones throughout the acquisition process.

The third important item to reference is the DoD Architecture Framework (DoDAF). This is a series of pictorial and graphical representations of the system being developed. It can be thought of as the documentation of the functional and physical architectures. The top level diagram of the DoDAF is the Operational View -1 (OV-1). This is typically a concept type picture that shows how the system may be operated. Essential elements are shown in the OV-1 along with external elements that the system is expected to interface with. There are additional Operational View documents to further describe these system and external elements and how they are intended to operate.

Additionally, the DoDAF has other diagrams and documents under the major categories of Systems and Services View (SV-x) and Technical Standards View (TV-x). The SV articles should be closely watched since it typically contains specifics on interfaces to external entities and is used to derive Interface Control Documents. Note: there is also a higher level All View (AV) but systems engineers may not find those as beneficial.

The DoDAF is started by the government operational agency to denote what the system is and how they intend to use it. Their most important contribution is the Operational Views. After the government acquisition agency begins their program they will most likely take over the DoDAF and work out the details with the contractor(s) and external entities that include users and interfaces. They may even elect to have the contractor take over the maintenance of the DoDAF, but the government retains responsibility. There are several tools for developing a DoDAF including IBM’s Rational System Architect^©. Vitech’s CORE^© software tool allows the engineer to capture functional and physical architectures in traditional systems engineering methods and has a DoDAF output it can generate. As a minimum a contractor’s system engineers are expected to understand and work with a government generated DoDAF document for their program. They may also be involved with generating and maintaining the DoDAF at some point in the program. It is important to learn and understand the various aspects of this visualization method.

In summary, for the engineer who is working on government acquisition programs, there are specific rules and requirements he/she must follow to ensure compliance with the DoDI 5000.02 development process. The process and documents the government requires are in general good systems engineering practices. The biggest challenge to the systems engineer on a government program is to follow the right systems processes under very challenging schedules. In this aspect, working government programs is no different than commercial.