View this section on the website
See edit history of this section
Post feedback on this section
1. Requirements
2.1.8.2 The technical and institutional authorities for requirements in this directive 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 column titled “Authority” in Appendix C).
(7) Include the SAISO (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 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
a. 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.
b. 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 HQ TA, then the project is required to get NASA HQ approval (e.g., OCE, OSMA, OCIO, or OCHMO) on a tailored request or a software Requirements Mapping Matrix.
1.2 History
2. Rationale
To reduce the risk and cost associated with the software development and use on NASA projects.
3. Guidance
3.1 Request for Deviation or Waiver
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.
2.2.1 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 tailoring from specific requirements are appropriately mitigated, NASA established TA governance. Tailoring from requirements in this directive are governed by the following requirements, as well as those defined in NPD 1000.3, The NASA Organization NPD 2800.1, NPR 2810.1, NPR 7120.5, NPR 7120.7, NPR 7120.8, NPR 7120.11 and NPR 8715.3 for all of the Agency’s investment areas. The Technical and Institutional Authority for each requirement in this NPR is documented in the “Authority” column of Appendix C. The responsible program, project, or operations manager need to formally accept the tailoring risk. Tailoring decided at the Center level are to consult the Center ETA, Center SMA TA, Center Health and Medical TA, and the NASA CIO’s Center IT Authority designee as defined in the requirements mapping matrix. The OSMA has co-approval on any tailoring decided at the HQ level that involves software. The Office of the Chief Medical Officer (OCHMO) has co-approval on any tailoring decided that involves software with health and medical implications. The SAISO, or designee, has co-approval on any tailoring of the cybersecurity requirements in Section 3.11. For tailoring involving human safety risk, the actual risk taker(s) (or official spokesperson[s] and appropriate supervisory chain) need to formally agree to assume the risk. ’ 083
Requests for relief from software requirements can take a variety of forms, including tailoring, compliance matrices, waivers, and deviations. Per NPR 7150.2D,
See also SWE-140 - Comply with Requirements, SWE-216 - Internal Software Sharing List,
3.2 Preparing Deviation or Waiver Requests
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 the 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 the 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 the 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 allows 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 - Shall Statements). 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 on 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.
See also 7.16 - Appendix C. Requirements Mapping and Compliance Matrix. SWE-150 - Review Changes To Tailored Requirements
3.3 ETA Considerations
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.
See also Topic 8.05 - SW Failure Modes and Effects Analysis
3.4 Deviation and Waiver Tracking
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.04 - Flow Down of NPR Requirements on Contracts and to Other Centers in Multi-Center Projects.
3.5 Compliance Matrix
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 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.
See also SWE-125 - Requirements Compliance Matrix,
3.6 Record Retention
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
See also SWE-121 - Document Tailored Requirements,
3.7 Additional Guidance
Additional guidance related to this requirement may be found in the following materials in this Handbook:
3.8 Center Process Asset Libraries
SPAN - Software Processes Across NASA
SPAN contains links to Center managed Process Asset Libraries. Consult these Process Asset Libraries (PALs) for Center-specific guidance including processes, forms, checklists, training, and templates related to Software Development. See SPAN in the Software Engineering Community of NEN. Available to NASA only. https://nen.nasa.gov/web/software/wiki 197
See the following link(s) in SPAN for process assets from contributing Centers (NASA Only).
| SPAN Links |
|---|
4. Small Projects
This requirement applies to all projects regardless of size.
5. Resources
5.1 References
- (SWEREF-023) NPR 8900.1B, NASA Office of the Chief Health & Medical Officer, 2008., Effective Date: December 16, 2016, Expiration Date: December 16, 2021
- (SWEREF-024) NPR 8705.2C, NASA Office of Safety and Mission Assurance, 2008., Effective Date: July 10, 2017, Expiration Date: July 10, 2025
- (SWEREF-036) NPD 8700.1E, NASA Office of Safety and Mission Assurance, 2008. Effective Date: October 28, 2008, Expiration Date: April 28, 2020
- (SWEREF-037) NPR 1441.1E, NASA Office of the Chief Information Officer, Effective Date: January 29, 2015, Expiration Date: January 29, 2024
- (SWEREF-066) NPD 1000.3E, Associate Administrator, April 15, 2015, Expiration Date: April 15, 2026
- (SWEREF-082) NPR 7120.5F, Office of the Chief Engineer, Effective Date: August 03, 2021, Expiration Date: August 03, 2026,
- (SWEREF-144) Diaz, Al,NASA Goddard Space Flight Center (Jan, 2004). CAIB Columbia Accident Investigation Board Report. (August 2003). Vol. 1. PB2005-100968
- (SWEREF-197) Software Processes Across NASA (SPAN) web site in NEN SPAN is a compendium of Processes, Procedures, Job Aids, Examples and other recommended best practices.
- (SWEREF-256) NPR 1400.1H, NASA Office of Internal Controls and Management Systems, Effective Date: March 29, 2019, Expiration Date: March 29, 2024
- (SWEREF-257) NPD 7120.4E, NASA Office of the Chief Engineer, Effective Date: June 26, 2017, Expiration Date: June 26, 2022
- (SWEREF-262) NASA Headquarters NASA Office of the Chief Engineer engineering deviations and waivers website.
- (SWEREF-268) NPD 1440.6I, 2008. Effective Date: September 10, 2014
- (SWEREF-273) NASA SP-2016-6105 Rev2,
- (SWEREF-373) NPR 2210.1C, Space Technology Mission Directorate, Effective Date: August 11, 2010, Expiration Date: January 11, 2022
- (SWEREF-403) NPR 2810.1F, Office of the Chief Information Officer, Effective Date: January 03, 2022, Expiration Date: January 03, 2027,
- (SWEREF-406) January, 2012. This is a list of the NASA Requirement Waivers. Instructions for submitting requirement waivers are outlined in Chapter 4 of NPR 1400.1, NASA Directives Procedural Requirements.
5.2 Tools
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
6.1 NASA Lessons Learned
- Columbia Accident Investigation Board, Report Vol 1 144, 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.
0 Comments