Middle Tier of Acquisition (MTA)

AAF  >  MTA Rapid Prototyping Path > Requirements

Requirements

How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: DoDI 5000.80, Paragraph 3.1.a

 

Operational Needs. DoD Components will develop a merit-based process for the consideration of innovative technologies and new capabilities to meet needs communicated by the Joint Chiefs of Staff and the Combatant Commanders. This process will result in an approved requirement and a DA signed acquisition decision memorandum (ADM) that validates the rationale for using the MTA pathway and identifies the full funding required.

 

Reference Source: DoDI 5000.80, Paragraph 1.2.f

 

Each DoD Component will develop a streamlined process that results in a succinct requirement document no later than 6 months from the time the operational needs process is initiated. Approval authorities for each capability requirement will be delegated to a level that promotes rapid action.

 

Reference Source: DoDI 5000.80, Paragraph 4.1

 

[For major systems,] CAEs will ensure the approved requirement document is available in the Knowledge Management and Decision Support system.

Check out the MTA FAQs and MTA Tips for potentially related questions from the field and helpful tips!

Reference Source: DoD Prototyping Handbook, Nov 2019

Identifying Military Capability Gaps for Prototyping Projects

Prototyping should start with a clear understanding of why the prototype is being developed. For projects in which the objective is to push the boundaries of technology, the purpose could come in the form of a statement of intent by the researcher or an emerging need not yet formally recognized by the Department. However, for projects seeking to directly support an operational mission, the purposes will come in the form of an identified existing or emerging military capability gap.

Military capability gaps can be obtained from numerous sources. Certainly, the most obvious are validated requirements that are documented through formal processes. Examples include requirements listed in approved Joint Capabilities Integration and Development System documents and strategic needs recorded in the following documents:

  • The 2018 National Defense Strategy;
  • The USD(R&E)’s Road to Dominance modernization priorities;
  • The Chairman’s Risk Assessment; and
  • The Joint Requirements Oversight Council-led Capability Gap Assessment.

Formal requirements also include capability gaps that have been validated by Components or the Joint Staff and documented by Joint or Military Services’ requirements processes, such as Integrated Priority Lists (IPL) and Initial Capability Documents. In addition, for urgent requirements, warfighters can use their Components’ urgent needs processes or work through the Joint Staff’s urgent needs process in which Combatant Commands, the Chairman of the Joint Chiefs of Staff, or the Vice Chairman of the Joint Chiefs of Staff can submit Joint Urgent Operational Needs Statements and Joint Emergent Operational Needs Statements.

Unlike formal acquisition programs, however, prototyping is often not bound by traditional Joint or Military Service requirements processes. In fact, the NDS encourages the use of prototyping prior to defining requirements. Rather, prototyping projects can be initiated using military capability gaps identified and provided by the warfighter, outside of Joint and Military Services’ requirements processes. Sources for these gaps include critical intelligence parameter breaches; emerging needs that are identified through threat, intelligence, and risk assessments; and offsetting or disruptive needs that are identified through experiments, demonstrations, and exercises.

Best Practices for Identifying Military Capability Gaps for Prototyping Projects

Reference Source: DoD Prototyping Handbook, Nov 2019

The following are best practices noted by SMEs that pertain to identifying military capability gaps for prototyping projects:

  • Not only is it important to understand the military capability gap identified, but PMs should also strive to understand why the gap was identified. This additional level of understanding will help ensure the warfighter’s intent is understood, and that the capability developed will fully satisfy the stated capability gap.
  • Regardless of whether the project is based on validated and documented requirements or on less formal military capability gaps, nearly all prototyping SMEs agree that close collaboration with members of the requirements community is critical and should begin as early in the project planning phase as possible. This collaboration is important for several reasons.
    • First, personnel in the requirements community can help define, organize, and clarify the project’s capability gap.
    • Second, personnel in the requirements community can help to identify existing validated requirements that may pertain to the project.
    • Finally, enabling requirements personnel to document the initial capability gaps and refine them as the project progresses can expedite the process if formal requirements are determined to be needed at some point in the future for follow-on production and fielding efforts.

DoD Component Guidance

Note that DoD Component MTA Implementation policies and guidance are currently being updated to be consistent with the newly published DODI 5000.80 (effective 30 Dec 2019). 

