1. Requirements

6.1.2 Where approved, the requesting Center or project shall document the approved alternate requirement in the procedure controlling the development, acquisition, and/ or deployment of the affected software.

1.1 Notes

NPR 7150.2, NASA Software Engineering Requirements, does not include any notes for this requirement.

1.2 Applicability Across Classes

This requirement applies to all classes and safety criticalities.

Class	A_SC	A_NSC	B_SC	B_NSC	C_SC	C_NSC	D_SC	D_NSC	E_SC	E_NSC	F	G	H
Applicable?

Key:    A_SC = Class A Software, Safety-Critical | A_NSC = Class A Software, Not Safety-Critical | ... | - Applicable | - Not Applicable
^X - Applicable with details, read above for more | P(C) - P(Center), follow center requirements or procedures

2. Rationale

The Center is required to record the alternate requirements obtained through the use of SWE-120 in Center or program/project documentation that controls the development, acquisition, and deployment of the affected software. Publication of the approved alternate requirements helps assure that all affected software engineers are informed of the approved changes. This action will assure the proper implementation of the alternate requirement throughout the various stages of the software life cycle. (See SWE-019 for information on the life cycle process.) The inclusion of these changes in a configuration managed system for the Center or program/project will inform current and future software product developers and project managers of the correct set of requirements and procedures.

3. Guidance

Project personnel record the appropriate information on any requirements changes resulting from the approval of a request made under SWE-120 in the project-specific software requirements documents. This information is placed in the project plan, the software management plan, and the software requirements specification. The Center's compliance matrix to NPR 7150.2 will also include the results of the approval by the Headquarters' Office of the Chief Engineer (OCE). The software team lead will include any updates in the compliance matrix that reflect approved alternate requirements. The software team lead also communicates this information to affected software Technical Authorities (TAs). (See SWE-125 and SWE-128 for information on the content and handling of a compliance matrix.)

When approval is granted for an action from SWE-120, the program/project also includes the results of the request and the rationale for the request, along with any approved alterations to the initial request, in the baselined program/project documentation. Typically, Center changes are reflected in the Center's local implementation of the flowdown of NPR 7150.2, e.g., Center Directives, Center Procedural Requirements covering software engineering, and software assurance plans. The Center-level procedure typically is stored in the Center's central documentation repository. As the alternate requirements generally affect processes, related process assets are updated in the process asset library for future use by software development teams within scope of the generic waiver.

4. Small Projects

Small projects may lack the resources and schedule to individually apply for waiver relief from specific sets of NPR 7150.2 requirements. Centers can request a generic waiver (waived in accordance with SWE-120 and documented under SWE-121) that will cover multiple small projects.

5. Resources

Click here to view master references table.

• (SWEREF-066)
  The NASA Organization w/Change 85
  NPD 1000.3E, Associate Administrator, April 15, 2015, Expiration Date: April 15, 2026
• (SWEREF-082)
  NASA Space Flight Program and Project Management Requirements
  NPR 7120.5F, Office of the Chief Engineer, Effective Date: August 03, 2021, Expiration Date: August 03, 2026,
• (SWEREF-083)
  NPR 7150.2 NASA Software Engineering Requirements,
  NPR 7150.2D, Effective Date: March 08, 2022, Expiration Date: March 08, 2027 https://nodis3.gsfc.nasa.gov/displayDir.cfm?t=NPR&c=7150&s=2D Contains link to full text copy in PDF format. Search for "SWEREF-083" for links to old NPR7150.2 copies.
• (SWEREF-256)
  NASA Directives and Charters Procedural Requirements
  NPR 1400.1H, NASA Office of Internal Controls and Management Systems, Effective Date: March 29, 2019, Expiration Date: March 29, 2024
• (SWEREF-257)
  NASA Engineering and Program/Project Management Policy,
  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.
  NASA Headquarters NASA Office of the Chief Engineer engineering deviations and waivers website.
• (SWEREF-263)
  Delegation of Authority for Granting Relief from OCE Requirements
  NASA HQ OCE Letter. August 15, 2012.
• (SWEREF-264)
  NASA Information Technology Program and Project Management Requirements
  NPR 7120.7A, Office of the Chief Information Officer, Effective Date: August 17, 2020, Expiration Date: August 17, 2025 .
• (SWEREF-269)
  NASA Research and Technology Program and Project Management Requirements (Updated w/Change 2)
  NPR 7120.8A, NASA Office of the Chief Engineer, 2008, Effective Date: September 14, 2018, Expiration Date: September 14, 2023
• (SWEREF-273)
  NASA Systems Engineering Handbook
  NASA SP-2016-6105 Rev2 supersedes SP-2007-6105 Rev 1 dated December, 2007
• (SWEREF-278)
  SOFTWARE ASSURANCE AND SOFTWARE SAFETY STANDARD
  NASA-STD-8739.8B , NASA TECHNICAL STANDARD, Approved 2022-09-08 Superseding "NASA-STD-8739.8A,
• (SWEREF-403)
  Security of Information and Information Systems
  NPR 2810.1F, Office of the Chief Information Officer, Effective Date: January 03, 2022, Expiration Date: January 03, 2027,
• (SWEREF-566)
  The Pitfalls of "Engineering-by-Presentation" (2005)
  Public Lessons Learned Entry: 1715.

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

A documented lesson from the NASA Lessons Learned database notes the following:

The Pitfalls of "Engineering-by-Presentation" (2005). Lesson Number 1715: Without documenting and, thereby, capturing details of the rationale for decisions affecting systems designs (requirements) "...project staff found themselves repeatedly revisiting the same technical issues. "Now why did we decide..."" This is a good indication that why it was done is as important, at times, as to what was done.

<ac:macro ac:name="unmigrated-wiki-markup">
<ac:plain-text-body><![CDATA[

OCE

]]></ac:plain-text-body>
</ac:macro>

personnel and future projects or Center personnel will be able to avoid reevaluating these general exclusion or alternate requirement approvals if they have appropriate access to the rationale so they can properly understand the basis on which the exclusions were granted in the first place. ⁵⁶⁶