This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2C
2.2.6 The projects shall comply with the requirements in this NPR that are marked with a “project” responsibility and an “X” in Appendix C consistent with their software classification.
Project relief from an applicable “X” requirement can only be granted by the designated Technical Authority called out in the column titled “Technical Authority” in Appendix C. The project also documents their related mitigations and risk acceptance in the approved compliance matrix. When the requirement and software class are marked with an “X,” the projects record the risk and rationale for any requirements that are completely relieved in the compliance matrix.
1.2 Applicability Across Classes
Class A B C CSC D DSC E F G H Applicable?
Key: - Applicable | - Not Applicable
A & B = Always Safety Critical; C & D = Not Safety Critical; CSC & DSC = Safety Critical; E - H = Never Safety Critical.
Per NPR 7150.2, “Software engineering is a core capability and a key enabling technology for NASA's missions and supporting infrastructure. ...This directive imposes requirements on procedures, design considerations, activities, and tasks used to acquire, develop, assure, and maintain software created and acquired by or for NASA programs. This directive is a designed set of requirements for protecting the Agency's investment in software engineering products and to fulfill its responsibility to the citizens of the United States. ... In this directive, all mandatory actions (i.e., requirements) are denoted by statements containing the term “shall,” followed by a software engineering (SWE) requirement number. The terms “may” or “can” denote discretionary privilege or permission, “should” denotes a good practice and is recommended but not required, “will” denotes expected outcome, and “are/is” denotes descriptive material.”
This requirement affirms that project personnel are to satisfy all requirements invoked for projects by this NPR.
The purpose of the Requirements Mapping Matrix in NPR 7150.2 is to essentially pre-tailor out requirements for less critical software systems, e.g., while Class A software has 84 invoked requirements for projects, Class H has only 9. The purpose of the “X” label is to clarify the intent of NPR 7150.2 and to preclude any alternate interpretation of invoked requirements.
This requirement makes a positive statement that each invoked requirement is to be fulfilled by the requirement’s responsible party (indicated by the Responsibility column in the Appendix C: Requirements Mapping and Compliance Matrix).
Inherently, it affirms that fulfillment of requirements marked with an "X" is the rule for specific NASA software classifications.
Relief from invoked requirements can only be granted by the designated Technical Authority called out for each requirement in Appendix C. Per NPR 7150.2, “The NASA CSMA has co-approval on any waiver or deviation decided at the Headquarters level that involves software.“
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 (see Appendix A for relevant definitions). Each project has unique circumstances, and tailoring can be employed to modify the requirements set appropriate for the software engineering effort. Tailoring of requirements is based on key characteristics of the software engineering effort, including acceptable technical and programmatic risk posture, Agency priorities, size, and complexity. Requirements can be tailored more broadly across a group of similar projects, a program, an organization, or other collection of similar software development efforts in accordance with NPR 7120.5, Section 3.5.5.”
Mitigations, risk acceptance, and rationale for relieved requirements are to be documented by the project. The preferred location for capturing this information is the NPR 7150.2 compliance matrix because the compliance matrix, as well as any deviations or waivers, requires the approval of the Technical Authority (see SWE-126.) Placing risk and justification information in the compliance matrix ensures that the Technical Authority has the proper information in one place to make an informed approval or disapproval of any requests for relief of requirements. Additionally, capturing this information in the compliance matrix provides one document that contains the project’s software requirement plans: requirements the project intends to meet, requirements approved for deviation or waiver, and the associated background for any relief approvals or disapprovals.
4. Small Projects
No additional guidance is available for small projects.
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
There are currently no Lessons Learned identified for this requirement.