Air Force

Reference Source: Air Force Guidance Memorandum for Rapid Acquisition Activities, 27 June 2019

 

Section 3. Rapid Prototyping (Middle Tier)

 

  • 3.3. Rapid acquisition activities should meet needs communicated by the Combatant Commands, Joint Chiefs of Staff, and/or the Air Force in a timely and effective manner. Exemption from JCIDS should not exempt the PM from engaging requirements authorities (e.g. Combatant Commands, Joint Chiefs of Staff, CSAF) to ensure rapid acquisitions either meet current or draft requirements (i.e., “requirements pull”) or might potentially generate a new requirement if successful (i.e., “technology push”).
  • 3.3.1. Rapid prototyping efforts should evaluate the potential of innovative technologies, new capabilities, and/or improved processes to meet existing or emerging capability gaps or create future operational opportunities.
  • 3.3.2. Initial requirements for rapid prototyping efforts should typically be validated no later than one year after initiation, but are not mandatory.

 

Section 5. Documentation

 

  • 5.1.1. Validated requirements should be documented in a previously-approved or subsequently coordinated requirements document. When available, the requirements document should include the system specification sheet as an attachment.

 

AF MTA Requirements Procedures

Reference Source: A5R Requirements Guidebook Vol 5: MTA Requirements Validation Process, 4 Dec 2019

2.1. Process Overview

The process to establish requirements in support of MTA activity is based on the normal requirements process in that it requires analysis to determine the most effective materiel or non-materiel solution based on a valid threat assessment or approved capability gap(s) and it requires proper documentation to deliver capability solutions to the warfighter quickly.

2.2. Initiation of MTA Efforts

Per SAF/AQ direction, all new capability development efforts will be reviewed for Middle-Tier of Acquisition applicability (i.e. capability development activities that can be accomplished within the 5 year timeframe). Other ongoing acquisition efforts may elect to “transition” to take advantage of MTA authorities, and those programs likely some degree of capability analysis, requirements documentation and programming support already in place.

MTA efforts may also be initiated in response to CDC direction (Top-Down) or from MAJCOM/Agency capability development proposals (bottom-up)

2.3. Capability Development Strategy (CDS)

The first steps in developing the CDS are to 1) ensure the MTA effort aligns with overarching AF strategy, capability development guidance and resourcing plans and 2) determine what capability analysis and/or requirements documentation exists (or needs to be developed) in order to support proceeding to MTA.

  • The MAJCOM/Agency Sponsor working through their AF/A5R SME, coordinates with AF/A5RP, AF/A5RA-OAS and AF/A5A to assess the sufficiency of existing analyses and/or requirements documentation that might be used to support of the MTA effort.
  • The Sponsor also assesses available resources in coordination with the Acquisition Program Office, SAF/AQX, SAF/FMB, AF/A8P, and AF/A8X (as appropriate) to determine the amount and timing of funding and other resources available for the MTA effort.
  • The Sponsor provides a presentation to the CDWG and/or CDC that describes how the effort will be integrated within an overall Capability Development Strategy (CDS).
    • NOTE: The purpose of a CDS is to define the overall plan of action and milestones (POAM) that will integrate the lines of effort across requirements, resourcing and acquisition. The CDS includes priorities and tradeoffs, and it needs to be consistent with available resources (both timing and amount of funding, manpower, basing strategies, etc.)

2.4. Documentation of Requirements to Support MTA

Following CDWG and/or CDC approval of the CDS and the path forward, the MAJCOM/Agency Sponsor, working through their AF/A5R SME and in coordination with AF/A5RP determines the appropriate requirements documentation to support the MTA activity.

  • Sponsors have the option to use an existing requirements document(s) to support the MTA process (subject to AF/A5RP approval), or they can create a new MTA requirements document.
  • An existing requirements document may include any previously validated requirements document(s) or a draft currently under development (in which case the Sponsor could continue staffing the current document through to validation in support of MTA rather than starting over with a new MTA document). AF/A5RP determines the level of review and approval necessary to use any existing draft or previously validated requirements document(s) in support of MTA activity. AF/A5RP notifies SAF/AQX directly of any decision to approve or deny the proposed use of existing requirements documents to support MTA activity.
  • If use of an existing requirements document is not deemed appropriate, the MAJCOM/Agency Sponsor can elect to develop a new MTA Requirements document; either a Rapid Prototyping Requirements Document (RPRD) or a Rapid Fielding Requirements Document (RFRD), as appropriate (format and content for the RPRD and RFRD are described in section 3 of this Guidebook).

