Middle Tier Requirements

• 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
• For Rapid Fielding, the Top Level Requirements shall include the production quantity required to meet the warfighting need within the first five years of service

• Deputy Chief of Staff for Strategic Plans and Requirements (AF/A5/8) will support development of requirements for rapid acquisition activities.
  • Because rapid prototyping efforts are exempt from the Joint Capabilities Integration and Development System (JCIDS) process, formally-documented requirements are not necessary for these efforts. However, AF/A5/8 will initiate and document initial requirements for subsequent refinement during prototyping whenever possible.
  • Though rapid fielding efforts are also exempt from JCIDS, the A5/8 will provide a streamlined process for requirements validation.
• 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”).
• 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.
• Initial requirements for rapid prototyping efforts should typically be validated no later than one year after initiation, but are not mandatory.
• Rapid fielding efforts should consider the potential of existing products, proven technologies, and/or demonstrated processes to meet an existing or emerging capability gap or create future operational opportunities.
• Requirements for rapid fielding efforts must be validated by the CSAF or designated representative prior to commitment of funds unless waived by the SAE.

For Rapid Prototyping, the effort might precede a validated requirement and, in fact, may inform the requirement. Although the MTA authority is not subject to JCIDS, the acquisition team must have an approved requirement within 6 months from the time that the MTA process is initiated. The PEO/PM will collaborate with HODA to assist with rapidly staffing the requirement across the enterprise to reduce risk and facilitate information sharing prior to approval. As prototyping matures, a re-validation of the requirement may be justified and documented.

The prototyping effort should begin with the most difficult requirements first. This allows for early confirmation that the prototype project is achievable, directs the effort toward a different technology, or informs program termination. Prototyping should have well defined outputs that can be assessed with Soldier Touch Points and/or experimentation. This will be used to inform, in as quantifiable manner as possible, a recommendation made by the PM, with CFT input where applicable. The recommendation should inform the DA, who then decides to proceed, adjust or terminate the prototyping effort.

UPDATE: Per Jun 2019 AFC Memo, Abbreviated Capability Development Documents (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. 

Effectively scoping a program, increment, or release is a critical element to being able to deliver capabilities in a timely manner. Far too many programs attempt to do too much at once which risks delivering any capabilities. The key is to scope the work that leverages mature technologies, is affordable within the available budget, and can realistically be delivered within the desired/needed timelines. To help meet expected delivery dates, some degree of flexibility is needed in the requirements. The operational command or business unit should convey requirements via high level objectives for the acquiring organization to deliver as much capability as possible based on budgets, schedules, risks, and other factors. The old adage: “Perfect is the enemy of good” applies to program scope and requirements; it’s better to have an 80% solution today than risk the entire program trying to get it perfect. If your program is under pressure to deliver sooner, ask yourself: What functionality could be removed or deferred and still achieve the desired outcomes? If you effectively scope the program and manage requirements as outlined below, you should be able to regularly deliver capabilities.

Guiding Principles

• The smaller the scope, the faster the delivery – 80% solution today!
• Smaller requirements documents = rapid – Don’t overly define the solution
• Deliver a Minimum Viable Product (MVP) ASAP to validate learning about how well the product aligns with user needs.
• Operational sponsors capture high level objectives via short summaries
• Empower a “product owner” to set vision, shape requirements, and collaborate with users, acquirers, developers
• Lower level requirements must remain dynamic
• Requirements for current release should leverage only mature technologies/COTS solutions, iterate on future developments
• Visit operational commands to meet face-to-face with many end users to understand their environment, frustrations with legacy systems, constraints, new threats, and priorities.