Requirements The Software Assurance Plan(s) shall be developed and documented per NASA-STD-8739.8, NASA Software Assurance Standard.


NPR 7150.2A does not include any notes for this requirement.

Implementation Notes from Appendix D

NPR 7150.2A does not include any implementation notes for this requirement.

Applicability Across Classes

This requirement applies to all classes and safety criticalities except:


Software assurance activities ensure that the project team implements software engineering products and processes according to the plans established by the project and comply with requirements in the NASA Software Assurance Standard. The NASA Software Assurance Standard captures the assurance requirements in a single place for more uniform application across projects where software is developed or acquired for NASA.
The Software Assurance Plan represents an agreement between the project, the software developers and the software assurance personnel. It describes the activities, roles, and responsibilities of software assurance on the project. As with any task, a plan helps ensure that the team performs all necessary and required tasks. Development of that plan provides the opportunity for stakeholders to give input and assist with the documentation and tailoring of the planned activities for the project.
Specific to software assurance, the NASA Software Assurance Standard provides requirements that the team can use as the basis for development of a project's software assurance plan. Using this previously thought-out, defined set of requirements gives plan development teams a common starting point for their activities and ensures that all software assurance plans include and address the same key tasks and assurance activities.


Per NPR 7150.2A, "The Software Assurance Plan details the procedures, reviews, and audits required to accomplish software assurance. The project office should coordinate with the Office of Safety and Mission Assurance for help in scoping and adapting the effort appropriately, and to designate the individual responsible for software assurance on the project."
For projects that involve subcontracted work, both the acquirer and the provider (subcontractor), need Software Assurance Plans and those plans must work together to accomplish the required level of software assurance. The preliminary acquirer plan is developed at the same time the Request for Proposal (RFP) or Memorandum of Agreement/Understanding (MOA/U) is created. Both acquirer and provider plans are to be completed by the time the contract is awarded.
As with many project plans, the Software Assurance Plan (SAP) may be a separate document or may be combined with another project plan such as the Software Development Plan (SDP).
While the NASA Software Assurance Standard contains requirements for software assurance in general, the following requirements, identified by the paragraph numbers, apply specifically to the development and documentation of a SAP. These requirements, shown here without their associated project lifecycle phase, provide a high-level content overview of both the acquirer and provider SAPs. When carrying out these requirements, consult the NASA Software Assurance Standard to determine the specific lifecycle phase in which they are to be completed.
Acquirer SAP:

Provider SAP:

NOTE: For smaller projects, this plan may be incorporated in another project-planning document or may be a separate document. Larger projects may have a separate plan or more than one software assurance plan.

The NASA Software Safety Standard (NASA-STD-8719.13B) also includes two requirements that address content to consider for the SAP:

Before writing a SAP, the team should review the following material as preparation:

Using an existing template will ensure consistency of plans across projects as well as ensure all key information is included in the SAP. If a project or Center SAP template or "best-in-class" example does not exist, the NASA Software Assurance Standard (NASA-STD-8739.8) contains a basic outline in Appendix B. Templates are included in the Resources section of this guidance, including one from Goddard Space Flight Center (GSFC) based on the IEEE 730-2002 standard noted in the NASA Software Assurance Standard requirements which includes suggested content for each section of the SAP.
Other content elements to consider include:

Ensure that the SAP is reviewed prior to implementation and at appropriate lifecycle reviews by personnel with sufficient software assurance knowledge to identify omissions, inadequacies, and other issues. Stakeholders affected by the plan should also be included in the reviews for awareness of planned activities and so that their suggestions can be addressed within the bounds of the project's required level of software assurance. Any identified issues should be corrected prior to plan implementation or prior to carrying out affected software assurance activities in the next lifecycle phase.
The following diagram excerpted from the Glenn Research Center SQA Process for Software Assurance, SEGP-SQA-PRC-15, shows a basic flow of activities for developing and documenting a SAP:

Any changes to the baselined SAP (typically baselined at PDR) should be made via the appropriate formal change request process (internal to the project for the acquirer SAP or via NASA's formal change request process for the provider SAP) and be accompanied by a risk analysis to ensure the project's level of software assurance is not compromised.
Guidance related to software assurance and which should be included in the SAP may be found in the following requirement in this handbook:


Software Plans


Software Classification


Software Assurance


Software Assurance Plan


Independent Software Classification Assessment


Software Safety Determination

Small Projects

According to the NASA Software Assurance Standard, smaller projects have the choice of incorporating their SAP in another project planning document or using a separate document.
If personnel resources are limited, the SAP may address the overall strategy, planning, and requirements at a high level for review at the Software Requirements Review (SRR), with updates to address details of the assurance activities added, as necessary, during project development.
Small projects may want to tailor an existing software assurance plan specifically written for small projects. Tailoring a proven plan from a similar project should reduce the overall plan development effort.


  1. NPR 7150.2A Handbook, Section 5.3.1 - NASA-STD-8739.8 (Standard for Software Assurance)
  2. NASA Software Assurance Standard, NASA-STD-8739.8
  3. ISD Software Quality and IV&V Support Planning Guidelines, 580-GL-030-01, Goddard Space Flight Center (GSFC)
  4. Dryden Centerwide Procedure, Code S, Software Assurance, DCP-S-007 Rev. B., Dryden Flight Research Center (DFRC)
  5. SQA Process, Software Assurance, SEGP-SQA-PRC-1, Glenn Research Center (GRC),
  6. Glenn Procedural Requirements, Software Assurance, GLPR 8739.1, GRC
  7. Software Process, Process and Product Quality Assurance, GRC-SW-7150.13, GRC
  8. IEEE 730-2002, IEEE Standard for Software Quality Assurance Plans(need user account to access IEEE standards via this NASA Technical Standards System link)


Software Quality Assurance Plan template, GSFC
Software Assurance Plan template,
Software Quality Assurance Plan Evaluation Checklist (from the Software Assurance Guidebook)
Acquirer Software Assurance Plan template,

Lessons Learned

There must be a software assurance plan. "Most Project Managers feel they have too many plans, and the suggestion of another one for Software Quality Assurance might be the proverbial straw that breaks the camel's back! But the success of any undertaking is to know what one is trying to achieve and how one expects to accomplish it, hence, the necessity of a plan for SQA. The plan will specify the goals, what is to be performed, standards against which the development work is to be measured, all relevant procedures, and the organizational structure of the Quality Assurance within the project. At NASA a software assurance plan is required." (Lesson 4 of 12, SoftwareTech News,