This version of SWEHB is associated with NPR 7150.2B. Click for the latest version of the SWEHB based on NPR7150.2D
View this section on the website
See edit history of this section
Post feedback on this section
1. Requirements
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.
1.1 Notes
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
2. Rationale
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.”
NPR 7150.2 was written to include the explicit statement in the requirement that full compliance with the requirement is necessary for those entries assigned an "X" in Appendix D.
3. Guidance
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.“
Deviations, waivers, and tailoring of the requirements of NPR 7150.2 are to follow the approved processes for requirements management. (See SWE-121 and SWE-145.)
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.
5. Resources
Renew your license to continue
Your evaluation license has expired. Contact your administrator to renew your Reporting for Confluence license.
5.1 Tools
Tools to aid in compliance with this SWE, if any, may be found in the Tools Library in the NASA Engineering Network (NEN).
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
There are currently no Lessons Learned identified for this requirement.
