This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C
184.108.40.206 Serving as Technical Authorities for requirements in this directive, Center Directors, or designees shall:
a. Assess project’s compliance matrices, tailoring, waivers, and deviations 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 compliance 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 compliance 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) Coordinate with the Center S&MA organization that the compliance matrix implementation approach does not impact safety and mission assurance on the project.
(6) Approving/disapproving request for relief from requirements designated with “X” in Appendix C, which fall under this Technical Authority’s scope of responsibility.
(7) Facilitating the processing of projects’ tailoring/compliance matrices, tailoring, waivers, or deviations from requirements in this directive, which fall under the responsibilities of a different Technical Authority (see column titled “Technical Authority” in Appendix C).
(8) Ensuring that approved compliance matrices, including any waivers and deviations against this directive, are archived as part of retrievable project records.
To effectively assess projects’ compliance matrices, the designated Center Engineering Technical Authorities for this NPR are recognized NASA software engineering experts or utilize recognized NASA software engineering experts in their decision processes. Additionally, it is a best practice to obtain a risk assessment from the Center’s Safety and Mission Assurance organization for any software waivers/deviations prior to Technical Authority approval. 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.
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.
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.
The no-cost classification tool in this Handbook, based on Appendix D, can be used as a first step in classifying software because the results from the tool and the supporting rationale can be printed and included in classification documentation. Topic 7.2 - Classification Tool and Safety-Critical Assessment Tool of this Handbook contains an introduction to the tool and its current Web address.
- 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: Topic 7.4 - Flow Down of NPR Requirements to 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 373. 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, 268 and NPR 1441.1D, NASA Records Retention Schedules. 037
4. Small Projects
This requirement applies to all projects regardless of size.
- A Renewed Commitment to Excellence: An Assessment of the NASA Agency-wide Applicability of the Columbia Accident Investigation Board Report.Diaz, Al,NASA Goddard Space Flight Center (Jan, 2004). CAIB Columbia Accident Investigation Board Report. (August 2003). Vol. 1. PB2005-100968
Tools relative to this SWE may be found in the table below. You may wish to reference the Tools Table in this handbook for an evolving list of these and other tools in use at NASA. Note that this table should not be considered all-inclusive, nor is it an endorsement of any particular tool. Check with your Center to see what tools are available to facilitate compliance with this requirement.
No tools have been currently identified for this SWE. If you wish to suggest a tool, please leave a comment below.
6. 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." 144