1. Requirements

3.1.11 The project manager shall comply with the requirements in this NPR that are marked with an “X” in Appendix C consistent with their software classification.

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

In this NPR, all mandatory actions (i.e., requirements) are denoted by statements containing the term “shall,” followed by a software engineering (SWE) requirement number.

3. Guidance

3.1 Tailoring

Software requirements tailoring is the process used to seek relief from NPR requirements consistent with program or project objectives, acceptable risk, and constraints. To accommodate the wide variety of software systems and subsystems, the application of these requirements to specific software development efforts may be tailored where justified and approved. To effectively maintain control over the application of requirements in this directive and to ensure proposed tailoring from specific requirements is appropriately mitigated, NASA established Technical Authority governance. Tailoring from requirements in this directive is governed by the following requirements, as well as those defined in NPD 1000.3, The NASA Organization NPD 2800.1 ⁵⁹⁸, NPR 2810.1 ⁴⁰³,  NPR 7120.5 ⁰⁸², NPR 7120.7 ²⁶⁴, NPR 7120.8 ²⁶⁹, NPR 7120.11 ²²⁹  and NPR 8715.3  ²⁸⁶  for all of the Agency’s investment areas. The Technical and Institutional Authority(s) for each requirement in this NPR are documented in the “Authority” column of Appendix C. The responsible program, project, or operations manager needs to formally accept the tailoring risk. Tailoring decided at the Center level is to consult the Center Engineering Technical Authority, Center SMA Technical Authority, Center Health and Medical Technical Authority, and the NASA CIO’s Center IT Authority designee as defined in the requirements mapping matrix. The OSMA has co-approval on any tailoring decided at the Headquarters level that involves software.  The Office of the Chief Medical Officer (OCHMO) has co-approval on any tailoring decided that involves software with health and medical implications. The SAISO, or designee, has co-approval on any tailoring of the cybersecurity requirements in section 3.11. For tailoring involving human safety risk, the actual risk taker(s) (or official spokesperson[s] and appropriate supervisory chain) need to formally agree to assume the risk.

3.2 Baseline Set of Requirements

This directive establishes a baseline set of requirements to reduce software engineering risks on NASA projects and programs. Appendix C defines the default applicability of the requirements based on software classification. Each project has unique circumstances, and tailoring can be employed to modify the requirements set appropriate for the software engineering effort. Tailoring of requirements is based on key characteristics of the software engineering effort, including acceptable technical and programmatic risk posture, Agency priorities, size, and complexity. Requirements can be tailored more broadly across a group of similar projects, a program, an organization, or other collection of similar software development efforts in accordance with NPR 7120.5, Section 3.5.5.

This requirement assesses that project personnel is meeting all requirements invoked for projects by NPR 7150.2 and by the NASA Software Assurance and Software Safety Standard, NASA-STD-8739.8 ²⁷⁸.

See also SWE-140 - Comply with Requirements, 

3.3 Requirements Mapping Matrix

The purpose of the Requirements Mapping Matrix in NPR 7150.2 is to essentially pre-tailor out requirements for less critical software systems, e.g., while Class A software has all of the requirements for projects, Class E has significantly fewer requirements.  The purpose of the “X” label is to clarify the intent of NPR 7150.2 and to preclude any alternate interpretation of invoked requirements. See topic 7.16 - Appendix C. Requirements Mapping and Compliance Matrix.

This requirement makes a positive statement that each invoked requirement is to be fulfilled by the requirement’s responsible party (indicated by the Responsibility column in Appendix C: Requirements Mapping and Compliance Matrix).  

Relief from invoked requirements can only be granted by the designated Technical Authority called out for each requirement in Appendix C.  

Tailoring of the requirements of NPR 7150.2 is to follow the approved processes for requirements management. (See SWE-121 - Document Tailored Requirements)  