Following development of the draft version of the RPRD or RFRD, and upon approval by the MAJCOM/Agency Director of Requirements (or higher), the sponsor submits the document to AF/A5RP via IRSS for entry into staffing.

  • AF/A5RP in consultation with the AF/A5R SME conducts initial AFGK checks to determine if the document is ready to enter into staffing.
  • A tailored staffing period will be conducted utilizing IRSS tasking procedures on SIPRNET.
  • AF/A5RP will also forward the document to the J8 Gatekeeper for Joint Staff awareness. Should Joint Staff determine that Joint equity exists, the Sponsor may continue to proceed with MTA activities while Joint equities are being outlined and a Joint approach is developed, if required.

Following the tailored staffing period, the Sponsor completes comment adjudication and any internal MAJCOM/Agency review process, then submits a final version of the document via IRSS for HAF review and validation staffing. Working with the AF/A5R SME, AF/A5RP prepares the staff package for review by the designated Requirements Decision Authority.

Following validation and approval by the appropriate Requirements Decision Authority, AF/A5RP uploads the final version of the approved document along with the decision memo to IRSS and forwards a copy directly to SAF/AQX.

2.5. Prototyping Analysis Report

For Rapid Prototyping MTA efforts, once the prototyping effort is complete, the sponsor in coordination with the program office, submits a summary report of the prototyping findings to AF/A5R, AF/A5A and SAF/AQX and attaches it to the original document record in IRSS. The report should contain the following information:

  • Summary of original prototyping phase goals/objectives.
  • Summary of prototyping findings, including assessment of the ability to address the validated gaps and any findings not directly related to original gap(s).
  • Schedule summary (did the original schedule hold true?).
  • Prototyping funding summary.
  • Earned Value Management analysis.

CDWG and/or CDC review the report and, in coordination with AF/A5R and SAF/AQX, make an assessment for continuation of capability development efforts consistent with the Capability Development Strategy.

 

AF Rapid Prototyping Requirements Document (RPRD): Document Format

Reference Source: A5R Requirements Guidebook Vol 5: MTA Requirements Validation Process, 4 Dec 2019

Below is the format for the RPRD. Sponsors should refer to the CDD format and content guidelines found in the JCIDS Manual for additional information on how to develop each section of the RPRD.

Cover Page:

  • Classification
  • Title starting with the phrase “Rapid Prototyping Requirements Document for…”
  • Date submitted by the sponsoring organization
  • Proposed MDA
  • Proposed RDA
  • Document revision number
  • Primary and secondary POCs for the document sponsor. Include name, title/rank, phone and both NIPRNET and SIPRNET email addresses.

Validation Page: placeholder for decision memo

  • While in draft, a placeholder page will be included, with a statement of: “This document (include revision numbering) has not yet been validated and shall not be considered an authoritative source for the content herein. This document may be considered authoritative only when this page is replaced by a signed validation memorandum from the appropriate validation authority.”
  • Once validated by the validation authority, the placeholder page will be replaced by the signed memorandum indicating validation of the document.

Commander’s Intent and Executive Summary:

  • Sponsor’s explanation of why this effort is a candidate for rapid prototyping. Briefly discuss the schedule to achieve a residual capability and a description and definition of what the successful demonstration of this new materiel solution will look like.

Document Body:

Section 1: Operational Context, Challenge and Anticipated Threats.

    • Provide a summary of the operational context and challenge to be addressed, explaining how the capability solution will contribute to the missions and activities of the Air Force or meet an identified operational challenge within the context of the anticipate threat environment.
    • Describe the timeframe under consideration and the overall operational risk and priority to the Air Force.
    • Consider evolving threats to on-going and follow-on RDT&E, production, and O&M resulting from technology transfer, espionage, and other adversarial collection efforts.
    • Summarize approved Critical Intelligence Parameters (CIPS), or information from Classified Information Compromise Assessment (CICA) which could critically impact the effectiveness and survivability of the proposed system.
    • Cite the latest DIA or Service-approved threat products used during the development of this document.

