Back to Top

Educating the Aerospace Industry

Blog Archives

Acquisition Process

Technology Readiness Assessment (TRA)

 

A Technology Readiness Assessment (TRA) is a formal, metrics-based process and accompanying report that assesses the maturity of critical hardware and software technologies called Critical Technology Elements (CTE) to be used in systems. It is conducted by an Independent Review Team (IRT) of subject matter experts (SMEs). All DoD acquisition programs must have a formal TRA at Milestone B and at Milestone C. A preliminary assessment is due for the Development RFP Release Decision Point. [2]

 

Guide: Technology Readiness Assessment Deskbook -May 2011

Guide: GAO Technology Readiness Assessment Guide – Aug 2016

 

The TRR is statutory requirement for Major Defense Acquisition Programs (MDAP) per DoD Instruction 5000.02, Enclosure 4, and a regulatory information requirement for all other acquisition programs. Title 10 United States Code (U.S.C.) Section 2366b requires, in part, that the Milestone Decision Authority (MDA) certify that the technology in an MDAP has been demonstrated in a relevant environment and has a Technology Readiness Levels (TRL) of (TRL 6) before Milestone B approval. [2]

 

The TRA may be conducted concurrently with other technical reviews such as the Alternative Systems Review (ASR), System Requirements Review (SRR), or the Production Readiness Review (PDR). The Defense Director for Research and Engineering (DDR&E) is required to conduct an independent TRA of MDAPs prior to Milestone B. [1]

 

The TRA should be used a tool for assessing program risk and the adequacy of technology maturation planning. The TRA scores the current readiness level of selected system elements, using defined Technology Readiness Levels (TRL). Completion of the TRA should provide the following: [1]

  1. A comprehensive review, using an established program Work Breakdown Structure (WBS) as an outline, of the entire platform or system. This review, using a conceptual or established design, identifies program CTEs,
  2. Objective scoring of the level of technological maturity for each CTE by subject matter experts,
  3. Maturation plans for achieving an acceptable maturity roadmap for CTEs before critical milestone decision dates,
  4. A final report documenting the findings of the assessment panel.

 

TRAs Inform Technology Development and Identify Potential Concerns

While a TRA uses TRL as key metrics for the evaluation of each technology, an assessment is more than just a single number at only single point in time. It is a compilation of lower-level assessments that could span several years, based on the program schedule and complexity of the development. Evaluations can help gauge the progress of technology development, inform program plans, and identify potential concerns for decision-makers throughout acquisitions. Conducting TRAs periodically and during the earlier phases of development can identify potential concerns before risks are carried into the later and more expensive stages of system development. [4]

 

TRAs can also facilitate communication between technology developers, program managers, and acquisition officials throughout development and at key decision points by providing a common language for discussing technology readiness and related technical risks. Finally, TRA results can inform other assessments and planning activities, such as cost and schedule estimates, risk assessments, and technology maturation plans. [4]

 

Program Managers (PM) have found that the TRA assessment process is useful in managing technology maturity. The TRA process highlights critical technologies and other potential technology risk areas that require the PM’s attention. The TRA can help identify immature and important components and track the maturity development of those components. Some programs use TRAs as an important part of their risk assessment.

 

