Click on the image to preview the file. From the preview, click on Download to obtain a usable copy. 

Click on the image to preview the file. From the preview, click on Download to obtain a usable copy. 

Updates needed:

Related Pages

PAT-070 - SDR - Software System Design Milestone Review Checklist

AI (gpt-4o)

The Software System Design Review (SDR) exit criteria outlined in NASA-HDBK-2203, Topic 7.09, ensure that the software's high-level architectural design is well-defined, feasible, and aligned with system-level goals and requirements. The SDR verifies that the software design provides a solid architecture for implementation and that all risks, trade-offs, and requirements are carefully considered. Below is a summary of the Software SDR Exit Criteria:

Summary of Software SDR Exit Criteria

  1. Architecture Definition:
    • A high-level software architecture must be identified and documented, showing how the software will meet the functional, performance, and interface requirements.
    • The architecture must define significant components, subsystems, modules, data flows, and interconnections.
  2. Requirements Traceability:
    • The software architecture and design must be traceable to all system-level and software requirements.
    • All high-level software components must map to specific requirements, including functional, performance, safety, security, and interface requirements.
  3. Interface Definition:
    • All software interfaces (internal and external) must be documented, including data formats, messaging, and communication protocols.
    • Interfaces must address hardware/software integration points and external interactions.
  4. Feasibility and Trade Studies:
    • Feasibility of the proposed design must be demonstrated, considering all resource constraints (e.g., cost, performance, and schedule).
    • Completed trade studies or analyses must justify design decisions and demonstrate that the selected approach balances mission priorities.
  5. Risk Assessment and Mitigation Plans:
    • Risks associated with the architecture, including technical, schedule, or cost risks, must be identified and assessed.
    • Mitigation plans must be documented for all identified risks.
  6. Preliminary Data Management:
    • Data management requirements (e.g., data storage, access, and flows) must be addressed in the high-level design.
    • Key data structures, databases, and storage solutions must be preliminarily defined and reviewed.
  7. Safety and Security Considerations:
    • Safety-critical aspects of the design must be identified, and appropriate controls defined in the architecture.
    • Security considerations, including protection against cyber threats, must be integrated into the high-level design.
  8. Verification and Validation (V&V) Planning:
    • A preliminary plan for verifying the high-level design must be defined.
    • The architecture must demonstrate that it supports the verification and validation of all software requirements.
  9. Compliance with Standards:
    • The design must comply with relevant software, system, and safety standards (e.g., NASA-STD-8719.13 and NASA-STD-8739.8).
    • Reviews must confirm adherence to agency guidelines and project-specific standards.
  10. Stakeholder Approval:
    • Key stakeholders, including systems engineers, project managers, and software assurance teams, must review and approve the architecture.
    • Agreement on the feasibility and readiness of the architecture must be reached among all parties.
  11. Supporting Documentation:
    • All documentation related to the software architecture must be complete, reviewed, and approved. This includes design diagrams, interface definition documents, trade studies, and risk analyses.
    • The documentation should provide sufficient detail to transition to detailed design and implementation.
  12. Readiness for Detailed Design:
    • The project must demonstrate readiness to proceed to the detailed software design phase.
    • All critical design issues raised at the SDR must be resolved or have approved paths toward resolution.

Key Purpose of Software SDR Exit Criteria

The Software SDR ensures that the high-level software design:

  • Is feasible and aligns with mission and system-level requirements.
  • Provides a robust foundation for detailed design and implementation.
  • Anticipates and mitigates risks associated with architecture and design decisions.
  • Aligns with safety, security, and performance requirements.

By meeting the SDR exit criteria, the project team ensures that the architectural framework is mature enough to proceed to the next stage of development with minimal risk.

Conclusion: The Software SDR Exit Criteria ensure the feasibility, completeness, and quality of the software's high-level architecture. Successfully addressing these criteria prepares the project to transition seamlessly into the detailed design phase with confidence that the software structure will meet mission objectives, requirements, and constraints.