Content updates needed on this page: 

Recent Changes: 

1. Revised tabs

This guidance provides the recommended life cycle review entrance and exit criteria for software projects and should be tailored for the project class.

1.4 Related Activities

This Topic is related to the following Life Cycle Activities:

The MDR (or SDR) examines the proposed requirements, the mission/system architecture, and the flow down to all functional elements of the system. (NPR 7120.5 )

• MDR is equivalent to SDR for robotic projects.

• Successful completion of the previous review (typically SRR) and responses made to all Requests for Actions (RFAs) and Review Item Discrepancies (RIDs)
• Final agenda, success criteria, and charge to the board have been agreed to by the technical team, project manager, and review chair
• Technical products for this review were made available to participants prior to SDR
• Preferred software solution defined including major tradeoffs and options
• Baseline documentation updated, as required
• Preliminary functional baseline (with supporting trade-off analyses and data) available
• Preliminary system software functional requirements available
• As applicable, the risk management plan updated (could be part of SDP/SMP)
  • Updated software risk assessment and mitigations (including Probabilistic Risk Assessment (PRA), as applicable)
• As applicable, SDP/SMP updated
  • Updated technology development, maturity, and assessment plan
  • Updated cost and schedule data
  • Work Breakdown Structure
• Preliminary software safety analysis available for review
• Project software data dictionary available
• Preliminary project software assurance plan available
• As applicable, an updated project software maintenance plan is available
• Software inputs/contributions completed for:
  • Flow down of system requirements to all software functional elements of the system
  • Requirements process
  • Technical approach

Software Assurance:

• Confirm that all RIDs/RFAs from SwRR have been resolved
• Coordinate with the project on any changes in software classification
• Review or participate in system preliminary safety analysis
• Confirm that:
  • The preferred software solution is defined as including major tradeoffs and options
  • The functional baseline is available; system software functional requirements exist and have been flowed down into software functional elements of the system.
  • The requirements process is in place
  • SDP/SMP has been updated (as applicable), including risk management, cost, schedule, work break-down structure, technical management, plans for monitoring performance
  • Confirm other baselined documentation has been updated as needed; check for alignment of documentation
  • Complete contributions to system safety and mission assurance plans
  • Complete software assurance plan
  • Confirm those entrance criteria are met
  • Review materials submitted for the review

• System architecture, including software
• Preferred software solution with tradeoffs and options
• Preliminary functional baseline
• Preliminary system software functional requirements
• The risk management plan, as applicable
• SDP/SMP, as applicable
• Preliminary software verification and validation (V&V) planning, as applicable
• Software requirements documents
• Interface requirements documents, including SW
• Technical resource utilization estimates and margins
• Software safety analysis
• Software data dictionary
• Software configuration management (CM) plan
• Software quality assurance (QA) plan

Software Assurance:

• Review materials for review; attend the review
• Summarize or present any SA analysis or audit results from this phase
• Submits any RIDs/RFAs for identified issues or risks

• The review panel agrees that:
  • Software requirements, including mission success criteria and any sponsor-imposed constraints, are defined and form the basis for the proposed conceptual design
  • System-level requirements are flowed down to the software
  • All software technical requirements are allocated and flow down to subsystems is adequate; they are verifiable and traceable to their corresponding system level requirement; requirements, design approaches, and conceptual design will fulfill the mission needs consistent with the available resources (cost, schedule, throughput, and sizing)
  • Technical plans have been updated, as necessary, including a risk management plan, SDP/SMP, V&V planning, software maintenance plan, QA plan, CM plan
  • Tradeoffs are completed, and those planned for Phase B adequately address the option space
  • Adequate planning exists for the development of any enabling new technology
  • Significant development, mission, and safety risks are identified and technically assessed, and a process and resources exist to manage the risks
  • The operations concept is consistent with the proposed design concept(s) and in alignment with the mission requirements
  • The requisite level of detail and resources are available to support the acquisition and development plan within existing constraints
  • All of these software subsystem requirements are traceable to either mission objectives, the concept of operations, or interface requirements
  • Monitoring processes/practices are in place to create a software subsystem within planned technical, schedule, cost, effort, and quality capabilities
• Preliminary verification approaches are agreed upon

Software Assurance:

• Confirm all risks and issues are documented.
• RIDs/RFAs for the SA Plan implemented
• Agree with the review panel that the items above have been adequately addressed
• Agree with resolutions or action plans for RFAs/RIDs; track them to closure