1. Requirements

1.1 Notes

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

1.2 History

1.3 Applicability Across Classes

2. Rationale

The project manager is required to maintain the following records for the life of the project.

(1) Each software classification determination performed by the project manager,
(2) Each project software requirements mapping matrix
(3) The results of each software-independent classification assessment by S&MA.

It is important to maintain the records of the software classification and the resulting logic for the classification since the NPR 7150.2 requirements that need to be satisfied for the software are dependent on the software classification. The software requirements mapping matrix will contain the records of any approved tailoring of the requirements. The combination of these records determines exactly what requirements the project will need to satisfy and that information needs to be communicated to everyone on the project.

The records of the logic for the software classification are important so they can be reviewed as the project requirements change and used to help determine whether there has been sufficient change to merit a change in software classification.

Records maintained by the project manager can also be used during the Office of the Chief Engineer (OCE) survey activity (see SWE-129 ) for evaluating compliance and software classification assessments. 

3. Guidance

The following records are maintained throughout the life of the project.

(1) Each software classification determination performed by the project manager,

The project completes the determination of software classification (see SWE-020 ). Some projects may contain multiple systems and subsystems having different software classes. Appendix C in the NPR defines the default applicability of the requirements based on software classification and safety criticality.

(2) Each project software requirements mapping matrix

A requirements mapping matrix typically lists all of the NPR 7150.2, NASA Software Engineering Requirements, requirements applicable to a project's software, along with the planned approach for demonstrating compliance. As projects can contain multiple classes of software, a project software requirements matrix with this NPR is created for each software class.

(3) The results of software classification determination by S&MA.

If an independent assessment is needed by S&MA, S&MA will complete the assessment and compare the results to the engineering assessment and work with the TAs to resolve any differences.

These records can be used in the OCE survey of a Center's processes and directives and thorough examinations of a project's official records. These surveys are one of the tools used by the OCE to provide oversight, maintain internal control, and review its operations. 

The software classification and safety criticality should be reexamined periodically, for example, whenever there are major requirement changes, and at major milestone review points.

The location of the records above should be listed on the project's data management list along with the record of the software safety criticality. The Software Management/Development Plan may list the initial determinations of the software classification and safety-critical and then point to the location of the data management list or the most up-to-date information.

When classifying software be sure to consider:

• All software for the system or subsystem (classification may need to be assessed separately).
• The purpose of the software.
• How the software is intended to be used.
• Relevance to major programs and projects.
• Hardware controls.
• Operations.
• Interaction with humans.
• Complexity (developmental and operational complexity is woven into the class definitions).
• The risk to the project, Center, and Agency
• Investment.

If a software component is traceable to a hazard and is determined to be safety-critical software, per the software safety-critical determination process defined in NASA-STD-8739.8, then the software component classification must be Software Class D or higher.

4. Small Projects

No additional guidance is available for small projects.

5. Resources

5.1 References

5.2 Tools

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

7.1 Tasking for Software Assurance

1. Confirm that records of the software Requirements Mapping Matrix and each software classification are maintained and updated for the life of the project.

7.2 Software Assurance Products

• Software Classification Determination 
• Identify the specific requirements in NASA-STD-8739.8 that are being tailored by the projects (*organizational metric)

  
  

  NPR 7150.2 and NASA-STD-8739.8 requirements mapping matrices signed by the engineering and SMA technical authorities for each development organization.

7.3 Metrics

•   % of Total Source Code for each Software Classification (*organizational measure)
• Identify the specific requirements in NASA-STD-8739.8 that are being tailored by the projects (*organizational measure)

7.4 Guidance

An independent software assurance classification assessment is not required but can be done if needed by your center processes. Software engineering and software assurance must reach an agreement on the classification of systems and subsystems.  Software assurance can just concur with the software engineering classification if they agree with the classification. If an independent software assurance classification is done, that record along with the rationale for the classification should be kept.

Some projects may contain multiple systems and subsystems having different software classes. Appendix C in the NPR defines the default applicability of the requirements based on software classification and safety criticality. The applicability of NPR 7150.2 requirements is determined using the Requirements Mapping and Compliance Matrix in Appendix C of the NPR using the software class definitions in Appendix D of the NPR and the software’s safety criticality designation. Important to classification is the usage of the software with or within a NASA system, the criticality of the system to NASA’s major programs and projects, the extent to which humans depend upon the system, developmental and operational complexity, and the extent of the Agency’s investment.

Complete the classification of software as soon as it has been determined that a project includes software. Both the software development organization in conjunction with the project office and software assurance classify software and, as stated in the NPR 7150.2 note for this requirement, Software engineering and software assurance must reach an agreement on the classification of systems and subsystems. Disagreements are elevated via both the Engineering Technical Authority and Safety and Mission Assurance Technical Authority chains.

Guidance: When classifying software be sure to consider:

• All software for the system or subsystem (classification may need to be assessed separately).   
• Purpose of the software.
• How the software is intended to be used.
• Relevance to major programs and projects.
• Hardware controls.
• Operations.
• Interaction with humans.
• Complexity (developmental and operational complexity is woven into the class definitions).
• The risk to the project, Center, and Agency Investment.

If a software component is traceable to a hazard and is determined to be safety-critical software, per the software safety-critical determination process defined in NASA-STD-8739.8 ,  then the software component classification must be Software Class D or higher. When classifying software be sure to consider: