Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
01. The Requirement
12. Rationale
23. Guidance
34. Small Projects
45. Resources
56. Lessons Learned
67. Software Assurance

1. Requirements


4.5.14 The project manager shall test embedded COTS, GOTS, MOTS, OSS, or reused software components to the same level required to accept a custom developed software component for its intended use. 

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 History

titleClick here to view the history of this requirement: SWE-211 History

Include Page
SITE:SWE-211 History
SITE:SWE-211 History

1.3 Applicability Across Classes


Applicable c


2. Rationale

Software testing is required to ensure that the software meets the agreed requirements and design, the application works as expected, the application doesn’t contain serious bugs and the software meets its intended use as per user expectations. Testing of embedded COTS, GOTS, MOTS, Open Source Software (OSS), or reused software component should be at the same level required to accept a custom-developed software component for its intended use.


3. Guidance

Commercial Off the Shelf (COTS), Government Off the Shelf (GOTS), Modified Off the Shelf (MOTS), Open Source Software (OSS), or reused software components are required to be tested, verified and validated, to the level required to ensure its fitness for use in the intended application.  The software should be verified and validated, to the extent possible, in the same manner as software that is hand-generated using the project classification and criticality as the basis for the level of effort to be applied.

For COTS, GOTS, MOTS, or reused software components like commercial real-time operating systems, it is sufficient to test, in the project environment, the features being used to meet the software system’s requirements.  It is not necessary to test every claim made by the software.  On Class A projects, when the software test suites for the COTS, GOTS, MOTS, or reused software components are available, they are to be used when appropriate to address the intended environment of use, interfaces to the software system, as well as the requirements of the project.

Off-The-Shelf Software

The remaining guidance on off-the-shelf (OTS) software is broken down into elements as a function of the type of OTS software. The following is an index of the guidance elements:

3.1 COTS / GOTS Software

3.2 MOTS Software

3.3 Open Source Software

3.4 Embedded Software

3.1 COTS/GOTS Software

Commercial Off the Shelf (COTS) software and  Government Off the Shelf (GOTS) software are unmodified, out-of-the-box software solutions that can range in size from a portion of a software project to an entire software project. COTS/GOTS software can include software tools (e.g. word processor or spreadsheet applications), simulations (e.g. aeronautical and rocket simulations), and modeling tools (e.g., dynamics/thermal/electrical modeling tools).

If COTS/GOTS software is used for a portion of the software solution, the software requirements about that portion should be used in the testing, V&V of the COTS/GOTS software. For example, if MIL-STD-1553 serial communication is the design solution for the project communications link requirements, and the COTS/GOTS software design solution is used along with the COTS/GOTS hardware design solution, then the project software requirements for the serial communications link should be used to test, verify and validate the COTS/GOTS MIL-STD-1553 software. Other functionality that might be present in the COTS/GOTS MIL-STD-1553 software may not be covered by the project requirements. This other functionality should be either disabled or determined to be safe by analysis and testing.

3.2 MOTS Software

As defined in Appendix A of NPR 7150.2, A.17:
"Modified Off-The-Shelf (MOTS) Software. When COTS, legacy/heritage software is reused, or heritage software is changed, the product is considered 'modified.'- The changes can include all or part of the software products and may involve additions, deletions, and specific alterations. An argument can be made that any alterations to the code and/or design of an off-the-shelf software component constitutes 'modification,' but the common usage allows for some percentage of change before the off-the-shelf software is declared to be MOTS software. This may include the changes to the application shell and/or glueware to add or protect against certain features and not to the off-the-shelf software system code directly. See the off-the-shelf [definition]."

In cases where legacy/heritage code is modified, MOTS is considered to be an efficient method to produce project software, especially if the legacy/heritage code is being used in the same application area as NASA. For example, Expendable Launch Vehicle simulations have been successfully modified to accommodate solid rocket boosters, payload release requirements, or other such changes. Further, if the "master" code has been designed with reuse in mind, such code becomes an efficient and effective method of producing quality code for succeeding projects.

3.3 Open Source Software

Open Source Software (OSS) is software with source code that anyone can inspect, modify, and enhance. Open Source can bring numerous benefits to NASA software efforts, including increased software quality, reduced development costs, faster development cycles, and reduced barriers to public-private collaboration through new opportunities to commercialize NASA technology. 

3.4 Embedded Software

Embedded software applications written by/for NASA are commonly used by NASA for engineering software solutions. Embedded software is software specific to a particular application as opposed to general-purpose software running on a desktop. Embedded software usually runs on custom computer hardware ("avionics"), often on a single chip.

Software reuse

The reuse of commercially-acquired software includes COTS, GOTS, and MOTS. Reuse of in-house software may include legacy or heritage software. Reused software often requires modification to be used by the project. Modification may be extensive, or just require wrappers or glueware to make the software useable. Assure the verification and validation (V&V) activity for the reused software is performed to the same level of confidence as would be required for the newly developed software component.

Additional guidance related to COTS, GOTS, MOTS, open-source, and reused software components topics may be found in the following related requirements in this Handbook:


4. Small Projects

No additional guidance is available for small projects.


5. Resources

5.1 References

Show If
titleVisible to editors only

Enter the necessary modifications to be made in the table below:

SWEREFs to be addedSWEREFS to be deleted

SWEREFs NOT called out in text but listed as germane: none

SWEREFs called out in text: none

5.2 Tools

Include Page
Tools Table Statement
Tools Table Statement


6. Lessons Learned

6.1 NASA Lessons Learned

No Lessons Learned have currently been identified for this requirement.

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.


7. Software Assurance

Excerpt Include
SWE-211 - Test Levels of Non-Custom Developed Software
SWE-211 - Test Levels of Non-Custom Developed Software

7.1 Tasking for Software Assurance

  1. Confirm that the project is testing COTS, GOTS, MOTS, OSS, or reused software components to the same level as developed software for its intended use.

7.2 Software Assurance Products

  • None at this time.

    titleObjective Evidence
    • Software test reports.
    • Software test procedures.
    titleDefinition of objective evidence

    Include Page
    SITE:Definition of Objective Evidence
    SITE:Definition of Objective Evidence

7.3 Metrics

  • # of Non-Conformances identified in embedded COTS, GOT, MOTS, OSS, or reused components in ground or flight software vs. # of Non-Conformances successfully closed
  • # of tests successfully completed vs. total # of tests
  • # of Non-Conformances identified during each testing phase (Open, Closed, Severity)
  • # of tests executed vs. # of tests successfully completed

7.4 Guidance

For software assurance to confirm that the COTS, GOTS, MOTS, OSS, or reused code is being tested to the same level as developed components, they must know what capabilities and requirements are being satisfied by each of the COTS, GOTS, MOTS, and OSS components. When those requirements and capabilities are identified, software assurance will confirm that each of those capabilities/requirements has been included in the test procedures and test cases.

Then software assurance will confirm that this set of tests has been run and satisfactorily completed, either by witnessing the tests or by examining the test reports. If changes have been made to the GOTS, MOTS, OSS, or reused software, confirm that these changes have been adequately tested, including regression testing so that all requirements are still satisfied with no unintended consequences. If this software is satisfying any safety-critical requirements, a full set of regression tests needs to be run. 

Software assurance signs off that all tests have been completed.