STATUTORY:  A preliminary assessment is due for the Development RFP Release Decision Point. The Assistant Secretary of Defense for Research and Engineering (ASD(R&E)) will conduct an independent review and assessment of the TRA conducted by the Program Manager and other factors to determine whether the technology in the program has been demonstrated in a relevant environment. The assessment will inform the 2366b CERTIFICATION MEMORANDUM at Milestone B (in accordance with 10 U.S.C. 2366b (Reference (g)). The TRA at Milestone C is a Regulatory requirement when Milestone C is Program Initiation. [3]

 

Detailed information about the TRA and its process and procedures can be found in the Technology Readiness Assessment Deskbook. The content of the Deskbook is listed below:

 

TRA Deskbook Content
1.     Introduction
1.1     Technology Readiness Assessment Definition
1.2     TRA Authority
1.3     TRA Importance
1.3.1     Milestone B TRA
1.3.2     Milestone C TRA
1.4     Purpose and Organization of This Document
2.     Initiating and Conducting TRAs
2.1     Key Players and the TRA Timeline
2.2     Roles and Responsibilities
3.     Evolution of Knowledge on Technology Maturity
3.1     Early Evaluations of Technology Maturity
3.2     Summary List of Acronyms

Appendixes
A.     Submitting a Technology Readiness Assessment
B.     Guidance and Best Practices for Identifying Critical Technology Elements (CTEs)
C.     Guidance and Best Practices for Assessing Technology Maturity
D.     Amplifying Technology Readiness Assessment Guidance for Ships
E.     Biomedical Technology Readiness Levels
F.     Technology Maturity Policy
G.     The Technology Readiness Assessment Process
H.     Easy-Reference Displays of the Hardware/Software TRLs and Additional TRL Definitions

 

AcqLinks and References:

Updated: 4/10/2021

Acquisition Process

Analysis of Alternatives (AoA)

 

An Analysis of Alternatives (AoA) is an analytical comparison of the operational effectiveness, suitability, and life-cycle cost of alternatives material solutions that satisfy an established capability need to be identified in an Initial Capabilities Document (ICD). It focuses on the identification and analysis of alternatives, Measures of Effectiveness (MOE), schedule, Concepts of Operations (CONOPS), and overall risk.  An AoA also assesses Critical Technology Elements (CTEs) associated with each proposed material solution, including; technology maturity, integration risk, manufacturing feasibility, and technology maturation and demonstration needs.

 

Instruction: DoD Instruction 5000.84 “Analysis of Alternatives”

Handbook: Analysis of Alternatives (AoA) Handbook – July 2016

Outline: Recommended Outline for the AoA Plan

 

The AoA is conducted during the Materiel Solution (MS) Phase before Milestone A. The final AoA supporting a Milestone A decision is provided to the Director of Cost Assessment and Program Evaluation (DCAPE) not later than 60 days prior to the milestone decision review meeting. The DCAPE normally develops and approves AoA Study Guidance. [1]

 

The Technology Development Strategy (TDS) should highlight how the risks identified in the AoA areas are going to be addressed and minimized in the Technology Maturation & Risk Reduction (TMRR) Phase and on the path to full manufacturing capability in the Production and Deployment (PD) Phase.

 

An AoA should be updated and performed in each acquisition phase and throughout the lifecycle of a program to guarantee that the correct material solution is being developed.  The update should be used to refine the proposed material solution and reaffirm the rationale in terms of cost-effectiveness.

 

For Major Defense Acquisition Programs (MDAP) at Milestone A, the Milestone Decision Authority (MDA) must certify in writing to Congress that the Department has completed an AoA consistent with study guidance developed by the Director of Cost Assessment and Program Evaluation (DCAPE).  For MDAPs at Milestone B, the MDA must certify in writing to Congress that the Department has completed an AoA with respect to the program. [1]

 

An AoA provides input into an Alternative Systems Review (ASR). Completion of the ASR should provide the following information from an AoA: [1]

  • A comprehensive rationale for the proposed materiel solution(s), based upon the AoA that evaluated relative cost, schedule, performance (hardware, human, software), and technology risks.
  • See Risk Management Overview

 

STATUTORY: for MDAP, Major Automated Information System (MAIS) programs, and all Automated Information Systems (AIS) programs, including National Security Systems (NSSs), at Milestone A. Updates required through Milestone C (or Milestone B if there is no Milestone C) for MAIS programs, and all AIS programs.

 

REGULATORY: for all other specified Program Type/Event combinations.

 

Analysis of Alternatives (AoA) Study Guidance
For potential and designated ACAT I and IA programs, the Director for Cost Assessment and Program Evaluation (DCAPE) prepares study guidance for Milestone Decision Authority (MDA) review and approval at the Materiel Development Decision (MDD).

 

AcqTips:

  • The Milestone Decision Authority will determine if a new or updated AoA is needed after Milestone A. Make sure you know the AoA requirements during each phase.

AcqLinks and References:

Updated: 5/22/2018

Acquisition Process

Initial Operational Test and Evaluation (IOT&E)

 

The Initial Operational Test and Evaluation (IOT&E) is conducted on production, or production representative articles, to determine whether systems are operationally effective and suitable for intended use by representative users to support the decision to proceed beyond Low-Rate Initial Production (LRIP).

 

The IOT&E will normally test the values in the Capability Production Development (CPD). The threshold and objective values from the Capability Development Document (CDD) are, therefore, superseded by the specific production values detailed in the CPD. Reduction in any Key Performance Parameters (KPP) threshold value will require a reassessment of the military utility of the reduced capability. [1]

 

The Operational Test Readiness Review (OTTR) is conducted to determine if a system can proceed into IOT&E. Once approved, an IOT&E must be completed before the Full Rate Production Decision (FRPD). More than one IOT&E may be conducted on the system if there are system performance problems requiring retest, the system is decertified, or a need exists to test in different environments   IOT&E is conducted by an Operational Test & Evaluation (OT&E) agency independent of the contractor, Program Management Office (PMO), or developing agency. Title 10 USC 2399 requires DoD to conduct an independent, IOT&E on major programs (Acquisition Category (ACAT) I & II) before entering Full-Rate Production (FRP).

 

IOT&E is conducted to: [1]

  1. Estimate the Operational Effectiveness and Suitability of the system;
  2. Identify operational deficiencies;
  3. Evaluate changes in production configuration;
  4. Provide information for developing and refining logistics support requirements for the system and training, tactics, techniques, and doctrine;
  5. Provide information to refine Operations and Support (O&S) cost estimates and identify system characteristics or deficiencies that can significantly impact O&S costs;
  6. Determine whether the technical publications and support equipment are adequate in the operational environment.

Before the certification of readiness for IOT&E, the developer should have obtained the Joint Interoperability Test Command’s (JITC)’s certification of interoperability for the system components. In parallel with IOT&E, Live-Fire Test and Evaluation (LFT&E) may be used to evaluate the vulnerability or lethality of a weapon system as appropriate and as required by public law. The PM’s briefing and the Beyond Low-Rate Initial Production (BLRIP) report address the risks of proceeding into Full Rate Production (FRP). [1]

 

Each Service has different and specific processes incorporated in the certification for IOT&E documentation. The Navy conducts additional DT&E for certification called TECHEVAL (Technical Evaluation). This is a DT&E event controlled by the program office that is conducted in a more operationally realistic test environment. The Air Force has developed a guide [2] with a structured process using templates to assist the Program Manager (PM) in assessing the program’s readiness for IOT&E.

For the Navy, see Operational Evaluation (OPEVAL).

 

AcqLinks and References:

Updated: 8/01/2019

Acquisition Process

Middle Tier Acquisition (Section 804)

 

Middle Tier Acquisition (MTA) is a rapid acquisition interim approach that focuses on delivering capability in a period of 2-5 years. The interim approach was granted by Congress in the FY16 National Defense Authorization Act (NDAA) Section 804 and is not be subject to the Joint Capabilities Integration Development System (JCIDS) and DOD Directive 5000.01 “Defense Acquisition System”.   The approach consists of utilizing two (2) acquisition pathways: (1) Rapid Prototyping and (2) Rapid Fielding.  It does this by streamlining the testing and deployment of prototypes or upgrading existing systems with already proven technology.

 

Instruction: DoD Instruction 5000.80 “Operations of the MTA”

 

(1) Rapid Prototyping

Use innovative technology to rapidly develop fieldable prototypes to demonstrate new capabilities, meet emerging military needs. The objectives are:

  • Field a prototype that can be demonstrated in an operational environment
  • Provide for residual operational capability within 5 years of an approved requirement

 

(2) Rapid Fielding

Use proven technologies to field production quantities of new or upgraded systems with minimal development required. The objectives are:

  • Begin production within 6 months
  • Complete fielding within 5 years of an approved requirement

Table: Summary of NDAA 2016, Section 804 Statutory Language

Funding

  • Organizations must make use of their existing funding consistent with the purpose ofr which the funds were appropriated.
  • Interim authority does not cover the establishment of Rapid Prototyping Fund
  • Rapid Prototyping Fund will be authorized when approved by organizations responsible for those authorities.

AcqLinks and References:

Updated: 9/18/2020

Acquisition Process

Preliminary Design Review (PDR)

 

The Preliminary Design Review (PDR) is a technical assessment that establishes the Allocated Baseline of a system to ensure a system is operationally effective.  A PDR is conducted before the start of detailed design work and is the first opportunity for the Government to closely observe the Contractor’s hardware and software design.  This review assesses the allocated design documented in subsystem product specifications for each configuration item in the system and ensures that each function, in the Functional Baseline, has been allocated to one or more system configuration items. The PDR establishes the allocated baseline (hardware, software, human/support systems) and underlying architectures to ensure that the system under review has a reasonable expectation of satisfying the requirements within the currently allocated budget and schedule.

 

Acquisition System

 

For complex systems, a PDR may be conducted incrementally for each configuration item. These incremental reviews lead to an overall system-level PDR. System-level performance is supported by compliance with Interface Control Documents, but not assured. Interface requirements make up each configuration item Allocated Specification.

 

The Weapons System Acquisition Reform Act of 2009 directed the PDR to: 

  • PDRs before Milestone (MS) B is mandatory for all Major Defense Acquisition Programs (MDAP) and will be reflected in the Technology Development Strategy (TDS) to be approved by the MDA at MS A. Post-PDR assessments will be conducted in association with MS B preparations and will be formally considered by the Milestone Decision Authority (MDA) at the MS B certification review.
  • The timing of PDRs for other than MDAPs will be approved by the DoD Component MDA when consistent with TDS or Acquisition Strategy objectives. When the PDR is conducted before MS B, a post-PDR assessment will be conducted in association with the MS B review and formally considered by the MDA at the MS B review. If the PDR is conducted after MS B, the MDA will conduct a post-PDR assessment at a time reflected in the approved acquisition strategy.
  • PDR before MS B is now a statutory requirement for MDAPs. The post-PDR assessment will be conducted during the MS B review, and prior to the section 2366b certification by the MDA per title 10, Unites States Code.

 

Completion of the PDR should provide the following:

 

AcqTips:

  • The Program Manager (PM) should conduct the PDR when all major design issues have been resolved and work can begin on the detailed design. The PDR should address and resolve critical, system-wide issues.
  • IEEE 5288.2 “Standard for Technical Reviews and Audits on Defense Programs” is the standard for technical reviews and audits to be performed throughout the acquisition life cycle for the US Department of Defense (DoD) and other defense agencies. This standard guides the DoD and contractor on what is required during an SRR
  • The PDR should be conducted when the allocated baseline has been achieved, allowing the detailed design of hardware and software configuration items to proceed. A rule of thumb is that 10 percent to 25 percent of product drawings and associated instructions should be complete and that 100 percent of all safety-critical component (Critical Safety Items and Critical Application Items) drawings are complete.

AcqLinks and References:

Updated: 5/23/2020

Acquisition Process

Critical Design Review (CDR)

 

A Critical Design Review (CDR) is a multi-disciplined technical review to ensure that a system can proceed into fabrication, demonstration, and test and can meet stated performance requirements within cost, schedule, and risk.  A successful CDR is predicated upon a determination that the detailed design satisfies the Capabilities Development Document (CDD).  Multiple CDRs may be held for key Configuration Items (CI) and/or at each subsystem level, culminating in a system-level CDR. The CDR is conducted during the Engineering & Manufacturing Development (EMD) Phase and when the product baseline has been achieved and the CDR entrance criteria detailed in the Systems Engineering Plan (SEP) have been met, allowing fabrication of hardware and coding of software deliverables to proceed.

 

Acquisition System

 

Fact Sheet: DoD Critical Design Review (CDR)

 

 A CDR assesses the system’s final design as captured in product specifications for each Configuration Item in the system’s baseline and ensures that each configuration item has been captured in the detailed design documentation. The resulting set of detailed drawings and specifications establish an initial product baseline, with a final baseline incorporating any design changes resulting from System Demonstration and Initial Operational Test and Evaluation (IOT&E).  The completion of CDR usually initiates the start of formal Configuration Management (CM) by the Contractor of the Technical Baseline.  Any changes to that baseline can only be accomplished with the approval of the Government.

 

A CDR should: [1]

  • Determine that the detailed design of the configuration item under review satisfies cost (for cost-type contracts), schedule, and performance requirements.
  • Establish detail design compatibility among the configuration item and other items of equipment, facilities, computer software, and personnel.
  • Assess configuration item risk areas (on a technical, cost, and schedule basis).
  • Assess the results of producibility analyses conducted on system hardware.
  • Review preliminary hardware product specifications.
  • Determine the acceptability of the detailed design, performance, and test characteristics of the design solution, and on the adequacy of the operation and support documents.

 

Completion of CDR should provide: [1]

  1. A system initial Product Baseline,
  2. An updated risk assessment for Engineering & Manufacturing Development (EMD),
  3. An updated Cost Analysis Requirements Description (CARD) based on the system product baseline,
  4. An updated program development schedule including fabrication, test, and evaluation, and software coding, critical path drivers, and
  5. An approved Life-Cycle Sustainment Plan (LCSP) updating program sustainment development efforts and schedules based on current budgets, test evaluation results, and firm supportability design features.

 

Post-CDR Assessment
For Major Defense Acquisition Programs (MDAP), the Deputy Assistant Secretary of Defense (Systems Engineering) “DASD(SE)” will assess the design maturity and technical risks evident in the CDR. Program Managers (PM) of these programs are required to invite DASD(SE) engineers to their system-level CDRs and make available CDR artifacts. These will include all CDR briefings and those artifacts that constitute the initial product baseline.
[1]

 

AcqTips:

  • The CDR chairperson should tailor the review to the technical scope and risk of the system, and address specifics of the CDR in the Systems Engineering Plan (SEP).
  • IEEE 15288.2 “Standard for Technical Reviews and Audits on Defense Programs” is the standard for technical reviews and audits to be performed throughout the acquisition life cycle for the US Department of Defense (DoD) and other defense agencies. This standard guides the DoD and contractor on what is required during a CDR
  • See Major Reviews

AcqLinks and References:

Updated: 3/03/2021

Acquisition Process

Milestone C

 

Milestone C (MS C) is a Milestone Decision Authority (MDA) led review at the end of the Engineering and Manufacturing Development (EMD) Phase of the Defense Acquisition Process.  Its purpose is to make a recommendation or seek approval to enter the Production and Deployment (PD) Phase.  A milestone marks the start/or finish of a phase and has defined Entrance and Exit Criteria.

 

Acquisition System

Figure: Defense Acquisition Process

For a list of mandatory items due at Milestone C, see the Milestone Requirements Matrix

 

Topics that should be addressed during a Milestone C Review include: [1]

 

An MDA-approved update to the Acquisition Strategy is required prior to Milestone C. The Acquisition Strategy should reflect planned efforts to result in the completion of manufacturing development in order to ensure adequate and efficient manufacturing capability and to produce the minimum quantity necessary to provide products or production-representative articles for Initial Operational Test & Evaluation (IOT&E), establish an initial production base for the system; and permit an orderly increase in the production rate for the system, sufficient to lead to Full-Rate Production (FRP) upon successful completion of operational (and live-fire, where applicable) testing. Additionally, the MS C Acquisition Strategy should reflect plans for demonstrating control of the manufacturing process and acceptable reliability, the collection of statistical process control data, and the demonstrating control and capability of other critical processes such as successful IOT&E. [1]

 

Program Support Review
The Program Support Review (PSR) is conducted to provide insight into current and future program execution through detailed analysis using the Defense Acquisition Program Support (DAPS) Methodology. A PSR is designed to assist the Program Managers (PM) and systems engineers prepare for Milestone A, B, and C decision reviews.

 

AcqLinks and References:

Update: 5/24/2018

Acquisition Process

DoD Instruction 5000.02

DoD Instruction 5000.02 "Operation of the Adaptive Acquisition Framework" - 23 Jan 2020

DoD Instruction 5000.02 “Operation of the Adaptive Acquisition Framework” – 23 Jan 2020

 

Update: DoD Instruction 5000.02 “Operation of the Adaptive Acquisition Framework” dated 23 January 2020 has been released.

 

Note: According to Section 1.4 Transition Plan of the new instruction the old DoDI 5000.02 dated Jan 7, 2015 (Change 3 dated 10 Aug 2017) has been renumbered to DoDI 5000.02T. DoDI 5000.02T will remain in effect, with content removed as it’s canceled or transitions to new issuance, as shown in Table 1 of the new DoDI 5000.02. [2]

 

DoD Instruction 5000.02

DoD Instruction 5000.02 “Operation of the Adaptive Acquisition Framework (AAF)” supports the Defense Acquisition System with the objective of delivering effective, suitable, survivable, sustainable, and affordable solutions to the end-user in a timely manner. To achieve those objectives, Milestone Decision Authorities (MDAs), other Decision Authorities (DAs), and Program Managers (PMs) have broad authority to plan and manage their programs consistent with sound business practice. The AAF acquisition pathways provide opportunities for MDAs/DAs and PMs to develop acquisition strategies and employ acquisition processes that match the characteristics of the capability being acquired. [2]

 

 

 


 

DoD Instruction 5000.02T, “Operation of the Defense Acquisition System” (Change 3) – 10 August 2017

DoD Instruction 5000.02T

The Defense Acquisition System is directed by DoD Instruction 5000.02T, “Operation of the Defense Acquisition System” dated (Change 3) August 10, 2017. The instruction provides the policies and principles that govern the defense acquisition system and forms the foundation for all DoD programs that include weapon systems, services, and Automated Information Systems (AIS). It establishes a Management Framework for translating user needs and technology opportunities into stable, affordable, and well-managed acquisition programs. The instruction also identifies the specific statutory and regulatory reports and other information requirements for each Milestone and Decision Point. The instruction is published by the Under Secretary of Defense (USD) for Acquisition and Sustainment (A&S). [1]

 

Table of Content

  1. Purpose
  2. Applicability
  3. Policy
  4. Responsibility
  5. Procedures
  6. Releasability
  7. Effective Date
  8. Enclosures
    1. Acquisition Program Categories and Compliance Requirements
    2. Program Management
    3. Systems Engineering
    4. Developmental Test and Evaluation (DT&E)
    5. Operational and Live-Fire Test and Evaluation
    6. Life-Cycle Sustainment Planning
    7. Human Systems Integration (HSI)
    8. Affordability Analysis and Investment Constraints
    9. Analysis of Alternatives (AoA)
    10. Cost Estimating and Reporting
    11. Requirements Applicable To All Programs Containing Information Technology (IT)
    12. (Cancelled) Acquisition of Defense Business Systems (DBS)
    13. Urgent Capability Acquisition
    14. Cybersecurity in the Defense Acquisition System

AcqLinks: and References:

Updated: 1/23/2020

Acquisition Process

Alternative Systems Review (ASR)

 

An Alternative Systems Review (ASR) is a technical review that assesses the preliminary materiel solutions that have been developed during the Materiel Solution Analysis (MSA) Phase.  The review ensures that one or more proposed materiel solution(s) have the best potential to be cost-effective, affordable, operationally effective, and suitable, and can be developed to provide a timely solution at an acceptable level of risk to satisfy the capabilities listed in an Initial Capabilities Document (ICD).  The ASR helps the Program Manager and Systems Engineer ensure that further engineering and technical analysis needed to draft the system performance specification is consistent with customer needs.

 

Checklist: ASR Risk Assessment

 

Checklist: Alternative System Review Checklist – Jan 12

 

A successful ASR is predicated on the review team’s determination that the operational capabilities, proposed solution(s), available technologies, and program resources (funding, schedule, staffing, infrastructure, and processes) form a satisfactory basis for proceeding into the Technology Development (TD) Phase.  An ASR should provide information to the Milestone A review before proceeding into the TD Phase.

 

Completion of the ASR should provide the following: [1]

  1. An agreement on the proposed material solution(s) (including the corresponding product support concept) to take forward into the milestone decision and subsequent Technology Development phase.
  2. Hardware and software architectural constraints/drivers to address all Key Performance Parameters (KPPs)
  3. An assessment of the full system software concept to include a conceptual definition of the complete deliverable/non-deliverable software, scope, and risk.
  4. A comprehensive rationale for the proposed materiel solution(s), based upon the Analysis of Alternatives (AoA) that evaluated relative cost, schedule, performance (hardware, human, software), and technology risks.
  5. A comprehensive assessment of the relative risks associated with including Commercial off-the-Shelf (COTS)items in the program, with emphasis on host platform environmental design, diagnostic information integration, and maintenance concept compatibility.
  6. A comprehensive risk assessment for the Technology Development (TD) Phase.
  7. Results of Trade Studies/technical demonstrations for concept risk reduction.
  8. Joint requirements for the purposes of commonality, compatibility, interoperability, and integration.
  9. Refined thresholds and objectives initially stated as broad measures of effectiveness and suitability (e.g., Key Performance Parameters (KPP) / Key System Attributes (KSA)).
  10. Completed, comprehensive planning for the TD phase (hardware, software, and human systems), including critical components to be developed, prototyped, and demonstrated their cost, and critical path drivers. This planning could include an Integrated Master Plan (IMP) and Integrated Master Schedule (IMS).
  11. Initial planning for the Engineering and Manufacturing Development phase.
  12. A draft System Requirements Document (SRD) if one does not already exist. (This is a high-level engineering document that represents the customer/user capability needs as system requirements.) This systems requirement document should include a system-level description of all software elements required by the preferred system concept.

 

The Technical Review Chair determines when the review is complete. ASR technical outputs should include, but not be limited to, the following products, including supporting rationale and trade study results: [1]

 

AcqTips:

  • The ASR risk assessment checklist is designed as a technical review preparation tool and should be used as the primary guide for assessing risk during the review.

AcqLinks and References:

Updated: 4/09/2018

Acquisition Process

Alternative Materiel Solution

 

Alternative Material Solutions are examined as part of an Alternative Systems Review (ASR).  They examine alternative solutions that might be viable to meet defined needed capabilities in terms of cost, schedule and performance risk, and reasonableness given the expected maturity of enabling technologies.  By reviewing alternative material solutions, the ASR helps ensure that sufficient effort has been given to conducting trade studies that consider and incorporate alternative system designs that may more effectively and efficiently meet the defined capabilities.

AcqLinks and References:

Updated: 7/31/2017