Section 2: Capability Requirements and Gaps/Opportunities.

    • The purpose of this section is to identify the mission needs/capability requirements and associated gaps, challenges or opportunities to be addressed by the proposed solution(s) and to outline the results of related analyses or studies conducted to determine the mission needs/required capabilities and gaps or opportunities and derive the required system-level performance attributes.

Section 3: Required System Attributes.

    • The purpose of this section is to outline the system level performance attributes that are necessary to address the capability requirements, gaps or opportunities or which are otherwise critical or essential to achieve mission goals and objectives.
    • System attributes must be assigned and have sufficient granularity to support contracting actions. Avoid over specification or inclusion of technical specifications.
    • Provide measures for each attribute in terms of threshold values or initial objective values as appropriate, to indicate the acceptable level of performance for the residual capability to be effective in an operational environment (as is required by MTA/804 authority).
    • Define other system attributes (as applicable). See the JCIDS Manual for examples.

Section 4: Interoperability & Supportability.

    • The purpose of this section is to specify how the individual system will operate within the Joint environment, including any physical or net-ready interoperability effects on joint or allied operations. Include factors that impact both the Air Force internally as well as outside agencies and programs.
    • Include any requirements for electromagnetic (EM) spectrum and environmental effects controls.
    • Include any requirements for intelligence supportability.
    • Include information or attributes for modular open system architecture (MOSA) or exportability that may impact future decisions about development, fielding, follow-on production, joint training, etc.
    • Include requirements for Weapons Safety Assurance (as required for munitions systems)
    • Outline non-materiel (DOTMLPF-P) changes that need to be made in order to successfully implement fielding of the residual capability in an operational environment. Address both a) changes that enable implementation, operations and support of the system and b) changes that must be made to support integration of the system with other fielded capabilities.

Section 5: Resourcing and Schedule.

    • The purpose of this section is to identify the overall resourcing plan and schedule of activities to provide the capability solution and highlight any challenges or risks to the planned timelines. Highlight any technology challenges that may impact the feasibility of meeting the timelines or providing a usable capability within the timeline.

Architecture Products (determined by the Program manager).

Army

Reference Source: ASA(ALT) Middle Tier of Acquisition Policy, 20 March 2020, Enclosure 1

 

Operational Needs.  The MTA program initiation process will result in an approved requirement and an Army Acquisition Executive (AAE)-signed Acquisition Decision Memorandum (ADM) that validates the rationale for using the MTA pathway and identifies the full funding required.

 

An approved requirements document such as Abbreviated Capability Development Document or Initial Capability Refinement Document is required.

 

Abbreviated Capability Development Documents (A-CDD)

Summary: The A-CDD can be used as the source requirement to execute rapid experimentation and prototyping efforts prior to program initiation IAW Section 804 Middle Tier of Acquisition. In an A-CDD, all CDD paragraphs must be accounted for, however the content for each section/paragraph does not have to be at the maturity level for a final CDD.

Reference Source: Army Futures Command (AFC) Refinement of the Abbreviated Capability Development Document (A-CDD) Guidance Memo, 11 Aug 2020

 

Background. A-CDDs are not constrained by Joint Capabilities Integration and Development System Integration and Development System (JCIDS) or acquisition policy.

 

  • The Army has elected to use a similar construct to the Capability Development Document (CDD) for document development to enable rapid prototyping, testing, experimentation, demonstration or rapid fielding efforts.
  • A-CDDs will provide sufficient technical, operational and analytical background or context to enable rapid prototyping and experimentation needed, but remain flexible in describing “Desired” characteristics/attributes vice “Threshold and Objective Key Performance Parameters or Key System Attributes.”

 

A-CDD. The A-CDD is a capability document used to establish the Army’s position on development of an Army materiel capability. The approval validation of an A-CDD initiates materiel development within the Middle Tier Acquisition (MTA) process.

 

  • A-CDDs offer numerous options for enabling an acquisition decision. (Figure 1)