Mitigations, risk acceptance, and rationale for relieved requirements are to be documented by the project.  The preferred location for capturing this information is the NPR 7150.2 compliance matrix because the compliance matrix, as well as any deviations or waivers, requires the approval of the Technical Authority (see SWE-126 - Tailoring Considerations.)  Placing risk and justification information in the compliance matrix ensures that the Technical Authority has the proper information in one place to make an informed approval or disapproval of any requests for relief of requirements.  Additionally, capturing this information in the compliance matrix provides one document that contains the project’s software requirement plans: requirements the project intends to meet, requirements approved for deviation or waiver, and the associated background for any relief approvals or disapprovals. See also SWE-216 - Internal Software Sharing List, 

3.4 Additional Guidance

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

3.6 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

• Assessment of Software Engineering Compliance w/ NPR 7150.2
• Audit results for both product and process audits
• Audits against NPR 7150.2 requirements mapping matrix, including findings.

  
  

  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 software work product Non-Conformances identified by life cycle phase over time
• # of Compliance Audits planned vs. # of Compliance Audits performed
• # of software process Non-Conformances by life cycle phase over time
• # of Open vs. Closed Audit Non-Conformances over time
• Trends of # of Non-Conformances from audits over time (Include counts from process and standards audits and work product audits.)
• # of Non-Conformances per audit (including findings from process and compliance audits, process maturity)
• # of safety-related requirement issues (Open, Closed) over time
• # of safety-related non-conformances identified by life cycle phase over time
•  # of Non-Conformances (activities not being performed)
  •      # of Non-Conformances accepted by the project
  •      # of Non-Conformances (Open, Closed, Total)
  •      Trends of Open vs. Closed over time
• # of Non-Conformances identified in plans (e.g., SMPs, SDPs, CM Plans, SA Plans, Safety Plans, Test Plans)

See also Topic 8.18 - SA Suggested Metrics. 

7.4 Guidance

This requirement assesses that project personnel is meeting all requirements invoked for projects by NPR 7150.2 and by the NASA Software Assurance and Software Safety Standard, NASA-STD-8739.8 ²⁷⁸.

The purpose of the Requirements Mapping Matrix in NPR 7150.2 is to essentially pre-tailor out requirements for less critical software systems, e.g., while Class A software has all of the requirements for projects, Class E has significantly fewer requirements.  The purpose of the “X” label is to clarify the intent of NPR 7150.2 and to preclude any alternate interpretation of invoked requirements. 

This requirement makes a positive statement that each invoked requirement is to be fulfilled by the requirement’s responsible party (indicated by the Responsibility column in Appendix C: Requirements Mapping and Compliance Matrix).  

Software that is incorporated into Complex Electronics (CE) or Programmable Logic Devices (PLDs) is covered by the NPR 7150.2 requirements and the NASA Software Assurance and Safety Standard, NASA-STD-8739.8. See the Programmable Logic Devices (PLD) Handbook, NASA-HDBK-4008 ⁶⁸⁶, and the NASA Complex Electronics Handbook for Assurance Professionals, NASA-HDBK-8739.23 ⁰³⁴  for additional guidelines.

To assess the project's compliance with the requirements in NPR 7150.2, obtain the project's approved Requirements Mapping Matrix or Matrices. Using the agreed-upon classifications of the project's software, verify that the correct column in Appendix C is being used in the Requirements Mapping Matrix for the classification of the software.

Verify that the appropriate signatories have approved any tailoring that is noted in the Matrix. The signatories for Class A through Class E should be Center Director or the Center Director’s designated Engineering Technical Authority, the Center Director's designated SMA Technical Authority, and the CHMO designated for Health and Medical Technical Authority (if there are medical or health concerns). The signatory for the Class F software is the Center Chief Information Officer or designee.

Using the set of requirements plus any approved tailoring, confirm that the project is following those requirements. Generally, this is done by auditing project documentation and activities using checklists. To confirm that all the requirements are being met completely, it will probably be necessary to do audits at different stages of the project. Any non-conformances found should be reported to the project manager and software assurance management. These should be tracked to closure.

7.5 Additional Guidance

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