1. Requirements

3.5.2 The project manager shall maintain records of each software classification determination, each software Requirements Mapping Matrix, and the results of each software independent classification assessments for the life of the project. 

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

Key:    - Applicable | - Not Applicable

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 - OCE NPR Appraisals ) for evaluating compliance and software classification assessments. 

3. Guidance

3.1 Records Maintenance and Retention

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 - Software Classification). 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. See 7.16 - Appendix C. Requirements Mapping and Compliance Matrix. 

(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 classification determination records can be utilized by teams throughout the software lifecycle, such as understanding how the different software classes fit the total project.  Testing systems with multiple software classifications can lead to inappropriate amounts of testing. 

See also SWE-021 - Transition to a Higher Class

3.2 Periodic Review of Classification and Safety Criticality

The software classification and safety criticality should be reexamined periodically, for example, whenever there are major requirement changes, and at major milestone review points.  See also 7.02 - Classification and Safety-Criticality, and Topic 7.13 - Transitioning to a Higher Class

3.3 Records Location

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 5.08 - SDP-SMP - Software Development - Management 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.

3.4 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook:

3.7 Center Process Asset Libraries

See the following link(s) in SPAN for process assets from contributing Centers (NASA Only). 

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

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)

  
  

  Objective Evidence

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

  Objective evidence is an unbiased, documented fact showing that an activity was confirmed or performed by the software assurance/safety person(s). The evidence for confirmation of the activity can take any number of different forms, depending on the activity in the task. Examples are:

  • Observations, findings, issues, risks found by the SA/safety person and may be expressed in an audit or checklist record, email, memo or entry into a tracking system (e.g. Risk Log).
  • Meeting minutes with attendance lists or SA meeting notes or assessments of the activities and recorded in the project repository.
  • Status report, email or memo containing statements that confirmation has been performed with date (a checklist of confirmations could be used to record when each confirmation has been done!).
  • Signatures on SA reviewed or witnessed products or activities, or
  • Status report, email or memo containing a short summary of information gained by performing the activity. Some examples of using a “short summary” as objective evidence of a confirmation are:
    • To confirm that: “IV&V Program Execution exists”, the summary might be: IV&V Plan is in draft state. It is expected to be complete by (some date).
    • To confirm that: “Traceability between software requirements and hazards with SW contributions exists”, the summary might be x% of the hazards with software contributions are traced to the requirements.
  • The specific products listed in the Introduction of 8.16 are also objective evidence as well as the examples listed above.

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)

See also Topic 8.18 - SA Suggested Metrics.

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: Topic 7.02 - Classification and Safety-Criticality. 

7.5 Additional Guidance

Additional guidance related to this requirement may be found in the following materials in this Handbook: