4.2.10. System Requirements Review
4.2.10. System Requirements Review
The System Requirements Review (SRR) is a multi-disciplined technical review to ensure that the developer is ready to proceed with the initial system design. This review assesses whether the system requirements as captured in the system performance specification:
- Are consistent with the preferred materiel solution (including its support concept) from the Materiel Solution Analysis (MSA) phase
- Are consistent with available technologies resulting from the prototyping efforts
- Adequately consider the maturity of interdependent systems
All system requirements and performance requirements derived from the Initial Capabilities Document (ICD) or draft Capability Development Document (CDD) should be defined and consistent with cost, schedule, risk, and other system constraints; and with end user expectations. Also important to this review is a mutual understanding (between the program office and the developer) of the technical risk inherent in the system performance specification.
For Major Defense Acquisition Programs (MDAPs), the PDUSD(AT&L) memorandum, “Improving Milestone Process Effectiveness” requires a Milestone A review before approving release of the final Request for Proposal (RFP) for the Technology Development (TD) phase; therefore, it is suggested that the program office perform a review similar to an SRR to assess readiness and risks of the technical content of the draft RFP(s) prior to Milestone A. This program office review most likely occurs after the Functional Capabilities Board (FCB) review of the AoA and other analytic results.
If the program’s Technology Development Strategy (TDS) includes competing contractual efforts during the TD phase, an SRR should be held with each participating developer to ensure the requirements are thoroughly and properly understood. This review also ensures that system of systems (SoS) requirements, in the form of logical and physical interfaces and desired performance outcomes, have been levied on the system to be procured and are consistent with the ICD and/or draft CDD. These requirements are documented in the system performance specification and managed through external communication and technical interfaces in accordance with the Systems Engineering Plan (SEP).
Roles and Responsibilities
The unique Program Manager responsibilities associated with an SRR include:
- Approve, fund, and staff the SRR as planned in the SEP developed by the Systems Engineer
- Manage and approve changes to the system performance specification
- Establish the plan to SFR in applicable contract documents including the SE Master Plan, Integrated Master Schedule (IMS), and Integrated Master Plan (IMP)
- Ensure the plan includes independent subject matter experts to participate in each review
The unique Systems Engineer responsibilities associated with an SRR include:
- Ensure all performance requirements, both explicit and derived, are defined and traceable (both directions) between requirements in the draft CDD including Key Performance Parameters (KPPs), Key System Attributes (KSAs), other system attributes, and the system performance specification (see CJCSI 3170.01 JCIDS)
- Ensure verification methods are identified for all system requirements
- Ensure risk items associated with system requirements are identified and analyzed, and mitigation plans are in place
- Ensure adequate plans are in place to complete the technical activities to proceed from SRR to the System Functional Review (SFR)
- Ensure plans to proceed to SFR allow for contingencies
Inputs and Review Criteria
Figure 4.2.10.F1 provides the end-to-end perspective and the integration of SE technical reviews and audits across the acquisition life cycle. The SRR criteria are developed to best support the program’s technical scope and risk and are documented in the program’s SEP at Milestone A.
Figure 4.2.10.F1. Weapon System Development Life Cycle
Table 4.2.10.T1 defines the suggested SRR products and associated review criteria. The review should not begin until these criteria are established, evidence has been received to support a case for success, and any prior technical review is completed and its action items closed. This is also an opportunity to assess whether technical requirements from all acquisition documentation (e.g., Program Protection Plan (PPP), Test and Evaluation Master Plan (TEMP), Reliability, Availability, Maintainability, and Cost Rationale (RAM-C) Report) are flowed to specifications. If the program’s TDS includes competing contractual efforts, an SRR should be held with each developer. A risk assessment tool for SRR preparation is the DoD SRR Checklist. This is a best practice review.
Table 4.2.10.T1. SRR Products and Criteria
Product
|
SRR Criteria
|
Cost Estimate
|
- Preliminary Cost Analysis Requirements Description (CARD) is consistent with the approved system performance specification
- Preliminary software development estimates established with effort, schedule, and cost analysis
- Updated cost estimate fits within the existing budget
|
Risk Assessment
|
- Technical risks are identified, and mitigation plans are in place
- Risk Management Plan (RMP) is complete and adequate
|
System Performance Specification
|
- Contractor clearly demonstrates an understanding of the system requirements consistent with the ICD and draft CDD
- System requirements are sufficiently detailed and understood to enable system functional definition and functional decomposition
- System requirements are assessed to be verifiable (see Chief Developmental Tester in DAG Chapter 9 Test and Evaluation)
- Requirements can be met given the technology maturation achieved and evidence from competitive prototyping
- External interfaces to the system have been documented in interface control documents
- SoS technical interfaces are adequately defined, including interdependences associated with schedule, test, and configuration changes
- Preliminary identification of all software components (tactical, support, deliverable, non-deliverable, etc.) are completed
- Human Systems Integration (HSI) and sustainment requirements have been reviewed and included in the overall system design (see DAG section 4.3.18.10 and DAG Chapter 6 Human Systems Integration)
- Contractor has adequately expanded the system specification to reflect tailored, derived, and correlated design requirements
- Bidirectional requirements traceability between the draft CDD, the Statement of Work (SOW), and the System Specification has been documented
- System performance specification is approved, including stakeholder concurrence, with sufficiently conservative requirements to allow for design trade space
|
Technical Plans
|
- Contractor’s Systems Engineering Management Plan (SEMP) is complete and adequate
- Cost and critical path drivers have been identified
- The program schedule is executable with an acceptable level of technical and cost risk
- Adequate processes and metrics are in place for the program to succeed
- SE is properly staffed
- Program is executable within the existing budget
- Software functionality in the system specification is consistent with the software sizing estimates and the resource-loaded schedule
- Programming languages and architectures, security requirements, and operational and support concepts have been identified
- Hazards have been reviewed and mitigating courses of action have been allocated within the overall system design
- Key technology elements have been identified, readiness assessed, and maturation plans developed
- Software development strategy is complete and adequate
- Program technical risks are adequately identified and documented such that there is a clear understanding regarding the contractor's ability to meet the specification requirements
- Draft verification methodologies have been adequately defined for each specification requirement
- Certifying agencies have been identified and certification requirements are understood
- Draft test plans have been developed in support of the TD phase (See Chief Developmental Tester in DAG Chapter 9 Test and Evaluation)
- Government and contractor configuration management (CM) strategies are complete and adequate
- The Modeling and Simulation (M&S) Plan for life-cycle support (including life-cycle costs / total ownership costs (LCC/TOC), training devices, tactics, air vehicle, mission system etc.) is complete and adequate to support system design and operation
- The manufacturing and production strategy is complete and adequate
- Integrated Master Schedule (IMS) adequately identifies the critical path and is resourced at reasonable levels, based on realistic performance/efficiency expectations
- Unique work requirements for competitive prototyping have been identified
- Product support plan and sustainment concepts have been defined with the corresponding metrics
|
Output and Products
The Technical Review Chair determines when the review is complete. Once the products have been reviewed and approved in SRR, they provide a sound technical basis for proceeding with system functional definition and preliminary design.