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 the NPR. 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 to NASA users for each class and safety criticality on the NASA Engineering Network (NEN) website within the Document Library folder of the software community of practice.

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 are submitted to the designated Center level Engineering Technical Authority for their records.

A software compliance matrix is initially developed and included in the Software Development Plan or Software Management Plan (see SDP-SMP). The software project development team draws the initial list of requirements for the compliance matrix from Appendix C 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.

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. Requests for software requirements relief (partial or complete relief) at either the Center or Headquarters Technical Authority level may be submitted in the streamlined form of a compliance matrix. The required signatures from the responsible organizations and designated Technical Authorities, engineering, and safety and mission assurance must be obtained. If the compliance matrix is completed and approved in accordance with NPR 7120.5’s direction on Technical Authority and this directive, it meets the requirements for requesting tailoring and serves as a waiver or deviation.

For situations where a requirement is under Center-level Technical Authority (TA) (as denoted in NPR 7150.2, Appendix C, fourth column), the Center can tailor the requirement in the compliance matrix and provide a justification. If a requirement is under the direct TA of the Headquarters Chief Engineer and the Office of Safety and Mission Assurance (OSMA), the Center must coordinate tailoring with the Headquarters' Office of the Chief Engineer (OCE) and Office of Safety and Mission Assurance (OSMA).

The software compliance matrix accounts for any approved waivers and deviations, including alternate requirements and exclusions. For additional guidance associated with waivers and deviations see 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 NASA Engineering Network (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.
• Risk and rationale for any requirements that are completely relieved in the compliance matrix.
• The required signatures from the responsible organizations and designated Technical Authorities, engineering and safety and mission assurance.

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.

NASA-specific compliance matrix information and resources are available in Software Processes Across NASA (SPAN), accessible to NASA users from the SPAN tab in this Handbook.

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.