Defining Military Space Capability Requirements for Successful Development
Policies and practices are evolving to ensure that new system developments are executable from the onset. The new approach emphasizes close coordination of requirements definition and acquisition strategy development.
First published May 2013, Crosslink® magazine
The key to delivering systems that meet operational capability needs on time and on budget involves early trade studies and decisions about the requirements that can be met within the given fiscal constraints. This involves matching up two processes—user requirements definition and acquisition development—that have historically functioned separately. Recent efforts within the Department of Defense are driving closer cooperation between the user requirements community and the acquisition community.
Aerospace supports both communities, helping them reach an appropriate balance between warfighter needs and available resources. In fact, early Aerospace support can be a force multiplier in the long run, creating the leverage necessary to ensure that an operational need can be successfully translated into a space system acquisition program. The earlier Aerospace systems engineering expertise is applied in the acquisition lifecycle, the more efficiently the government can satisfy capability needs across the overall space portfolio.
Tracing Requirements to Combat Needs
The Department of Defense has divided responsibilities for acquiring systems and establishing operational requirements into two primary chains. The acquisition chain is headed by the secretary of defense and the service secretaries, and the operational chain is headed by the chairman of the Joint Chiefs of Staff. The acquisition process is primarily governed by DoD Directive 5000.01 and DoD Instruction 5000.02, collectively known as the Defense Acquisition System. The operational requirements process is governed by CJCS Instruction 3170.01, which establishes the Joint Capabilities Integration and Development System (JCIDS).
Under JCIDS, warfighter capability needs are established by the combatant commanders—the joint commanders responsible for executing military operations for a functional area (such as U.S. Strategic Command) or a geographic region (such as U.S. Central Command). Within each military service, a major command is designated as the lead command, responsible for organizing, training, and equipping a combatant command. For most space and cyber capabilities, Air Force Space Command serves as the lead command. The bulk of acquisitions within the space mission portfolio are managed by the Space and Missile Systems Center (SMC).
This duality of having the combatant commanders establish capability needs and the acquisition community fulfill those needs is an effective way to balance needs and affordability. On the other hand, these dual responsibilities have led to problems whereby requirements are validated with insufficient assurances by the acquisition community that they are feasible and executable. Recent changes in both law and policy have sought to synchronize these processes better; these changes affect how system-level requirements are engineered up front, early in the acquisition process prior to any contract award for the system design or development.
The acquisition and requirements lifecycle, starting at the materiel development decision. This simplified view of the Joint Capabilities Integration and Development System process overlaid on the acquisition process is part of a tutorial on the space acquisition framework, which was developed by the Space and Missile Systems Center at Los Angeles Air Force Base and Aerospace to reflect the integration and alignment of acquisition and requirement milestones in the acquisition lifecycle.
Assessing Mission Needs
As a first step in tracing user needs to new materiel requirements, Air Force Space Command conducts a capabilities-based analysis, tied to mission-level architectures, to identify and prioritize gaps in military capability. Aerospace often leads or contributes to these analyses. Specific tasks include developing integrated architectures to identify mission needs and linkages to system capabilities and performing mission-area analyses and integrated investment analyses to determine the most economical way to satisfy capability gaps within and across mission areas. The products of these activities inform decisions on programming (budgeting) and technology development, and can even indicate which types of materiel solutions should be pursued as future programs. Implicit in this process is technical rigor and freedom from bias—specifically, long-term expertise with mission analysis and architecting, objectivity, and unfettered access to proprietary concepts from industry. This type of work, therefore, lends itself to being done by an independent body such as Aerospace, which is a California nonprofit corporation that operates a federally funded research and development center (FFRDC).
A capability gap may be broad and may be met with new tactics, new capabilities, new materiel, or a combination of all three. When it is determined, based on analysis, that a new materiel solution must be developed, Air Force Space Command creates the initial capabilities document (ICD) to define new requirements and associated gaps. This document is the first to formally trace capability requirements from the mission architectures and underlying analyses to the initial set of system-level requirements. This traceability, both in requirements and in architectures, must be preserved throughout the acquisition lifecycle.
Establishing an Initial Requirements Baseline
The decision to pursue a new system ushers in the materiel-solution analysis phase. Two major activities occur at this time, the analysis of alternatives and the development of an acquisition course of action.
The analysis of alternatives is highly structured and typically led by Air Force Space Command for space programs, but sometimes sponsored or led by other organizations, such as U.S. Strategic Command. Aerospace often serves as the study leader. Team members typically span multiple organizations and communities, including users, headquarters staff, acquisition centers, labs, and intelligence organizations.
As with the capabilities-based assessment, the analysis of alternatives must be executed by organizations and personnel free from real or perceived conflicts of interest—otherwise, industry will not share its system concepts, and decision makers will not accept the results. Aerospace personnel representing multiple organizations often work together on analysis of alternative teams, typically leading technical studies or subgroups developing measures, threat assessments, materiel alternatives, scenarios, and methodologies. The analysis of alternatives is documented in a report which, under the JCIDS process, is coordinated through the Joint Requirements Oversight Council. This report is not openly discussed until published because of the extreme sensitivity associated with comparing the merits of materiel concepts from multiple industry and government sources. The report is required by the Air Force to include a requirements correlation table (RCT), which defines an initial set of prioritized key performance parameters and system attributes for the recommended alternative or set of alternatives. This information will form the basis for a draft capability development document (CDD), which is the formal operational capability requirements document that must be finalized before the acquisition baseline can be approved.
The analysis of alternatives will indicate the most effective means of satisfying the high-level capability needs, but will not contain enough detail to develop an acquisition strategy. Thus, an acquisition course of action must be established. Aerospace supports the process through workshops designed to assist the program office in presenting a common vision and establishing an end state for the program.
The technology development phase involves simultaneous requirements and acquisition processes. Aerospace often facilitates collaboration during the early portion of this phase, where numerous stakeholder requirements are considered. Failure to work collaboratively can lead to rejection at milestone decision points.
These workshops cover program objectives, risk assessments, technology development strategies, and acquisition strategies and help to identify the requirements that most influence cost, schedule, and technical performance. For example, Aerospace recently led a workshop for a program that involved a wide range of operational and acquisition stakeholders. While the only viable materiel solution was a new space-based sensor, the possible acquisition approaches varied widely, from a payload hosted on a foreign spacecraft to development of a new spacecraft. This workshop defined program objectives and key driving requirements and provided the foundation for selecting an acquisition approach. Such early programmatic decisions are often fraught with competing government and industry goals, but the workshop ensured that the acquisition approach was based on solid data and a fair accounting of risks, cost, and schedule considerations as well as technical performance.
The transition from the analysis of alternatives to the acquisition course of action is significant, for it is at this point that the program office begins to set the pace (in terms of budget and schedule) for delivery of a capability. Once an acquisition strategy has been selected and approved, an affordability target must be established and formally documented. To properly integrate affordability into the baseline set of requirements, the systems engineering and architecting performed here must be integrated across system segments and functional disciplines, including program management and control. The systems engineers—which include Aerospace personnel supporting both Air Force Space Command and SMC—must maintain a holistic view of the trade space and not lock in specific solutions that overly constrain other elements. Solution sets that may not satisfy 100 percent of the requirements should be considered with a broader view of balancing cost, schedule, and technical performance. The cost analysis must consider lifecycle and acquisition costs as well as possible impacts to associated systems and operational concepts, such as the need to modify intelligence gathering systems or to commission new military units to implement the new capability. Aerospace supports the decision-making process by managing and executing the independent program assessments required by acquisition policy. There has been a tendency in recent years for programs to skip the materiel-solution analysis phase to avoid preparation and coordination of the requisite documents. This can appear to save two to three years of schedule, but it also eliminates much of the systems engineering that reduces risk and enables effective and efficient program execution.
Systems engineering activities ramp up in the technology development phase, particularly before a new program can be placed on contract for design and development. High-level policy and instructions typically only identify senior approvals of final requirements and acquisition documents through separate chains of responsibility, and therefore often do not adequately convey the intent that these documents be developed collaboratively and in parallel. Aerospace often facilitates collaboration among the acquisition and user stakeholders during this phase. Failure to work collaboratively will result in rejection at key decision points, leading to delays, rebaselining, and ultimately, failure to deliver a system that meets user expectations on schedule and within budget.
There are three main process loops for requirements collaboration. The first involves the flow down (and up) of requirements from the correlation table or draft capability development document to the draft system requirements document (SRD). The second entails the formal coordination of the final system requirements document included in a request for proposal (RFP). The third generates the acquisition community’s formal feasibility assessment of the capability development document prior to approval. Aerospace is involved in each of these process loops, representing various stakeholder perspectives and ensuring that technical issues are resolved early and at the lowest level possible.
Loop 1: Requirements Trades
The tracing of requirements from the correlation table or draft capability development document to the draft system requirements document is performed as part of iterative trade studies. These trades refine key performance parameters, schedule, cost, and technology and manufacturing risk and are performed within the context of larger mission architectures and mission-level capability analyses. Performance must also be traded against operational suitability requirements such as reliability and protection as well as considerations such as operational concepts, staffing, facilities, and training. Aerospace typically leads or supports these analyses, which are similar to the trade studies performed in the materiel solution analysis phase, but at a lower level of detail. Aerospace often also develops the system requirements document on behalf of the program office and helps establish a requirements-management process that includes a mechanism for maintaining traceability both up and down the hierarchy of documentation. Neither the system requirements document nor the capability development document can be completed until affordability targets are fully analyzed and trade studies are completed. Requirements traceability becomes more complicated and more critical as these documents are solidified. A simple table or spreadsheet becomes unwieldy as operational attributes and constraints are translated into materiel development requirements—which is why a formal requirements-management program is essential.
Loop 2: Coordination
It may sound counterintuitive, but the system requirements document (also known as the technical requirements document, or TRD) is finalized and approved before the capability development document. The contractors will use the system requirements document to derive system-level specifications and develop a preliminary design. To ensure that appropriate requirements coordination and traceability is occurring at the working levels, the Air Force now requires all programs to coordinate system or technical requirements with Air Force Space Command prior to issuing an RFP (most SMC programs were already coordinating requirements documents with their working-level counterparts at Air Force Space Command, but were not formally coordinating them above the working level). This requirement highlights the importance of the system requirements document as a critical element of early systems engineering. The key to successful coordination is demonstrating clear traceability and mutually agreeable decomposition of the operational capability requirements and intent into an achievable set of system requirements. Before the system requirements document enters coordination, it must be checked to ensure that it is consistent and traceable to user capability needs and does not represent requirements growth. This task, sometimes performed by Aerospace, requires complex understanding of the user’s intent, concept of operations, sustainment plan, and lifecycle budget in addition to the user requirements.
Loop 3: Assessment
The Air Force requires the acquisition community to formally assess the feasibility of the operational requirements in the capability development document before it can be approved. This assessment is certified by the acquiring major command and service acquisition executive (depending on program size). For SMC programs, the acquiring major command
is also Air Force Space Command, but in a different role from the one it plays as lead command in developing the capability development document.
Certification is accomplished concurrently with joint staffing of the capability development document, which occurs around the time of the preliminary design review, about a year before the acquisition program baseline is finalized. For the certification to occur, the program office and Air Force Space Command must have worked together to finalize the document requirements. As the user representative for the program, Air Force Space Command is responsible for engaging warfighters and other operational stakeholders as well as programming and acquisition personnel in developing the document. The formal mechanism for doing so is the integrated concept team. Aerospace supports these teams through multiple stakeholder organizations, including the program office, U.S. Strategic Command, and operational units as well as functional areas within Air Force Space Command staff such as operations, testing, training, logistics, basing, and information assurance.
In support of both SMC and Air Force Space Command, Aerospace also ensures that the capability development document and system requirements documents, as well as operational and system architectures, are synchronized and also leads analyses to ensure that all requirements are feasible from a technical, cost, and schedule perspective. For the government, Aerospace also leads the resolution of requirements issues across Air Force Space Command, the program office, and user organizations such as U.S. Strategic Command and the intelligence community, as it is uniquely positioned within each of these organizations to provide continuity as well as technical expertise.
Certain elements of the capability development document must be included in the acquisition program baseline—specifically, the key performance parameters table, dates of initial and full operating capability, and cost thresholds. Aerospace personnel supporting a program must be aware of the acquisition program baseline (APB) thresholds and corresponding capability development document thresholds in order to monitor progress against the baseline and avoid a breach in cost, schedule, or technical performance. Consistency across the acquisition and requirements baselines is especially critical, because a program in breach of its acquisition program baseline or capability development document baseline must be staffed through the acquisition chain of command and also have its requirements revalidated.
Closing the Affordability Gap
In the interest of closing the affordability gap between capability needs and program baseline, the requirements process (JCIDS) and the acquisition process (DoD Instruction 5000.02) have been synchronized such that the capability development document is finalized around the time of the preliminary design review. This is intended to ensure that the document presents an affordable set of requirements and that the program baseline is based on a mature system design. This principle encourages knowledge gained during early system-level design to influence the requirements process.
This approach, however, presents a paradigm shift for the space acquisition community. Traditionally, the prime development contract was awarded midway into the technology development phase, and the contractor was allowed to mature the design through the system engineering design reviews. But history shows that changes in contractual system requirements after the prime development contract is awarded jeopardize the negotiated contractual baseline; contract modifications after contract award are challenging for the government to negotiate.
The traditional solution to this challenge, which is deeply embedded in SMC culture, has been to insist that Air Force Space Command lock down operational capability requirements early in the technology development phase. However, this cultural aversion to keeping requirements flexible during the early stages of design has, on more than one occasion, had the unintended consequence of forcing a contractor to attempt to design and develop a system to meet an operational requirement that turned out to be infeasible with regard to cost, schedule, or the current state of technology. In some cases, a formal request for relief was made only after a breach in the cost, schedule, or technical baseline had occurred. This overly formal type of relationship between user requirements and program acquisition is one of the problems that was targeted in the Department of Defense mandate to treat affordability as a key performance parameter.
To achieve the efficiency and economy envisioned in the latest guidance, innovative strategies are needed that allow affordability updates to flow into the program and contract baselines. One strategy might involve competition all the way through to the preliminary design review; however, carrying two (or more) industry partners would be a costly proposition unless the contracted efforts were confined to specific subsystems or limited areas of the overall system design. A full and open competition would be advantageous to the government, but would shift the financial burden to the competing contractors. Another strategy might involve a contract structure that anticipates changes to the requirements baseline that is implemented through some predetermined cost of the anticipated changes.
Aerospace can help program office personnel select and formulate the most effective top-level acquisition strategy and contractual approach to achieve program success under the certain conditions of constrained budgets and a flexible requirements baseline.
Aerospace has many roles to play in helping program offices define and manage affordable and traceable requirements. Early Aerospace involvement in requirements definition and management is critical to the success of the acquisition in any era, but is even more critical in a time of shrinking budgets. Moreover, Aerospace is positioned to foster teamwork across multiple organizations; such collaboration enables effective responses to time-critical issues and ensures that requirement trades are considered and assessed at a technical level. Such support across the entire system lifecycle can have far-reaching benefits when combined with a relatively small increase in Aerospace participation at the front end of requirements and program definition.
Aerospace Report No. TOR-2005(8583)-3, “Rev B, Systems Engineering Requirements and Products” (The Aerospace Corporation, El Segundo, CA, 2005).
Better Buying Power 2.0: Continuing the Pursuit for Greater Efficiency and Productivity in Defense Spending, OUSD(AT&L) Memo. for Defense Acquisition Workforce, http://bbp.dau.mil/references.html (as of Nov. 13, 2012).
Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 3170.01H, “Joint Capabilities Integration and Development System,” https://acc.dau.mil/CommunityBrowser.aspx?id=267116 (as of Apr. 19, 2013).
Manual for the Operation of the Joint Capabilities Integration and Development System (July 31, 2009), https://acc.dau.mil/CommunityBrowser.aspx?id=386053 (as of Feb. 12, 2013).
About the Authors
Jennifer R. Owens
Project Engineer, Space Situational Awareness and Command and Control, supports the Acquisition Center of Excellence at the Space and Missile Systems Center, Los Angeles Air Force Base, in technical baseline development, acquisition planning, and source selection. She joined Aerospace in 2000 after serving 11 years in the Air Force. She has a B.S. in astronautical engineering from the U.S. Air Force Academy and an M.S. from Chapman University.
Senior Project Engineer, Engineering and Integration Division, joined Aerospace in 2008 and provides engineering and acquisition consultation to the Space and Missile Systems Center at Los Angeles Air Force Base. Belanger previously worked as a NASA program manager for the commercial orbital transportation services program. He is a retired naval flight officer with 28 years of active duty experience, is a graduate of the Industrial College of the Armed Forces, and has completed senior acquisition courses.
Ray G. Bonesteele
Senior Project Leader, Engineering and Integration Division, supports the Acquisition Center of Excellence at the Space and Missile Systems Center, Los Angeles Air Force Base, primarily planning and coordinating independent program assessments. Before joining Aerospace in 2004, he served for 24 years in the Air Force. He has a Ph.D. in meteorology from St. Louis University, specializing in Doppler weather radar detection of severe thunderstorms.
Andy T. Guillen
Systems Director, Engineering and Integration Division, joined Aerospace in 1980 supporting government multiagency and multinational programs. His experience includes system engineering, system acquisition, program management, and structural mechanics. He has a B.S. in mechanical engineering from the Massachusetts Institute of Technology and an M.S. in systems management from the University of Southern California.
Senior Project Engineer, Engineering and Integration Division, joined Aerospace in 2011 and supports the Space and Missile Systems Center at Los Angeles Air Force Base in acquisition development. Since 1980, she has worked in the commercial space industry in the design, manufacturing, integration, and testing of spacecraft for numerous programs. She has a B.S. in aerospace engineering from the University of Southern California and an M.S. in space studies from the University of North Dakota.
Back to the Spring 2013 Table of Contents
Go to sidebar: A Focus on the End User