4.2.9. Alternative Systems Review
4.2.9. Alternative Systems Review
The Alternative Systems Review (ASR) is held to support a dialogue between the end user and acquisition community and leads to a draft performance specification for the preferred materiel solution. The ASR typically occurs during the Materiel Solution Analysis (MSA) phase, after completion of the Analysis of Alternatives (AoA) and before Milestone A. It focuses technical efforts on requirements analysis.
The ASR should evaluate whether there is sufficient understanding of the technical maturity, feasibility, and risk of the preferred materiel solution, in terms of addressing the operational capability needs in the Initial Capabilities Document (ICD) and meeting affordability, technology, and operational effectiveness and suitability goals.
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.
CJCSI 3170.01 calls for a Functional Capabilities Board (FCB) review prior to Milestone A. This FCB review should ensure compatibility between the operational capability needs in the ICD and the maturity, feasibility, and risks of the preferred materiel solution.
Roles and Responsibilities
The unique Program Manager responsibilities associated with an ASR include:
- Approve, fund, and staff the ASR
The unique Systems Engineer responsibilities associated with an ASR include:
- Ensure adequate plans are in place to complete the necessary technical activities for the ASR
- Ensure results of all technical trade studies are captured in documents that are carried through to the next phase
- Ensure technical risk items are identified and analyzed, and appropriate mitigation plans are in place. This activity should include, for example, the identification of critical technologies and identification of key interfaces with supporting or enabling systems
Inputs and Review Criteria
The ASR typically occurs after the AoA is complete and after a preferred materiel solution is selected by the lead Service or Component but before the FCB review. Figure 4.2.9.F1 provides the end-to-end perspective and the integration of SE technical reviews and audits across the acquisition life cycle.
Figure 4.2.9.F1. Weapon System Development Life Cycle
This timing allows the focus of the ASR to be on the preferred materiel solution rather than on all the alternatives and allows for some post-AoA technical analysis to be completed and inform the FCB deliberations.
- The AoA results are an input to the ASR. The AoA should have evaluated a number of candidate materiel solutions and identified those alternatives that can meet the user requirements within the remaining trade space (including cost and affordability constraints).
- After the AoA is complete, the operational requirements community and the acquisition community collaboratively identify one or more preferred materiel solution(s) with the potential to be affordable, operationally effective and suitable, sustainable, and technically and technologically achievable (i.e., able to provide a timely solution to the stated operational capability need at an acceptable level of risk). This preferred materiel solution is also an input to the ASR.
- The draft concept of operations (CONOPS) should be available as an input to the ASR. It should have been available for use in the AoA and can then be used to support development of missions and operational scenarios used to evaluate the preferred materiel solution.
Table 4.2.9.T1 defines the suggested ASR artifacts and associated review criteria. The review should not begin until these criteria are considered met. This is a best practice review.
Table 4.2.9.T1. ASR Products and Criteria
|
Product
|
ASR Criteria
|
|
Refined Joint Requirements
|
- Joint context and initial CONOPS updated to reflect current user position about capability gap(s), supported missions, interfacing/enabling systems in the operational architecture; overall system of systems (SoS) context
- Required related solutions and supporting references (ICD and CDDs) identified
- Joint refined thresholds and objectives initially stated as broad measures of effectiveness and suitability (e.g., KPPs, KSAs, need date)
|
|
Initial Architecture for the Preferred Materiel Solution(s)
|
- High-level description of the preferred materiel solution(s) is available and sufficiently detailed and understood to enable further technical analysis in preparation for Milestone A
- SoS interfaces and external dependencies are adequately defined
|
|
System Performance Specification
|
- Clear understanding of the system requirements consistent with the ICD and draft CDD (if available)
- System requirements are sufficiently understood to enable system functional definition
- Draft system performance specification has sufficiently conservative requirements to allow for design trade space
- Relationship between draft system specification and competitive prototyping objectives is established
|
|
Preferred Materiel Solution(s) Documentation
|
- Comprehensive rationale is available for the preferred materiel solution(s), based on the AoA
- Key assumptions and constraints associated with preferred materiel solution(s) are identified and support the conclusion that this solution can reasonably be expected to satisfy the ICD (or draft CDD if available) in terms of technical, operational, risk, and schedule/cost (affordability) criteria
- Results of trade studies/technical demonstrations for concept risk reduction, if available
- Initial producibility assessments of solution concepts
|
|
Risk Assessment
|
- Technical risks are identified, and mitigation plans are in development
- Initial hazard analysis/system safety analysis for preferred solution(s) complete
|
Outputs and Products
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:
- Refined description of the preferred materiel solution to support further development
- Informed advice to the user-developed draft Capability Development Document (CDD) required at Milestone A
DAG Tutorial 
