1. Requirements

3.1.13 Each project manager with software components shall maintain a requirements mapping matrix or multiple requirements mapping matrices against requirements in this NPR, including those delegated to other parties or accomplished by contract vehicles or Space Act Agreements. 

1.1 Notes

A project may have multiple software engineering requirements mapping matrices if needed for multiple software components on a given project.

Project relief from an applicable “X” requirement can be granted only by the designated Technical Authorities, Engineering, and Safety and Mission Assurance, or, for security issues, the NASA Chief Information Officer or designee. The record of their approval of the tailored requirements in a Requirements Mapping Matrix will be indicated by the Authority signature or signatures in the Requirements Mapping Matrix. The projects will document their related mitigations and risk acceptance in the approved Requirements Mapping Matrix. When the requirement and software class are marked with an “X,” the projects record the risk and rationale for any requirements that are entirely or partially relieved in the Requirements Mapping Matrix. The CIO has institutional authority on all Class F software projects.

1.2 History

1.3 Applicability Across Classes

Key:    - Applicable | - Not Applicable

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 provide a management control tool for mutual understanding and agreement about the project software requirements. 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 apply to some software components but not to others. The project completes the determination of software classification (see SWE-020 ), which is assessed by the software assurance organization. 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 and SMA Technical Authority for their records.

A software compliance matrix is initially developed and included in the Software Development Plan or Software Management Plan (see 5.08 - SDP-SMP - Software Development - Management Plan). 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 apply 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 following 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 justify. 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, the 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 demonstrations 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 concerning 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 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. Confirm that the project is maintaining a requirement mapping matrix (matrices) for all requirements in NPR 7150.2. 

2. Maintain the requirement mapping matrix (matrices) for requirements in NASA-STD-8739.8.

7.2 Software Assurance Products

• Software assurance and software safety requirements mapping matrix with approved tailoring (approvals are signatures by the Engineering TA, the Software Assurance TA, and Chief Information Officer (if needed)). 
• Record of review or discussion on software assurance/software safety requirements mapping matrix to determine if changes are needed
• List of software assurance/software safety requirements that are tailored
• Risks or issues on the maintenance of either requirements mapping matrices

  
  

  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
•  Identify the specific requirements in NASA-STD-8739.8 that are being tailored by the projects (*organizational metric)
• Organizational metrics:
  • Identification of which requirements are being tailored by which projects.
  • Number of projects tailoring each requirement and % of requirements tailored per project

7.4 Guidance

• Confirm that the project is maintaining appropriate requirement mapping matrix (matrices) for all requirements in the NPR at or before approval of the software management or development plan - Obtain from the project copies of the requirements mapping matrix (matrices) before the software management or development plan is approved.  Confirm that all appropriate signatures are included. Repeat this step throughout the software development lifecycle at key milestones or when an event such as a change in software classification triggers a change to the matrix (matrices).  Keep a copy of the approved requirement mapping matrix (matrices) for your records.
• Assess the tailored SA requirement(s) to ensure that the tailored requirements are in the SA plan, record, or SA procedure for the project - Review, at or before approval of the software assurance plan, the SA matrix generated under the SA Guidance tab for SWE-121 in this Handbook) to ensure it contains the tailored NASA-STD-8739.8 ²⁷⁸ requirement.  Repeat throughout the software development lifecycle. Keep a copy of the approved requirement mapping matrix (matrices) in the SA records. Make sure that any tailored requirements are addressed in the planning process and documentation and the SA schedule (see SA Guidance tab for SWE-121) and in any SA product deliveries.  Clearly define who is responsible for each SA requirement in the NASA-STD-8739.8 matrix.