1. Requirements

6.3.2 Each project with software components shall maintain a compliance matrix against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles.

1.1 Notes

Note: The compliance matrix documents the requirements that the project plans to meet and any approved waivers or deviations. The compliance matrix and compliance matrix updates should be submitted to the designated Center level Engineering Technical Authority for their records.

1.2 Applicability Across Classes

This requirement applies to all classes and safety criticalities.

2. Rationale

Compliance is commonly defined as the demonstration of adherence to the standard or the requirement applied to the project. The development and maintenance of a compliance matrix provides a management control tool for the mutual understanding and agreement about the project requirements between acquirer and provider. A properly maintained compliance matrix is an indicator of the state and progress of the project. Periodic reviews of achieved project compliance against that planned in the compliance matrix can help identify any needed deviations or waivers against the requirements of NPR 7150.2. The compliance matrix can also be a useful tool during an evaluation of project risk.

3. Guidance

A compliance 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's compliance matrix with this NPR may contain entries that are applicable to some software components but not to others. The project completes the determination of software classification (see SWE-020 ), which is independently assessed by the software assurance organization (see SWE-132 ). An example of a blank compliance matrix template ²⁸⁴is available for each class and safety criticality on the NASA Engineering Network (NEN) website ²⁵⁸ within the Document Library folder of the software community of practice.

A software compliance matrix is initially developed and included in the Software Development Plan or Software Management Plan (see SWE-102). The software project development team draws the initial list of requirements for the compliance matrix from Appendix D of NPR 7150.2. This Handbook provides matrices ²⁸⁴ of NPR requirements that are applicable to each software class. If a Center has properly mapped the NPR 7150.2 requirements to its Center-level procedural requirements, then it is acceptable to develop the compliance matrix from that Center's software directives. The locally tailored P (Center) requirements (see SWE-140) are included in the compliance matrix. In some instances, a requirement may be included in a matrix for a particular software class but may not be applicable for a given project or software component. In these cases, the requirement is still included in the compliance matrix but clearly marked "Not Applicable" with an associated reason, e.g., SWE-131 is 'Not Applicable" because the project was not selected by the Headquarters Chief Safety and Mission Assurance (SMA) for Independent Verification and Validation (IV&V)  services. For situations where a requirement is under Center-level Technical Authority (TA) (as denoted in NPR 7150.2, Appendix D, last column), the Center can mark the requirement "Not Applicable" in the compliance matrix and provide a justification. If a requirement under the direct TA of the Headquarters Chief Engineer or Chief SMA is not applicable, the Center must coordinate with the Headquarters' Office of the Chief Engineer (OCE) or Office of Safety and Mission Assurance (OSMA). Waivers and deviations are not required for such clearly defendable requirements that are designated and/or coordinated as "Not Applicable."

The software compliance matrix accounts for any approved waivers and deviations, including alternate requirements and general exclusions. For additional guidance associated with waivers and deviations see SWE-120, SWE-121, and SWE-126 . The compliance matrix has the additional feature of being usable by the program, project, or facility as a checklist to ensure coverage of all requirements applicable to the project.

The matrix typically is filled in with a description or identification of the document and section number or step that defines the method the project is using to comply with the requirement. There needs to be enough detail that an auditor can find the documentation to assess compliance at various points in the project life cycle.

Many projects contain software with requirements to be met by a combination of on-site workforce and external contractors. Contracts and agreements need to include the software requirements assigned to external development organizations consistent with the project's software compliance matrix. The compliance matrix template referred to above may need to be expanded to sufficiently capture the information about the software acquired by contract, e.g., prime contractor, subcontractor, listing of contractor-approved alternate requirements.

Because projects face complex problems and challenging environments, waivers and deviations from select NPR 7150.2 requirements may provide acceptable relief from the competing and sometimes conflicting technical, schedule, and cost issues facing the projects. While some of these will be requested and approved before project initialization, others will occur throughout the planning and implementation phases of the project. The compliance matrix assumes an even greater role in tracking compliance demonstration against these initial and revised requirements throughout the project's life cycle. General waiver/deviation processes and direction for NASA TAs are provided in NPR 7120.5, NASA Space Flight Program and Project Management Requirements, and at the NEN Requirements and Technical Authorities web page. ²⁶²

A well-formed compliance matrix entry will include:

• The requirement statement.
• Sufficient information to locate it in the controlling document.
• A listing of the revised or tailored requirement (see Guidance for SWE-140 for P(Center) requirements).
• An entry for the planned compliance demonstration activity.

The software development team typically enters into the matrix actual project evidence that demonstrates compliance as the project progresses. Often, this evidence is saved in a web- or server-based file or database in a central location that is available to the entire project team. In addition to project monitoring and control activities that capture the compliance matrix information and its updates within the project records, the information is also provided to the Center's software Engineering Technical Authority (ETA). This provision assures that the ETA is properly informed and takes appropriate action with respect to NASA's system of checks and balances in the areas of dissenting opinion, independent reviews, and compliance assessment. One of the things the TA routinely checks in compliance matrices is whether items marked "Not Applicable" are sufficiently justified. The project team develops the mechanics of the actual transmission of this information to the Center's ETA as a part of the overall project's planning activities.

4. Small Projects

All requirements are listed in the compliance matrix, but the project can determine the critical entries along with waiver/deviation candidates during the development of the compliance matrix to balance project risks when personnel or funding restrictions limit documentation and other activities

5. Resources

5.1 Tools

Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).

NASA users find this in the Tools Library in the Software Processes Across NASA (SPAN) site of the Software Engineering Community in NEN.

The list is informational only and does not represent an “approved tool list”, nor does it represent an endorsement of any particular tool. The purpose is to provide examples of tools being used across the Agency and to help projects and centers decide what tools to consider.

6. Lessons Learned

No lessons learned have currently been identified for this requirement.