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

Per NPR 7150.2, “Software engineering is a core capability and a key enabling technology for NASA's missions and supporting infrastructure. ...This directive imposes requirements on procedures, design considerations, activities, and tasks used to acquire, develop, assure, and maintain software created and acquired by or for NASA programs. This directive is a designed set of requirements for protecting the Agency's investment in software engineering products and to fulfill its responsibility to the citizens of the United States. ... In this directive, all mandatory actions (i.e., requirements) are denoted by statements containing the term “shall,” followed by a software engineering (SWE) requirement number. The terms “may” or “can” denote discretionary privilege or permission, “should” denotes a good practice and is recommended but not required, “will” denotes expected outcome, and “are/is” denotes descriptive material.”

3. 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).  

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)  

Per NPR 7150.2, “Tailoring is the process used to adjust or seek relief from a prescribed requirement to accommodate the needs of a specific task or activity (e.g., program or project). The tailoring process results in the generation of waivers or deviations depending on the timing of the request (see Appendix A for relevant definitions). 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 following NPR 7120.5, Section 3.5.5.”

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.)  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.

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. Assess that the software requirements, products, procedures, and processes of the project are compliant with the NPR 7150.2 requirements per the software classification and safety criticality for software.

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 over time
• # of Non-Conformances identified in plans (e.g., SMPs, SDPs, CM Plans, SA Plans, Safety Plans, Test Plans)

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 compliance to 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.