1. Requirements

2.1.5.6 Serving as technical and institutional authorities for requirements in this directive, Center Director, or designee, shall:  

a. Assess projects’ requirements mapping matrices and tailoring from requirements in this directive by: 

(1) Checking the accuracy of the project’s classification of software components against the definitions in Appendix D. 

(2) Evaluating the project’s Requirements Mapping Matrix for commitments to meet applicable requirements in this directive, consistent with software classification. 

(3) Confirming that requirements marked “Not-Applicable” in the project’s Requirements Mapping Matrix are not relevant or not capable of being applied. 

(4) Determining whether the project’s risks, mitigations, and related requests for relief from requirements designated with “X” in Appendix C are reasonable and acceptable. 

(5) Approving/disapproving requests for relief from requirements designated with “X” in Appendix C, which falls under this Authority’s scope of responsibility. 

(6) Facilitating the processing of projects’ requirements mapping matrices and tailoring decisions from requirements in this directive, which falls under the responsibilities of a different Authority (see the column titled “Authority” in Appendix C). 

(7) Include the Center CIO and CISO (or delegate) in all software reviews to ensure software cybersecurity is included throughout software development, testing, maintenance, retirement, operations, management, acquisition and assurance activities. 

(8) Ensuring that approved requirements mapping matrices, including any tailoring rationale against this directive, are archived as part of retrievable project records.

b. Indicate the Technical Authority or Technical Authorities approval by the signature(s) in the Requirements Mapping Matrix itself, when the Requirements Mapping Matrix is used to tailor from the applicable “X” requirement(s).

1.1 Notes

1. 1. To effectively assess projects’ requirements mapping matrices, the designated Center Engineering Technical and Institutional Authorities for this NPR are recognized NASA software engineering experts or utilize recognized NASA software engineering experts in their decision processes. NASA-HDBK-2203 contains valuable information on each requirement, links to relevant NASA Lessons Learned, and guidance on tailoring. Center organizations or branches may also share frequently used tailoring and related common processes.
   2. The Requirements Mapping Matrix documents the requirements that the project plans to meet, “not applicable” requirements, and any tailoring approved by designated Authorities with associated justification. If a project wants to tailor a requirement marked as Headquarters Technical Authority, then the project is required to get NASA Headquarters approval (e.g., OCE, OSMA, OCIO, or OCHMO) on a tailored request or a software Requirements Mapping Matrix.

1.2 History

2. Rationale

NPR 7150.2 contains the basic set of requirements for software developed by or for the agency. Any request for a "Deviation" (a documented authorization releasing a program or project from meeting a requirement before the requirement is put under configuration control at the level the requirement will be implemented) or a "waiver" (a documented authorization intentionally releasing a program or project from meeting a requirement after the requirement is put under configuration control at the level the requirement will be implemented) from a particular requirement is made to the appropriate level and type of Technical Authority (TA) as listed in Appendix C in NPR 7150.2. When assessing the requests, the designated TA considers a number of relevant factors in deliberation. It is not uncommon for a waiver/deviation to require approval from TAs from two different organizations, e.g., Engineering TA (ETA) as well as Safety & Mission Assurance TA. 

3. Guidance

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 a 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 in 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 the 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 the 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 on 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: Topic 7.04 - 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 the information required for the release activity by the Software Release Authority. Appropriate planning by the TA and the software team can assure the 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. ⁰³⁷

4. Small Projects

This requirement applies to all projects regardless of size.

5. Resources

5.1 References

5.2 Tools

6. Lessons Learned

6.1 NASA Lessons Learned

• Columbia Accident Investigation Board, Report Vol 1 ¹⁴⁴, Aug 2003, Recommendation R7.5-1: "Establish an independent Technical Engineering Authority that is responsible for technical requirements and all waivers to them, and will build a disciplined, systematic approach to identifying, analyzing, and controlling hazards throughout the life of the Shuttle System."

6.2 Other Lessons Learned

No other Lessons Learned have currently been identified for this requirement.