Per NPR 7150.2, “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, 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 variants from specific requirements are appropriately mitigated, NASA established Technical Authority governance. ... The Technical Authority for each requirement in this NPR is documented in the "Technical Authority" column of Appendix C. The NASA CSMA has co-approval on any waiver or deviation decided at the Headquarters level that involves software. The NASA CHMO has co-approval on any waiver or deviation decided at the Headquarters level that involves software with health and medical implications. Waivers or deviations decided at the Center level are to follow similar protocol when software criticality or health and medical issues are involved.”
Requests for relief from software requirements can take a variety of forms, including tailoring, compliance matrices, waivers, and deviations. 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. Requests for software requirements relief (i.e., partial or complete relief) may be submitted in the streamlined form of a Compliance Matrix.... If the Compliance Matrix is completed and approved in accordance with NPR 7120.5’s direction on Technical Authority and this NPR, it meets the requirements for requesting tailoring and serves as a waiver or deviation.”
General directions for preparing NASA "deviation" and "waiver" requests can be found in NPR 7120.5. Direction specific to software is provided in Chapter 2 of NPR 7150.2.
If the project or software lead engineer submits a request for relief, the Engineering Technical Authority (ETA) performs specific actions to assess those submissions.
- Check project’s classification of software components: Appendix D of NPR 7150.2 gives definitions and examples of systems that typically have the listed software classification. Relief from requirements for higher level software classes (A and B) or with safety critical aspects is evaluated with increased rigor. Additional classifications, such as human-rated systems and payload classifications, also imply the degree to which a waiver/deviation would be acceptable. The TA checks to ensure correct classification of the system, subsystem, and software, as requirements can vary significantly across classifications. Consideration is given to the software classification associated with these systems or subsystems to assure the level of risk accepted by granting the waiver or deviation is consistent with the overall importance of the system under development.
- Evaluate project’s compliance matrix: Comparing the project’s completed NPR 7150.2 compliance matrix against Appendix C in the NPR helps provide an objective review early in the life cycle to confirm that the project is planning to meet all requirements for the appropriate software classification for which the project has not received approval for relief.
- Confirm requirements marked “Not-Applicable” are not relevant or not capable of being applied: Accuracy of the project’s compliance matrix is important to help ensure that the correct set of requirements is included in project plans. Requirements that are marked as “not applicable” in the compliance matrix should have corresponding project justification, risk assessments, and/or rationale to assist the ETA in confirming that those requirements are not relevant to the project or that the project cannot meet them.
- Determine whether project’s risks, mitigations, and related request for relief are reasonable and acceptable: Justification, risk assessments, and/or rationale provided to assist the ETA in confirming that requirements for which the project is seeking relief are not relevant to the project or that the project cannot meet them should be clear, complete, reasonable, and build the case which allows the ETA to deem them an acceptable basis upon which to grant the waiver or deviation. Additionally, consideration is given to how waiving this requirement could impact this mission as well as subsequent missions. It is not uncommon for software to be reused on future missions or to evolve to a more critical role on the current mission. A relevant factor is that waivers and deviations and other relief from requirements are not granted on a permanent basis, because software developed under relief from requirements can negatively impact its reuse.
- Coordinate approach with the Center S&MA organization: Coordination is needed with the Center SMA organization (CSMA) that the set of requirements in the compliance matrix allow the assurance of robust safety and mission assurance processes and activities for this mission and that any waived or deviated requirements do not negatively impact the safety or completion of the mission. Any disagreements should be handled by the Center-defined technical authority process.
- Approve/disapprove request for relief: Requirements in this NPR are invoked by software classification in Appendix C. Requirements marked with an “X” in Appendix C are required (see SWE-139). Appendix C also lists the TA who has the responsibility for approving or disapproving waivers and deviations for each requirement.
- Facilitate processing of requests for relief from requirements in this NPR which fall under a different Technical Authority: Potential impact to health, medical concerns, or safety directly affects the risk consideration when evaluating a request for relief from a requirement. When these factors are relevant, it is very likely that involvement of the Safety TA and/or the Health and Medical TA will be necessary. It is not uncommon for a waiver/deviation request to come up through one TA chain but not another. When this occurs, it is the ETA's responsibility to coordinate with counterparts.
- Ensure approved compliance matrices, waivers and deviations, are archived: Archiving as part of the project’s records the approved compliance matrices and any waivers and deviations associated with NPR 7150 is important so that compliance decisions, notes, rationale are maintained for use by future projects as well as to justify or explain those decisions on the current project. As the project is reviewed throughout the life cycle, recalling the reasons for waivers, deviations, and approved requirements can be difficult unless they are captured and archived in a retrievable manner in a project repository.
The ETA who is assessing the projects’ tailoring/compliance matrices, waivers, or deviations from requirements in this NPR should also consider the impacts found by others considering the following areas:
- Impacts to health and safety, e.g., medical TA.
- Results of Failure Mode Effects Analysis (FMEA).
- Findings in Hazard reports.
- Other risk evaluations, e.g., Safety and Mission Assurance (SMA) Technical Authority (TA).
- Overall considerations for mission success.
The ETA's considerations should include the interests of systems stakeholders, support organization functions, and other interested parties.
Information and results for deviation and waiver request activities are recorded and tracked in the project's configuration management system. Information on configuration management systems is available throughout the NASA literature. This documentation typically includes request procedures, configuration control techniques, general instructions for evaluating impacts, and guidelines for completing the necessary forms. Project development activities typically draw upon these resources to develop project-specific documentation. The request packages are typically processed through management chains, through project control boards, and to higher administrative and management levels, e.g., the Headquarters' OCE, when appropriate.
Additional guidance on deviations and waivers related to contracts may be found in the following related topic in this Handbook: 7.4 - Flowdown of NPR Requirements on Contracts and to Other Centers in Multi-Center Projects.
The project’s compliance matrices, including tailoring, waivers, and deviations from requirements in this directive recorded in them, are a part of the software release requirements for software developed or procured by NASA per NPR 2210.1C . The compliance matrices contain information required for the release activity by the Software Release Authority. Appropriate planning by the TA and the software team can assure availability of documentation that satisfies both NPR compliance and software release needs.
Record retention and deletion procedures contained in the configuration management process are performed in accordance with Center record management directives, as well as NPD 1440.6, NASA Records Management, and NPR 1441.1D, NASA Records Retention Schedules.