An A-CDD can inform numerous Acquisition decisions within the Adaptive Acquisition Framework (AAF). Image with three parallel lines. The first parallel line represents MTA, and there is a stand-alone box for Rapid Prototyping and a stand-alone box for Rapid Fielding. The third parallel line represents MCA, and it includes adjacent boxes to represent the MCA phases (Materiel Solution Analysis, Technology Maturation & Risk Reduction, Engineering & Manufacturing Development, Production & Development). The second parallel line is between these two and represents the A-CDD insertion points. The MCA milestones are listed (MDD, MS A, MS B, CDD, MS C, IOC, and FOC) with arrows showing the A-CDD can be inserted between MDD and MS A, between MS A an MS B, between MS B and MS C/CDD, and after CDD.

  • Approval of an A-CDD does not necessarily lead to a Materiel Development Decision (MDD) or acquisition milestone decision (MS A, MS B, or MS C).
  • A-CDDs provide the source desired (proposed required) capabilities and characteristics to execute rapid experimentation and prototyping efforts prior to formal program initiation.
  • The A-CDD that demonstrates successful rapid experimentation and prototyping, while clearly defining the desired capability, will enable the documentation and fielding of a residual combat capability or the development of a CDD for acquisition decision.

 

Approval. The Quick-Fire Process is an approved pathway to instantiate a materiel capability and the supporting A-CDD. A-CDDs are a pathway to execute rapid experimentation and prototyping efforts using Mid-Tier Acquisition (MTA) authorities.

 

Format. The A-CDD format will follow the JCIDS Manual Appendix C to Enclosure B (CDD), paragraph 2 (reference e). All CDD paragraphs are not required for an A-CDD and those paragraphs addressed do not have to be at the maturity level for a final CDD. Many of the CDD paragraphs may not be applicable or known until prototyping and experimentation are complete. To transition the capability into the Defense Acquisition System, the A-CDD must be converted into a formal CDD. Examples of key differences between an A-CDD and a complete CDD are shown in the table below:

 

Paragraph in CDD A-CDD Rationale for Differences
4. Program Summary 4. Prototype Summary

·      The A-CDD will not generate an acquisition program

·      It is designed to underpin rapid prototyping/experimentation

·      IOC and FOC are not germane (except for rapid fielding initiatives) thus A-CDDs describe the scope of the prototyping effort

·      How many, what will be prototyped, is it a full-up prototype, will it be models and simulation event, etc

5. Performance Attributes (KPPs, KSAs, and APAs) 5. Desired characteristics

·      The A-CDD defines the baseline or initial minimum value and sponsors allow technology to define upper limit rather than imposing an unnecessary objective

·      Only define an objective for the desired characteristic when it provides useful framing for the Program Manager

·      Desired characteristics are a single list of “desirements” that sponsors seek to prove out through rapid prototyping and experimentation including soldier touch points

13. Program Affordability 13. Prototyping Summary

·      There is no formal acquisition program at the time an A-CDD is approved

·      Sponsors should submit the same resources required table as a CDD, but focus on cost of prototyping and experimentation

·      Prototyping costs may be used to inform program affordability

·      This is in line with the “buy, try and decide” methodology the Army adopted to reduce risk in acquisition programs

Navy

Capability Requirements

Reference Source: ASN(RDA) Middle Tier Acquisition and Acquisition Agility Guidance, 24 April 2018

  • All Middle Tier acquisition projects shall have documented capability requirements, not more than six months from when the project was initiated, from the requirement community.
  • At a minimum, a Top Level Requirements Documentation will outline the minimum viable product that is acceptable to the operational force

SOCOM

Reference Source: USSOCOM Middle Tier Acquisition Authorities and Guidance, 1 Aug 2018

Stakeholder Analysis: As with all SOF AT&L acquisition efforts, the Acquisition Team is expected to understand the required capability, whether formally stated or not, of the user community represented by the HQ, Components and TSOCs. For an MTA strategy to be applicable, the capability must be simultaneously well defined and broadly defined. A capability that is either defined too tightly or is subject to deviations or growth over time will negate the Acquisition Team’s ability to pursue an MTA strategy. The team must also understand the current maturity of technology within industry, labs, academia and the Services. When the Acquisition Team sees an opportunity to satisfy a known requirement with a technology that could be prototyped and/or fielded within five years, they should pursue an MTA strategy in support of the Capability Sponsor.

Requirements Validation: For Rapid Prototyping, the effort might precede a validated requirement and, in fact, may inform the requirement. 

Additional Resources